¿Sabías que SQL Server implementa un sistema de conexiones de emergencia para cuando todo lo demás falla? Se llama DAC (Dedicated Admin Connection) y es una las puertas traseras que todo DBA tiene que habilitar en sus servidores SQL para poder acceder cuando el servidor está tan saturado que no responde. Más bien podríamos considerarlo una entrada de emergencia, si es que el término existe.
¿Qué es DAC y cómo funciona?
Como hemos comentado en la introducción DAC es una conexión dedicada para administradores que nos va a permitir acceder a nuestro servidor SQL Server aun cuando los problemas de rendimiento sean tan graves que nada más responda. Cuando habilitamos DAC y abrimos una conexión de esta manera, lo que realmente estamos haciendo es decirle a SQL Server que se reserve un hilo de proceso para nosotros, sea lo que sea que esté corriendo en otros procesos. Como habrás intuido, tiene un problema, no paraleliza, el hecho de reservar un único hilo de procesos va a hacer que si una consulta necesita paralelizar de error. Aun así, con un hilo de proceso va a ser suficiente para localizar la consulta o consultas que están saturando el servidor y poder detenerlas.
¿Tipos de DAC?
Antes de nada, DAC es un acrónimo común, en este artículo siempre nos referimos a las Dedicated Admin Connection. SQL Server también implementa una cosa llamada Aplicaciones de Capa de Datos que llama DAC Package pero no estamos hablando de eso, no tiene nada que ver con esto.
Ahora que tenemos esto claro, tenemos dos tipos de conexiones dedicadas para administradores y son en local o remotas. Cuando hablamos de conexiones DAC remotas vamos a verlo como RDAC o Remote Dedicated Admin Connection. DAC siempre está habilitado en SQL Server y no lo podemos deshabilitar, sin embargo, RDAC por defecto no lo está y tendremos que habilitarlo nosotros manualmente.
¿Por qué necesitas habilitar RDAC?
Como hemos visto, RDAC es lo mismo que DAC solo que de forma remota. Si podemos entrar al servidor de manera local y conectar por DAC, ¿por qué deberíamos habilitar RDAC? Muy fácil, estamos hablando de una puerta trasera para emergencias, casos en los que el servidor va a estar tan saturado que es posible que ni podamos conectar de manera local por terminal server. En esta situación, tener un endpoint a la escucha de manera remota que siempre está habilitado para acceder por muy mal que esté el servidor puede ser la diferencia entre tener que reiniciar el servidor o no. Y nunca querremos tener que llegar a reiniciar el servidor, ¿verdad?
Habilitar Remote DAC
A nivel de instancia, habilitar RDAC es tan sencillo como ejecutar el siguiente comando de configuración:
EXEC sp_configure 'remote admin connections', 1;
GO
RECONFIGURE
GO
Sin embargo, depende de la seguridad de tu red es probable que tengas que hablar con el administrador de redes para que te permita estas conexiones. Como hemos comentado antes por encima, Remote DAC usa un endpoint específico, lo que significa que no está a la escucha por el mismo puerto que las conexiones normales. Normalmente usará el puerto 1434 en vez del 1433. Asegúrate que el administrador de red te permite esas conexiones en el firewall antes de que tengas que echar mano de ellas y no vayas a poder.
Limitaciones de DAC
Tanto DAC como RDAC tienen las mismas limitaciones, y es normal, en el fondo son el mismo tipo de conexión. Esta limitación básica es que solo reserva un hilo de procesamiento por lo que solo vamos a poder tener una conexión abierta y ejecutar consultas sin paralelismo. Puedes pensar que es un gran hándicap pero, te aseguro que no. DAC no está pensado para trabajar normalmente ni para ejecutar planes de mantenimiento ni nada parecido. Solo es un método de acceso de emergencia para casos puntuales y, en esos casos, aun con esta limitación, es más que suficiente.
Por último, otra limitación es que solo van a poder usar este tipo de conexiones los usuarios sysadmin. Es lógico también, otro tipo de usuarios, aunque pudiesen acceder, no iban a poder solucionar la incidencia.
¿Cómo conectar usando DAC?
Ya sabemos casi todo lo necesario sobre DAC y por qué lo necesitamos, ahora bien, nos falta lo más importante, ¿cómo se usa?. Primero de todo dejame decirte que ojalá tengas la suerte de no necesitarlo nunca pero, como esto no es un mundo de fantasía, vamos a ver cómo vamos a tener que conectarnos. En este sentido tanto para conexiones en local (DAC) como para remotas (RDAC) es exactamente igual. En principio esta solución está pensada para conectarse desde una ventana de comandos con SQLCMD y para ello en la cadena de conexión usaremos el modificador -A. Sin embargo, tenemos la posibilidad de conectar también desde el SSMS con el prefijo “Admin:” antes del nombre del servidor.
El uso de SSMS tiene sus pegas, por un lado, aunque no es una limitación real, queda prácticamente limitado a conexiones RDAC ya que con el servidor completamente saturado rara vez vamos a poder ejecutar SSMS en local en un tiempo razonable. La segunda pega del uso de SSMS tiene que ver con el límite de sólo una conexión DAC simultánea y es que, SSMS, en concreto el explorador de objetos, ya consume más de una conexión. Por este motivo, su uso queda limitado a una conexión de una ventana de consultas exclusivamente.
Para conectar por una ventana de comandos usaremos los siguientes comandos:
Local (DAC):
sqlcmd -S servername -U sa -P <12ContraseñaUltra$egurisimaDeLaMuerte34> -A -d master
Remoto (RDAC):
sqlcmd -S servername,1434 -U sa -P <12ContraseñaUltra$egurisimaDeLaMuerte34> -A -d master
Es importante tanto el modificador -A para usar la conexión DAC como el “-d master” para especificar que conecte a esta base de datos. Esto se debe a que si la base de datos por defecto del usuario está offline la conexión va a fallar. De esta manera nos aseguramos que conectemos a la master y nos evitamos ese problema.
Conclusión
Gracias a las conexiones dedicadas para administradores DAC y RDAC vamos a poder garantizarnos un acceso de emergencia a nuestros servidores en caso de que todo lo demás esté fallando. Dedica unos minutos a habilitar RDAC en tus servidores y a validar su funcionamiento, así como, a familiarizarte con su uso por SQLCMD. No esperes a tener un problema para probar porque, en ese caso, es probable que el estrés del momento te juegue una mala pasada.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
