Regresando a lo basico: Diagnosticar conexión a SQL Server (Parte 2)

En el post anterior hablamos de como diagnosticar problemas de conexión, primero revisando que SQL Server estuviera encendido y funcionando, verificar los puertos y que no tuviéramos problemas por el contra fuegos o anti-virus, pero que pasa si esto aun falla.

Parte 1

Como en el articulo anterior debemos de hacernos unas preguntas para poder llegar a una deducción, método científico.

¿Puede alcanzar el otro servidor?

Esta es posible la pregunta más simple y con la contestación más fácil, hagamos un pequeño ping desde la linea de comando con

Ping <servidor remoto> ó Ping <ip servidor remoto>

o si estamos teniendo intermitencia en la conexión

Ping -t <servidor remoto> ó Ping -t <servidor remoto>

Es bueno realizar ambos debido a que en ocasiones es posible que el DNS no este resolviendo el nombre y aqui realmente radique el problema.

Llego pero aun así no me puedo conectar

Ping lamentablemente no es un comando TCP/IP y lo único que nos indica es si puede alcanzar el servidor en especifico, si queremos hacer una prueba un poco más certera usaremos Telnet, o un archivo UDL o portQry de Microsoft son buenas alternativas.

Con telnet

En una linea de comando

Telnet <ip> <puerto>

Con udl

Crean un archivo de texto vació, le cambian la extensión de .txt a .udl

Una vez tengan esto ponen los datos (también pueden probar contra Azure), solo pueden poner credenciales de SQL, en caso de que sean con Windows usara con las que están en ese momento.

PortQry

Portqry se puede utilizar con UI o por medio de linea de comando, en el link se explican ambos métodos pero una vez que lo descomprimamos veremos esto:

Al igual que en caso anterior podemos especificar SQL Server directamente o dar un puerto en especifico.

¿Si esto falla?

Aqui entramos en un área donde se vuelve más difícil el diagnosticar pero hagamos unos mismos pasos, asegurémonos de tener el puerto correcto y verificar que el servicio este en ejecución, revisemos el contra fuegos que no este bloqueando el regreso.

Si esto falla podríamos verificar el trafico en la red por medio de NETMON o Wireshark pero esto ya es más pertinente para un especialista en redes o un sysadmin.