Blog Help

Conectividad y SQL Server 2005

 

El tema de la conectividad con la base de datos causa a menudo muchas dudas y sensaciones de impotencia, voy a intentar contar algunas cositas que pueden ayudar al lector sobre cómo funcionan estos temas.

Lo primero es que para que dos se comuniquen, tienen que hablar el mismo lenguaje y en la misma frecuencia. Intento explicarme mejor

El mismo lenguaje

Los participantes en una comunicación cliente servidor, el cliente, y el servidor,  tienen que hablar el mismo lenguaje, para eso se necesitan drivers en la parte de server (que instala automáticamente el proceso de instalación) y en la del cliente. La mayor parte de las veces si solo se necesita una conectividad básica, los drivers de cliente ya están preinstados en Windows, con el .NET framework o con otras aplicaciones. No obstante pueden instalarse las herramientas de cliente de SQL Server 2005, desde el propio CD de instalación del producto eligiendo ese tipo de instalación.

En la instalación de los componentes de servidor, aparece a la derecha las tools, eso son la herramientas que usamos para desarrollar o administrar SQL, no son necesarias en la mayoría  de los clientes de nuestras aplicaciones, que solo necesitarán conectividad, de todas formas, si necesita alguna de esas herramientas pueden instalarse desde el CD sin instalar ninguna de las características de servidor.

 

La misma frecuencia

No sé si el lector  recuerda los silbatos para perros, estos que se soplan, nada se oye pero hace que los animalitos si que notan.  Algo parecido pasa en cualquier comunicación, en nuestro caso es mas comparable con el protocolo, además en las máquinas,  hechas a imagen y semejanza de nuestra retorcida forma de pensar es más complicado aún. Por ejemplo si le dices a un compañero de mesa a la hora del almuerzo “pásame la sal” y no te la pasa, lo que haces es repetir hasta que te oiga, incluso tienes alta disponibilidad, como la sal te la puede dar otro compañero, si este no te oye, pues se la pides a otro y listo, el  objetivo es obtener la sal al fin y al cabo J.

En el caso de SQL  esto son los protocolos, puede escuchar en varios, lo importante es que server y cliente estén escuchando en el mismo protocolo, también en la misma dirección (si le hablamos a alguien de espaldas, por mucho que lo hagamos por el  canal adecuado  es posible que no nos conteste). La herramienta que SQL 2005 nos da para controlar esto es el SQL Server 2005 configuration manager.  Ahí podemos configurar los protocolos en los que escucha el server y también los que usa el cliente. Ojo, cada  uno  hay que usarlo en su sitio J , vamos, no se puede configurar como va a escuchar el cliente en el servidor, no tendría mucho sentido.  Si en el cliente no encuentras la herramientas, después de instalar el SQL Native Client te crea una consola MMC que podrás usar, para añadirla, pulsa inicio ->ejecutar->MMC y después agrega la consola del Configuration manager como puedes ver en el gráfico

Una vez añadida la consola tendremos acceso al SQL Serverr Configuration manager que no deja de ser más que una aplicación MMC que nos ayudará a entender la conexión.  En el  caso de cliente, dos de las pestañas del configuration manager no tienen sentido. Ni los servicios de SQL Server 2005 ni el SQL Server 2005 Network config nos ayudarán en absoluto ya que lo que controlan es la parte de servidor, para poder indicar que protocolos están habilitados y para que sirven esos protocolos.  Hay que ser muy cuidadoso con esta parte, siguiendo las recomendaciones de la “informática confiable” y su SD al cubo, es decir Seguro por defecto, seguro por diseño y seguro por implementación varias de las ediciones de SQL no escuchan  en ningún protocolo, en estos casos la imagen del configuration manager será la siguiente:

Un hecho a destacar es que SQL Server 2005 llama MSSQLSERVER a la instancia por defecto,. En esta instalación (en el caso que nos ocupa es la developer edition) todos los protocolos excepto el de memoria compartida están deshabilitados, es decir, esta instalación de no cambiar nada no podrá escuchar peticiones de ningún cliente fuera del propio servidor.

Es también aquí donde se configura el protocolo, en el caso de TCP-IP que es el más común además de si está o no habilitado puede configurarse detalles como el Keep Alive, que es en milisegundos el tiempo que SQL Server se toma para comprobar que una conexión inactiva sigue viva. También si SQL escucha en todas las tarjetas de red que tenga el equipo  y para cada ip si el puerto es dinámico o fijo y cual es el puerto que utiliza. Aquí radica una de las novedades interesantes en cuanto a protocolos, ya podemos configurar nuestro server para que no escuche por todas las tarjetas de red si no es nuestro deseo sin necesidad de cerrar los puertos con otros mecanismos como firewalls etc.

Como el lector puede intuir, muchas de las comprobaciones de conectividad comenzarán por mirar por aquí la dirección en la que la instancia SQL está escuchando (la instancia por defecto, por defecto sigue escuchando en el puerto 1433)

Si el puerto lo configuramos de forma dinámica, para garantizar la conectividad deberíamos habilitar el servicio SQL Server Browser. El servicio SQL Server browser escucha  en el puerto udp 1434 y proporciona a los clientes los nombres de instancias instalados en el servidor y la configuración de cada una de esas instnacias, ya sea el nombre de pipe para el protocolo name pipes o el puerto en el que SQL Server está escuchando en el caso de conexiones TCP. SQL Server browser viene a enriquecer las características del SSRP (SqlServer resolution protocol) de la versión 2000 y a solucionar algunas de sus deficiencias.

 

Todo esto está muy bien, pero ¿Por qué no me conecto a mi SQL Server?

Bueno, la verdad es que seguro que muchos lectores se han preguntado esto más de una vez. Vamos a ver los pasos que yo haría para comprobar donde está el problema.

Paso 1 ¿Mi server está escuchando?

Para comprobar esto hay que conectarse desde el propio servidor, el protocolo que probablemente se use es Shared Memory lo que por tanto no garantiza en sí mismo que se esté escuchando en ningún otro protocolo, pero sí que realmente hay un SQL Server que pretende escuchar.

Paso 2: ¿Mi server escucha en el protocolo deseado?

Alguna vez he visto que incluso con el protocolo habilitado SQL Server no se ha puesto a escuchar en el protocolo seleccionado, si eso sucede hay que tirar de visor de sucesos (Event Viewer) y ver si hay conflictos de puertos o de nombres o protocolos de red que se han desinstalado o mil cosas. De todas formas garantizar que está escuchando se puede hacer mirando los logs del  propio SQL Server. Los logs están en la parte de administración del explorador de objetos cuando tenemos un servidor abierto. El siguiente gráfico demuestra como el servidor de ejemplo está escuchando  tanto name pipes como TCP (Ipv4 en este caso aunque es capaz también de escuchar en IPV6).

Nota, en adelante nos centraremos solamente en TCP-IP para las explicaciones

Una vez que hemos comprobado que nuestro servidor está escuchando en los puertos  vamos a ver si realmente responde a peticiones, para esto vamos a hacer ejecutar el propio servidor la utilidad telnet para comprobar que realmente está escuchando en el puerto deseado. Ojo, el puerto en el que está escuchando será por defecto el 1433 si es la instancia por defecto, pero cualquier otro si estamos conectando a una instancia con nombre. Recuerde que en el propio  configuration manager podemos comprobar esos parámetros.

Una vez que sabemos el puerto y conocido también el nombre del server  abriremos una consola y ejecutaremos la siguiente instrucción

telnet SERVERNAME Port,

Ejemplos

Telnet SQLSERVER1 1433

(para salir de telnet si funciona bien tendréis que pulsar CRTL+ [+] y luego teclear exit.

Si el resultado no es un error, (telnet nos avisa de que nadie escucha en ese Puerto), entonces podemos seguir buscando los fantasmas en otro sitio. Si no es así, hay que revisar si está habilitado TCP, si el puerto es el correcto, si en los logs aparece que está escuchando ,…

Paso 3 ¿Mi cliente puede conectarse?

Algunas veces los problemas están en los firewalls, routers y en general en todo lo que tiene que ver con la electrónica de red.  Así pues vamos a descartar primero problemas en esos puntos y luego vemos si podemos o no conectar.

Lo primero que haremos será hacer PING al servidor, ejecutar PING NombreDeServer desde la consola si el resultado es que  se resuelve el nombre (se asocia el nombre a una dirección ip) incluso si ping no devuelve los paquetes es posible que si haya conectividad. El servicio que devuelve contestación a ping puede estar deshabilitado, de hecho lo está en muchas instalaciones.

Si el nombre es resuelto, ejecutaremos TELNET, exactamente igual que hicimos en el servidor, y el resultado debiera ser el mismo, es decir, que no hayan errores.  Si esto es así el cliente debe poder conectarse.

Paso 4: Conectando

Ahora viene la parte más divertida, hay que conectarse, si nuestro servidor es una instancia con nombre, que por ejemplo está escuchando en el puerto 1800 y hemos ejecutado telnet, que además responde bien, nada debería impedirnos conectar ¿Verdad?. Sin embargo en nuestra cadena de conexión ponemos eso de Data Source=SQLSERVER1\INSTANCE1 y aquello no conecta L que dececpción. Esto puede ser debido a que no esté levantado el servicio SQL Server Browser en el servidor también a que no esté abierto el puerto UDP 1434 que es donde SqlServer Browser estará esperando peticiones. 

Un alternativa es sustituir el nombre por el puerto, esto es algo comprometido, ya que si nos cambian el puerto, nuestra aplicación dejará de funcionar, en cualquier caso eso puede hacerse si se usa el comando  Data Source=SQLSERVER1,1433 (sustituyendo 1433 por el puerto en donde vuestro server esté escuchando).  Seguramente con esto ya funcione.

Más alternativas, podemos crear un alias dentro del configuration  manager, para eso hay que ir a Aliases, pulsar nuevo y rellenarlo con algo parecido a lo que podéis ver en la siguiente pantalla.

 

Algunas otras consideraciones

Establecer aliases puede ser más adecuado si estamos manejando replicación. La replicación en SQLServer 2005 comprueba que los nombres de server a los que estamos conectados coinciden con el nombre del servidor, es decir que hemos usado el nombre correcto para conectarnos, esto nos impide poder usar nombres como  SQLSERVER1,1433 y por tanto nos limita de alguna forma las alternativas, sin embargo el producto parece ganar en robustez.

No modifiquéis los archivos de host si no resuelve nombres, añadid los nombres a los DNS, si no , cuando vayáis a migrar vuestro servidor de nombre nada funcionará y no sabrás porque.

Si puedes evitar usar trucos, evítalo, todos ellos implican conocimientos y control, intentemos hacer que las instalaciones sean dependientes del rol y no de la persona J-

 

Conclusiones

El mundo de la conectividad con el server parece pequeño, pero no lo es, hay muchísimos factores que influyen en las comunicaciones y en las conexiones así que tenedlas siempre presentes cuando aparezcan problemas de conectividad.

 

Miguel Egea

Solid Quality Learning.