Infra

05
Nov
2025

El hardware se abarata, el licenciamiento de SQL Server no

Hace poco me compré un portátil nuevo. Un equipo serio, de esos con más núcleos que sentido común y potencia suficiente para levantar sin despeinarse un entorno de desarrollo completo con SQL Server, BI y lo que se le ponga por delante. Vamos, lo que necesito para las demos en los eventos. Precio: unos 2000€. Hasta aquí, todo bien.

Pero al mirar los procesadores disponibles (Ryzen con 16 o 24 núcleos, Intel con 20 y más RAM que la que tenía tu último servidor físico en producción) no pude evitar pensar: si alguien quiere usar esto para algo serio, ¿cómo lo licencia?

Y ahí es donde empieza el problema. Porque el precio del hierro ha bajado, pero el coste del licenciamiento de SQL Server sigue atascado en 2012. O antes.

El espejismo de la democratización

Nos han vendido la moto de que la informática se ha democratizado, que cualquiera puede montar un sistema potente por poco dinero, que digitalizarse es barato. Y en parte es verdad… hasta que levantas la alfombra del licenciamiento.

Cualquier pyme, autónomo o pequeño despacho que hoy quiera informatizar su gestión (pongamos que por exigencias tan poco opcionales como VERIFACTU) probablemente lo hará con lo que tiene a mano: un PC sobremesa moderno, o a lo sumo una torre decente con componentes actuales. Las pequeñas empresas no tienen presupuesto para servidores.

El problema es que hoy incluso un sobremesa “modesto” puede tener un procesador de 16 núcleos físicos y 128 GB de RAM por menos de 1500€. Y en ese momento SQL Server te sonríe… con su sonrisa de tiburón.

SQL Server Standard: paga por core, sufre por diseño

Si quieres usar SQL Server Standard en producción, aunque sea solo para almacenar facturas y cuatro tablas más, y te vas al modelo de licenciamiento por núcleo, prepárate: cada core te cuesta unos 2000 dólares. Sí, da igual que tu software solo use un hilo. Pagas por el número de núcleos visibles al sistema operativo, no por el uso real.

Y aquí viene lo bueno: en un PC moderno que no sea una patata, lo normal es que haya 12, 16 o 24 núcleos físicos (con el doble de vCores). Haz números. Eso son 24.000, 32.000, 48.000 o más euros solo en licencias, sin contar soporte, copias, backups, ni nada más.

Lo que iba a ser una digitalización económica se convierte en un agujero financiero. Y claro, muchos acaban optando por soluciones “temporalmente tolerables” como usar la versión Express… hasta que chocan de frente con sus limitaciones.

Express Edition: demasiado limitada para tomársela en serio

Sí, SQL Server Express es gratuita. Pero su techo de 10 GB por base de datos, 1 GB de RAM utilizable por instancia y uso de un único core lógico la hacen útil para pruebas, no para operar un negocio que mínimamente se tome en serio sus datos.

¿Que quieres hacer informes? Prepárate para sufrir. ¿Que tienes un CRM o un ERP que genera logs o almacena históricos? En dos años estarás exportando datos a Excel para aligerar. ¿Que necesitas rendimiento? Olvídalo.

La Express está bien para entornos de aprendizaje o microproyectos. Pero no está pensada para escenarios empresariales reales, por pequeños que sean.

La trampa del licenciamiento Server + CALs

Aquí algunos intentan una vía alternativa: el modelo de licenciamiento Server + CALs. Y sí, puede ser más asequible si solo tienes unos pocos usuarios y no quieres pagar por cada core.

Pero Microsoft te pone dos límites claros con SQL Server Standard bajo este modelo:

  • Máximo 24 núcleos virtuales visibles.
  • Máximo 128 GB de RAM utilizables.

Y aquí volvemos al drama. Porque un PC de 2025, sin ser nada del otro mundo, puede traer más de 12 núcleos físicos que son 24 virtuales (vCores) fácilmente. Y cuando eso pasa, no puedes usar Server + CALs legalmente. Te obligan a licenciar por core, aunque no necesites ni el 10% de los recursos. Maravilloso, ¿verdad?

Y no, no puedes decir “bueno, entonces limito el uso de cores desde el BIOS o desde el sistema operativo”. Eso no es legalmente vinculante para Microsoft. Si la CPU física tiene 32 núcleos, los vas a pagar todos. Así funciona el modelo de licencias.

En la nube también duele: SQL Server frente a PostgreSQL

Alguien podría pensar: “Vale, el licenciamiento físico es duro, pero si me voy al cloud me quito ese problema de encima, ¿no?”. Bueno… no exactamente. En la nube sigue siendo caro, y en algunos casos, directamente ridículo.

Vamos con cifras reales y actuales, para no caer en sensaciones vagas:

En Azure, una base de datos SQL con 8 vCores cuesta unos 893 dólares al mes. En el mismo entorno, una base de datos administrada de PostgreSQL con 8 vCores cuesta 123 dólares al mes. No es una diferencia. Es un abismo. Con lo que pagas por SQL puedes montar 7 PostgreSQL distintos y aún te sobra para un par de backups con redundancia geográfica.

Y si nos vamos a AWS, el panorama no mejora. Una instancia RDS de SQL Server con 16 vCores y 64 GB de RAM (db.m5.4xlarge) cuesta alrededor de 7.100 dólares mensuales. Sí, has leído bien: más de siete mil dólares al mes. Mientras tanto, la misma configuración con PostgreSQL cuesta 2.423 dólares mensuales. Casi tres veces menos.

Lo importante aquí no es solo el número. Es lo que implica: SQL Server no escala bien en costes. A mayor capacidad, mayor diferencia, y no precisamente a favor. PostgreSQL, en cambio, mantiene un coste racional y predecible, lo que lo hace mucho más viable en entornos que necesiten crecer sin hipotecarse.

Esto deja muy claro por qué tantos arquitectos de datos y CTOs están migrando workloads al open source. No porque les guste complicarse la vida, sino porque el presupuesto manda. Cuando el coste de mantener una base de datos supera al de todo el resto de la arquitectura, hay un problema, y no es técnico.

¿Qué opciones de licenciamiento tiene una pyme? Pocas, y ninguna es buena

Después de todo lo dicho, lo razonable es preguntarse: “¿Qué hago si necesito SQL Server, tengo un hardware moderno y no quiero fundirme el presupuesto en licencias?”

Pues no tienes muchas alternativas, realmente no hay una opción buena, solo algunas menos malas.

Primera opción de licenciamiento: SQL Express

Esta es la más obvia, SQL Express es gratis, sí, pero está muy limitada. Para empresas pequeñas con muy pocos datos puede ser una opción pero siempre con la vista puesta en sus límites. No solo hablo del hardware, que ya impone unos límites considerables (solo usa 4 vCores, 1 Gb de RAM y las bases de datos no pueden superar los 10Gb), sino que le faltan muchas características como el agente de SQL Server, SSIS, SSAS, etc… 

Aunque también es cierto que seguramente no necesites las aplicaciones de ETL o analítica y que la limitación del agente la puedas salvar ejecutando SQLCMD con tareas programadas en el programador de tareas de windows.

Segunda opción de licenciamiento : Licencias Server + CAL

La segunda opción es licenciar tu SQL Server Standard por Server + CALs… si puedes. Esto solo aplica a SQL Server Standard y si tienes un número limitado de usuarios bien controlado. Y no se aplica a entornos públicos, web apps o APIs abiertas. Si tu escenario es cerrado y sabes exactamente cuántos usuarios acceden, podría salirte más barato, unos 900€ la licencia del servidor SQL Server. Pero cuidado, porque CALs también cuestan y hay que contarlas bien, cada usuario que se conecte necesitará su CAL de aproximadamente 200€.
Pero recuerda, esta opción solo es posible si tu máquina tiene menos de 24 vCores. Y si te preguntas si puedes crear una máquina virtual con menos vCores para ahorrar dinero tengo una mala noticia, no es tan sencillo.
Para el licenciamiento de máquinas virtuales Microsoft exige licenciar todos los vCores de la máquina física así que estaríamos en las mismas. Por suerte hay un clavo ardiendo al que puedes agarrarte, es posible licenciar solo los vCores de la máquina virtual si, y solo si, contratas Software Assurance (SA). Este servicio es una suscripción de pago anual que te da derecho, además de a pagar solo por los vCores de la VM, a actualizaciones de versiones de SQL Server. Lo malo es que aquí no podemos hablar de precios, Microsoft no los comparte y tendrás que negociarlos con tu partner de licencias (suele costar anualmente entre un 20 y un 30% del coste de las licencias).

Tercera opción de licenciamiento: Cloud y pago por uso

Ya hemos visto que el coste de la nube no es barato, aun así, el pago mes a mes puede ser más fácil de asumir que el desembolso total de las licencias de una sola vez. Además, si tienes pocos requisitos de recursos, en Azure hay bases de datos sin servidor desde 5€/mes, con unos recursos muuuuy limitados, claro.

 Quedaría otra opción, abandonar SQL Server y mirar a la competencia pero eso ya no es tan sencillo, al menos para proyectos o desarrollos existentes. Oracle no es una opción, su coste por licencia es también por core y cuesta más del doble que SQL Server, pero no es la única alternativa.

PostgreSQL, MariaDB, o incluso SQLite: la fuga silenciosa

Cada vez más desarrolladores están abandonando SQL Server. No porque no funcione bien (que lo hace maravillosamente bien), ni porque no tenga features potentes (que las tiene geniales). Sino porque ya no es viable para ciertos escenarios.

PostgreSQL y MariaDB no imponen estas barreras. No cobran por core. Tampoco limitan la RAM. No te obligan a licenciar el procesador entero si solo usas dos hilos. Y, sinceramente, para el 80% de los casos de uso en empresas pequeñas, hacen el trabajo igual.

Eso si, que PostgreSQL o MariaDB no cobren por licencias no significa que sea gratis.

Porque cuando eliges PostgreSQL o MariaDB, te llevas el motor, pero no el soporte. Ni la monitorización. Ni el clúster. Tampoco la estrategia de backups. Ni la restauración en caliente. Todo eso hay que construirlo, mantenerlo… o pagarlo a una tercera empresa que lo haga.

Y aquí es donde muchas veces la factura no es tan diferente a SQL Server. Solo que el dinero no se va a Microsoft, sino a consultoras especializadas, soporte de terceros o a una inversión de tiempo interno brutal que acaba saliendo más cara de lo previsto.

También hay que reconocerlo, PostgreSQL tiene una curva de aprendizaje considerable, sobre todo si vienes de SQL Server. Lo que antes resolvías con Management Studio ahora implica línea de comandos, pg_dump, systemd, y a menudo, búsqueda en foros. Y que no te dé por hacer un clúster HA sin una herramienta externa, porque ahí es donde empiezas a pagar con sangre o con suscripciones.

Así que sí, hay motivos para migrar. Pero que no te vendan que todo es gratis. Porque no lo es. Y a veces, cuando te das cuenta, ya estás hasta el cuello de migración, y ni puedes volver atrás ni puedes pagar el camino nuevo.

Conclusión

La paradoja sigue ahí. El hardware moderno ha democratizado el acceso a CPUs potentes, pero SQL Server sigue licenciado como si cada core fuese un diamante. El resultado: una tecnología excelente, pero cada vez más difícil de justificar fuera de entornos que puedan asumir ese coste sin pestañear.

Las PYMEs, los autónomos y cualquier organización que pretenda informatizarse en serio sin vaciar su cuenta bancaria se topan con un muro invisible: el licenciamiento. Un muro que no distingue entre portátil, sobremesa o servidor, y que tampoco afloja si te mudas a la nube.

Y sí, SQL Server 2025 está en puertas, con la Release Candidate ya disponible. Pero no parece que el modelo de licencias vaya a cambiar. Ojalá me equivoque y Microsoft suba ese límite absurdo de 24 vCores para el Server + CAL. Pero no creo.

Mientras tanto, PostgreSQL y compañía siguen ganando terreno. No por ideología, sino por supervivencia económica.

Y si esto te parece exagerado, revisa tu próxima factura de Azure o AWS. O tu presupuesto para licencias on-prem. Verás que la exageración no está en el artículo. Está en el modelo.

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
26
Sep
2025

Opciones de Quorum para un clúster Always On

Sí, lo sé. Esto no va de índices columnstore ni de Extended Events sacando fuegos artificiales ni nada propiamente de bases de datos. Esto va de Quorum. Ese componente del clúster de Windows que muchos DBAs miran de reojo con la misma ilusión con la que uno revisa un log de errores a las 6 de la mañana. Pero si te metes en el barro de Always On, más te vale entender cómo funciona. Porque si el Quorum no está bien configurado, tu clúster puede caerse por una tontería. Y no, no da igual poner un disco o un voto más aquí o allá. Aquí no venimos a improvisar.

Este artículo no es tanto de SQL Server como de administración de sistemas, pero es un conocimiento que cualquier DBA serio necesita tener controlado. No porque vayamos a montar los clústeres a mano (que también), sino porque cuando empiecen los problemas, nadie va a buscar al sysadmin de guardia. Primero te van a buscar a ti.

El Quorum no es una opinión

Primero, vamos al grano: ¿qué demonios es el Quorum y por qué nos debería importar?

El Quorum es un mecanismo que usan la mayoría de los clúster, incluido el de Windows Server (WSFC, Windows Server Failover Cluster), para decidir si puede seguir funcionando. No estamos hablando de algo estético. Si el clúster pierde el Quorum, se apaga. Así de simple. O, peor aún, se divide y entra en split-brain, ese estado esquizofrénico donde dos nodos piensan que son los jefes, pero en realidad nadie manda. Un poco como algunas reuniones entre directores de distintos departamentos.

Así que no, el Quorum no es un «detalle más». Es un componente crítico del diseño. Y en el caso de Always On Availability Groups, que se basan en WSFC, ignorarlo es como montar un Ferrari y pasar de los frenos.

Tipos de Quorum en WSFC

Windows Server ofrece varias configuraciones de Quorum. Cada una con sus ventajas, sus pegas y sus peligros ocultos. No son intercambiables ni da igual cuál elijas. Vamos a repasarlas, una a una.

Node Majority (Mayoría de nodos)

Es el más sencillo, cada nodo tiene un voto, y si más de la mitad están activos y comunicados, el clúster sigue funcionando. Normalmente se usa en entornos con número impar de nodos (3, 5…). Es el ideal cuando todos los nodos están en el mismo datacenter o con conexiones fiables.

Su principal ventaja es su simplicidad de configuración, no necesita recursos compartidos adicionales y mantiene la alta disponibilidad mientras haya mayoría.

El inconveniente es que en un clúster con número par de nodos, el riesgo de perder Quorum por una simple caída es real. Además no escala bien para entornos geográficamente distribuidos.

Si montas un clúster de 2 nodos con esta configuración, estás invitando a que se caiga con solo un reboot. Lo llaman “configuración de alto riesgo”.

Node and Disk Majority (Mayoría de nodos y disco testigo)

Aquí añadimos a los nodos un testigo en forma de disco compartido (usualmente un LUN en un SAN), que también vota. Es perfecto para evitar empates en clústeres con número par de nodos. Se usa mayoritariamente cuando tiene clústeres con número par de nodos en el mismo datacenter.

Sigue siendo fácil de configurar si tienes un SAN compartido y evita el split-brain. 

El problema es que el disco es un punto de fallo más. Si falla el disco y un nodo, te vas al suelo. Y si hablamos de Always On con réplicas distribuidas en varios sitios, esta opción no aplica.

¿Un único punto de fallo en una configuración de alta disponibilidad? Brillante.

Node and File Share Majority (Mayoría de nodos y recurso compartido)

En este caso sustituimos el disco testigo por un File Share Witness (FSW), alojado en un servidor accesible por red. No necesita almacenamiento compartido, solo conectividad SMB. Su uso está extendido entre clusters distribuidos o donde no hay almacenamiento compartido disponible.

Es flexible y fácil de montar y, cómo no dependes de un SAN, es ideal para Always On entre sitios.E inconveniente es que el recurso compartido debe estar SIEMPRE disponible y accesible desde todos los nodos. Si cae la conectividad, puede hacer más daño del que parece.

Sí, ese FSW que “nadie sabe muy bien dónde lo pusimos” puede ser lo que decida si tu clúster sobrevive o se apaga. Más vale que esté monitorizado.

No Majority: Disk Only (Solo disco)

Aquí no hay mayoría. El disco decide. Y si el disco falla, adivina qué más falla.

¿Cuándo se usa? La respuesta correcta es NUNCA. O, como mucho, en entornos de laboratorio. No hay excusa para usar esta configuración en producción.

Como ventajas de este tipo de Quorum podríamos destacar NINGUNA y como inconvenientes TODOS: Alta fragilidad, nula tolerancia a fallos. No compatible con Always On.

Si ves esto en un entorno real, haz un RDP al nodo, abre un bloc de notas y escribe tu carta de despido preventivo.

Votos, pesos y cómo romper el clúster sin querer

No basta con elegir el tipo de Quorum. También hay que entender cómo se distribuyen los votos. Cada nodo, por defecto, tiene un voto. Pero puedes ajustar manualmente qué nodos votan. Y también puedes decirle al testigo (FSW o disco) si vota o no.

Esto es útil, pero también peligroso. Quitar votos a la ligera puede provocar que el Quorum se pierda con menos fallos de los que imaginas. Y confiar ciegamente en que “Windows lo ajusta solo” es un camino directo al caos. WSFC puede hacer ajustes automáticos, sí, pero no es infalible. El clúster no tiene bola de cristal.

¿Un ejemplo real? Un clúster de 4 nodos con dos en cada datacenter y un FSW mal ubicado. Si cae la conectividad entre sitios y el testigo queda del lado equivocado, puedes perder todo. Porque, como en las películas malas, gana el lado que tenga más votos. Aunque no tenga la base de datos principal.

Always On y el testigo olvidado

En los grupos de disponibilidad de Always On, mucha gente se obsesiona con los réplicas, los listeners, las rutas de red… y se olvidan del Quorum. Error.

Una réplica en modo síncrono con failover automático NO te sirve de nada si el Quorum no se mantiene en caso de caída. La réplica puede estar perfecta, lista para levantar el grupo, pero si el clúster ha perdido el Quorum, no se produce el failover. Porque el WSFC está abajo. Fin.

Por eso, en entornos con réplicas distribuidas geográficamente, el testigo (FSW) debe estar ubicado estratégicamente. Idealmente, en un tercer sitio con conectividad simétrica. Si no puedes, al menos asegúrate de que el Quorum esté configurado con cabeza.

Y no, no pongas el FSW en uno de los nodos del clúster. No es que vaya a fallar, pero síes una muy mala idea. Es como guardar las llaves de la caja fuerte… dentro de la misma caja.

Casos típicos y cómo configurarlos bien

A modo de ejemplo vamos a repasar las configuraciones más recomendadas en los escenarios más comunes.

  • Clúster de 2 nodos en el mismo datacenter: Node and File Share Majority. FSW en un servidor externo y altamente disponible. Nada de ponerlo en uno de los nodos.
  • Clúster de 3 nodos: Node Majority. Número impar, no hace falta testigo, salvo que tengas paranoia (bien justificada). Si los tres nodos están en ubicaciones distintas, replantéate la estrategia.
  • Clúster con réplicas entre datacenters: Node and File Share Majority. FSW en una tercera ubicación. Y no, “la nube” no es una tercera ubicación si no tienes garantizada la conectividad.

Conclusión

Como muchas cosas en administración de sistemas, el Quorum es esa parte invisible que solo duele cuando falla. Pero cuando falla, duele de verdad. Si gestionas entornos con Always On y no entiendes bien cómo se comporta el Quorum, estás conduciendo a ciegas. Y algún día, te vas a estrellar.

No hace falta que seas un experto en WSFC, pero necesitas saber cómo se configura el Quorum, cómo afecta a la disponibilidad real de tu clúster y, sobre todo, cómo evitar caer en las trampas típicas. Porque no, Always On no lo gestiona “todo solo”. Tú sigues siendo responsable de que el clúster se mantenga vivo. Y para eso, el Quorum es tu piedra angular.

Así que la próxima vez que montes un clúster, o revises uno existente, pregúntate: ¿está el Quorum bien diseñado o estoy viviendo con una bomba de relojería? Porque en producción, el Quorum no perdona.

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! 

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
24
Sep
2025

Canalizaciones por nombre (Named Pipes) en SQL Server

Durante años, las canalizaciones por nombre (Named Pipes) han sido uno de esos protocolos de red que viven en las sombras de TCP/IP. Están ahí, aparecen en las configuraciones del SQL Server Configuration Manager, y de vez en cuando algún alma valiente pregunta si debería activarlas “por si acaso”. Y no, por si acaso no es un argumento válido en administración de sistemas, y mucho menos en bases de datos. Vamos a analizar qué son exactamente, cómo funcionan y en qué escenarios podrían tener sentido… si es que alguno queda en 2025.

¿Qué demonios son las canalizaciones por nombre?

Antes de decidir si las activamos o las dejamos durmiendo el sueño de los justos, conviene entender qué son. Las canalizaciones con nombre son un mecanismo de comunicación interprocesos (IPC) heredado del glorioso mundo de Windows NT. Permiten que dos procesos, incluso en máquinas diferentes, se comuniquen a través de una ruta virtual. En SQL Server, representan uno de los protocolos disponibles para aceptar conexiones de cliente.

Mientras que TCP/IP utiliza direcciones IP y puertos, Named Pipes utiliza una sintaxis como \\.\pipe\sql\query, y en red sería algo tipo \\Servidor\pipe\sql\query. Esta vía de comunicación puede ser más rápida en entornos muy controlados y locales (léase: conexión directa entre un cliente y un servidor dentro de la misma LAN y sin cuellos de botella), pero en la práctica actual… hay que hilar muy fino para justificar su uso.

TCP/IP vs Canalizaciones por nombre: ¿por qué seguimos hablando de esto?

La realidad es que TCP/IP es el protocolo estándar y recomendado para conexiones SQL Server, tanto en producción como en desarrollo. Es más robusto, más flexible, y más preparado para escenarios reales con múltiples capas de red, firewalls, balanceadores, NATs y demás fauna moderna.

Entonces, ¿por qué SQL Server sigue ofreciendo Named Pipes como opción? Por compatibilidad. Porque aún hay sistemas legacy que las usan. Y porque a Microsoft le cuesta soltar lastre tanto como a cualquiera que aún mantiene SQL Server 2008 en alguna esquina de su datacenter “temporal”.

Hay entornos donde, por motivos históricos o arquitecturas muy específicas, se configuraron conexiones a SQL Server utilizando Named Pipes. En esos casos, sí, deshabilitarlas podría romper algo. Pero esa es la excepción, no la norma.

¿Cuándo tienen sentido las Named Pipes?

Vale, no todo es blanco o negro. Hay escenarios, pocos pero existentes, donde las canalizaciones por nombre pueden tener cierta ventaja:

  • Conexiones locales (cliente y servidor en la misma máquina): En algunos benchmarks internos de Microsoft (de hace más de una década nada menos), se observó que el rendimiento de Named Pipes en conexiones locales era ligeramente superior al de TCP/IP. Pero, francamente, si ese es tu cuello de botella, tienes problemas mayores.
  • Autenticación integrada en entornos Windows puros: Las canalizaciones por nombre pueden simplificar ciertos escenarios de autenticación integrada en entornos totalmente controlados por Active Directory. Pero otra vez: TCP/IP también lo hace sin problemas.
  • Entornos legacy que no quieres (o puedes) tocar: Si tienes una aplicación que explícitamente se conecta usando np: o configuraciones hardcoded de canalizaciones con nombre, y no puedes modificarla… entonces no queda otra que habilitarlas.
  • Solución de problemas puntuales: En algunos casos, cuando el acceso por TCP/IP falla misteriosamente (DNS, puertos bloqueados, fuegos en el CPD…), usar Named Pipes puede servir para diagnosticar si SQL Server sigue vivo y coleando.

Pero si tu escenario no cae en alguno de estos puntos, las Named Pipes sobran.

Cómo funcionan realmente las canalizaciones por nombre

Cuando habilitas Named Pipes en SQL Server, el motor escucha en una canalización concreta: \\.\pipe\sql\query por defecto. El cliente debe conectarse utilizando ese nombre. Lo que muchos no saben es que esto no solo requiere que el cliente conozca la sintaxis, sino también que la resolución de nombres esté bien configurada (en red), y que no haya firewalls bloqueando el tráfico correspondiente.

Además, en entornos remotos, el protocolo puede comportarse de forma bastante torpe: mayor latencia en la negociación, más complejidad en el tráfico de red, y más exposición a errores difíciles de diagnosticar. Si te suena a dolor de cabeza… es porque lo es.

¿Qué pasa si dejo las canalizaciones por nombre activadas “por si acaso”?

Esto es como dejar todas las ventanas de casa abiertas por si te olvidas las llaves. En teoría podría ayudarte, pero en la práctica te estás exponiendo innecesariamente. Habilitar las canalizaciones por nombre sin necesitarlas abre un vector de ataque innecesario (sí, también hablamos de superficie de ataque), complica el troubleshooting de conexiones, y puede provocar que clientes mal configurados intenten conectar usando este protocolo en lugar de TCP/IP.

Por si fuera poco, cuando están activadas, SQL Server puede priorizarlas en la cadena de protocolos, lo que lleva a situaciones surrealistas como que un cliente tarde más de la cuenta en conectarse porque está intentando usar Named Pipes antes que TCP/IP.

Lo peor de todo es que, en redes modernas, usar Named Pipes puede ralentizar la conexión en lugar de mejorarla. Así que eso de activarlas para “ganar velocidad” es un mito que ya deberíamos haber dejado atrás con el disquete.

¿Y si las necesito, cómo las activo (o desactivo)?

Si a pesar de todo necesitas activar Named Pipes, el proceso es sencillo, pero no inmediato. Desde SQL Server Configuration Manager, accede al protocolo correspondiente bajo SQL Server Network Configuration, y ahí puedes habilitarlas o deshabilitarlas. Necesitarás reiniciar el servicio SQL Server para que los cambios tengan efecto.

Además, si vas a usarlas, asegúrate de configurar también correctamente la cadena de conexión en el cliente, usando el prefijo np: para forzar que se utilicen Named Pipes.

Y, por supuesto, monitoriza. No asumas que todo va mejor solo porque te conectaste. Comprueba latencias, errores, y la experiencia real del usuario. Porque los milagros no vienen de las canalizaciones.

¿Qué protocolo prioriza SQL Server?

El orden de los protocolos es importante. SQL Server Native Client (o el driver OLE DB / ODBC que uses) sigue un orden al intentar conectar, salvo que lo fuerces. Ese orden se define también en SQL Server Configuration Manager, y puedes modificarlo.

Si dejas Named Pipes activado y en primer lugar, el cliente intentará primero por ahí antes de probar TCP/IP. Si Named Pipes no está disponible o hay problemas de red, el tiempo de espera puede incrementarse de forma absurda. ¿Te suenan esas conexiones que tardan 20 segundos solo en conectar? Pues eso.

Conclusión

Las canalizaciones por nombre son como el fax, aún existen, aún funcionan, y hay quien defiende que tienen utilidad. Pero en la mayoría de escenarios modernos con SQL Server, no hay ninguna razón técnica sólida para tenerlas activadas si no se están usando.

No aportan ventaja real frente a TCP/IP, complican el diagnóstico, abren superficie de ataque, y pueden ralentizar la conexión. Si tu entorno las requiere, adelante, pero hazlo con conocimiento de causa. Si no sabes para qué las necesitas, es que no las necesitas.

Apaga las Named Pipes, reinicia tu SQL Server y duerme tranquilo sabiendo que has reducido complejidad innecesaria.

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 LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
22
Sep
2025

El libro de SQL Server que estabas esperando

Después de más de una década trabajando con SQL Server y ahora compartiendo contenido en SoyDBA, estoy escribiendo un libro pensado para profesionales que quieren ir más allá de la documentación oficial. Un libro técnico y muy didáctico.

Más de 40 capítulos en 7 partes, desde los fundamentos del modelo relacional hasta las herramientas de diagnóstico más avanzadas. Un recorrido completo, pensado para DBAs, analistas y desarrolladores que quieren entender cómo funciona SQL Server de verdad.

Portada Libro

El prólogo lo firma Fernando G. Guerrero, pionero y referente en nuestra comunidad. La contraportada, Juanjo Luna, MVP de Access y más apasionado de SQL de lo que quiere reconocer. Os dejo aquí el texto de la contraportada:

No os voy a engañar; comercialmente, este libro va a ser un fracaso. Escribir más de 200 hojas hablando de un tema que no es de uso práctico, es algo que nadie quiere hoy en día.

Su propia portada ya lo indica: La no guía práctica …

En medio de una sociedad en la que lo que vende es el producto rápido de consumo inmediato, con soluciones mágicas; pretender sacar un producto de este tipo significa ser un… Déjame que busque la palabra… ah sí: MVP

Leyendo el libro, me venía a la cabeza que tenía entre manos el test de la ITV de los DBAs. Si no dominas lo que pone en el libro y gestionas servidores y/o bases de datos, tienes un problema.

¿Por qué deberías leer este libro?

Si eres un neófito del tema, que tan solo consume servicios de datos, sin saber lo que hace, este libro es un itinerario fantástico para saber cómo adentrarte en el mundo de los DBAs.

Para el ya iniciado es el test perfecto para descubrir todo lo que le falta por saber. Cuánto habría dado hace años por tener algo así para poder elegir como progresar, de manera independiente en la gestión de mis servidores de datos.

Si por el contrario, eres realmente un experto, el mero hecho de compartir conocimientos con Roberto Carrancio, es un disfrute que solo los grandes entendidos pueden comprender.

Seas el tipo que seas, el libro que tienes entre manos, no te hará experto en nada; pero te abrirá las puertas para que puedas llegar a serlo.

Escribir este libro justo ahora en el que todo el mundo busca cómo utilizar la IA para que haga las cosas sin necesidad de entenderlas es un error absoluto….

O TAL VEZ NO.

Si quieres conseguirlo corre a Amazón.

El libro está disponible en Amazon en formato papel y Kindle en todo el mundo.

Consigue el libro aquí

Mantente al día de las novedades con mi newsletter gratuita

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, Índices, Rendimiento, SQL Server, 0 comentarios
19
Sep
2025

Backups en SQL Server Always On y novedades en SQL Server 2025

Llevamos años con Always On sobre la mesa, vendiéndolo como la solución de alta disponibilidad y recuperación ante desastres por excelencia en entornos SQL Server. Cuando alguien monta un Availability Group por primera vez, suele pensar que ya tiene resuelta la alta disponibilidad, la recuperación ante desastres, los backups, el estrés y la hipoteca. Y no es mentira, pero tampoco es magia. Quienes lo gestionamos sabemos que montar un AG (Availability Group) es fácil en demos, pero bastante más delicado en producción. Always On resuelve cosas, sí, pero también introduce otras que hay que entender, especialmente cuando hablamos de estrategias de backup.

Y es que, hasta ahora, hacer backups en réplicas secundarias era poco más que un “parche”. Con SQL Server 2025, Microsoft ha introducido una mejora que, aunque llega tarde, se agradece: la posibilidad de hacer backups completos, diferenciales y de logs directamente sobre una réplica secundaria. Vamos a ver qué cambia exactamente y cómo podemos (por fin) diseñar estrategias de backup decentes en entornos Always On.

¿Dónde se hacen los backups en un Availability Group?

Empecemos con lo básico, que no es tan obvio como parece. En un AG, todas las réplicas tienen una copia de la base de datos, pero no todas son iguales ni sirven para todo. A la hora de hacer backups, SQL Server nos permite controlar el comportamiento a través de dos configuraciones clave:

AUTOMATED_BACKUP_PREFERENCE: una propiedad del Availability Group que indica en qué réplica se deben lanzar los backups automáticos (es decir, los lanzados mediante SQL Server Agent, Maintenance Plans, etc.). Esta propiedad puede tomar los valores:

  • PRIMARY: sólo se hacen backups en la réplica primaria.
  • SECONDARY_ONLY: sólo se hacen en las réplicas secundarias.
  • SECONDARY: se prefiere una secundaria, pero se usa la primaria si no hay otra disponible.
  • NONE: no hay preferencia definida, el agente decide.

BACKUP_PRIORITY: una propiedad individual de cada réplica que define su peso relativo a la hora de ser elegida para realizar los backups, si hay varias candidatas disponibles según la preferencia anterior.

Con estas dos configuraciones combinadas, SQL Server decide en qué réplica ejecutar los backups cuando se utilizan herramientas automatizadas. Pero ojo: si ejecutas el backup manualmente (T-SQL, PowerShell, etc.), se lanza en la réplica donde estés conectado. Lo de la preferencia solo aplica en los automatismos.

Logo SoyDBA

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Tipos de backups permitidos hasta SQL Server 2022

Ahora bien, no todos los tipos de backup están permitidos en todas las réplicas. Hasta SQL Server 2022 (incluido), las reglas eran bastante limitantes.

Los backups completos (FULL) sólo están permitidos en la réplica primaria, salvo que sean COPY_ONLY, en cuyo caso sí se pueden hacer en réplicas secundarias. Los backups diferenciales (DIFFERENTIAL) tienen el mismo “problema”, únicamente se pueden hacer en la primaria. Por el contrario, los backups de log (TRANSACTION LOG) si se pueden hacer en cualquier réplica (primaria o secundaria), siempre que esté en estado sincronizado o aceptable. Y son válidos como parte de la cadena de recuperación.

En resumen, solo los logs son realmente “migrables” a réplicas secundarias de forma productiva. El resto, si no es COPY_ONLY, requiere pasar por la primaria. Y como ya sabemos, los COPY_ONLY no afectan a la cadena de backups, por lo que no sirven como parte del plan de recuperación principal.

Este escenario genera el clásico problema, la carga de los backups importantes (full y diff) sigue recayendo en la réplica primaria, justo la que está ejecutando cargas de producción críticas. Y claro, luego vienen los lloros por I/O, CPU y ventanas de mantenimiento.

¿Qué cambiará en los backups de AG con SQL Server 2025?

Aquí llega la buena noticia. A partir de SQL Server 2025 (en preview), Microsoft amplía por fin el soporte de backups en réplicas secundarias. Y esta vez de verdad: Ya se podrán hacer backups FULL, DIFFERENTIAL y LOG en réplicas secundarias. Y no en modo COPY_ONLY, sino como parte activa de la cadena de recuperación.

Esto significa que podremos rediseñar completamente nuestra estrategia de backups en entornos Always On. Por ejemplo, podremos mover el backup completo diario a una secundaria, programar los diferenciales en otra y dejar los logs en una tercera. Todo sin tocar la primaria.

Y lo mejor es que no habrá que cambiar nada en la configuración actual del AG. Si ya tenemos configurado AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY y hemos definido prioridades con BACKUP_PRIORITY, esas mismas reglas se aplicarán también a full y diferenciales. Lo único que cambia es lo que SQL Server permitirá hacer técnicamente en cada réplica.

Cómo configurarlo (y cómo comprobarlo)

La configuración es la misma de siempre, para ver el valor actual de la preferencia de backups del AG podemos usar:

SELECT automated_backup_preference_desc FROM sys.availability_groups;

Para ver la prioridad de backup por réplica:

SELECT replica_server_name, backup_priority FROM sys.availability_replicas;

Y, si necesitas modificar la preferencia:

ALTER AVAILABILITY GROUP [NombreDelAG]
SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY);

Y podrás seguir usando la vista sys.dm_hadr_backup_is_preferred_replica para determinar en tiempo real cuál es la réplica preferida según la configuración actual. Ideal para integrarlo en scripts de backup personalizados.

Consideraciones importantes y limitaciones

Como todo cambio de este tipo, hay que tener claro qué implica antes de correr a modificar tus scripts. La réplica secundaria debe estar sincronizada y en estado ONLINE. No sirve una réplica desactualizada o en SUSPENDED. Por supuesto, el backup de log seguirá necesitando una cadena coherente. Como hasta ahora, puedes hacer logs desde réplicas secundarias, pero asegúrate de que tu estrategia de restauración tiene en cuenta su procedencia.

El restaurado no cambiará, si haces un FULL en una secundaria, un DIFF en otra y LOGs en una tercera, tendrás que restaurarlos todos en orden, desde sus respectivas ubicaciones. Esto requiere un buen control del sistema de almacenamiento y del catálogo de backups.

Por último, el rendimiento de las réplicas secundarias importa. No pienses que es buena idea mandar todos los backups a una secundaria con discos lentos y CPU de museo. Es posible, sí. Recomendable, no.

¿Cómo adaptar tu estrategia de backups?

Con esta mejora, por fin podremos plantear una estrategia de backups moderna para Always On, que de verdad aproveche la arquitectura del AG. Algunas ideas:

  • Mueve los FULL y DIFF a réplicas secundarias bien dimensionadas.
  • Mantén los LOGs distribuidos según disponibilidad, pero con control estricto del histórico.
  • Diseña tus planes de mantenimiento con tolerancia a failover: si una réplica cae, otra puede asumir su rol.

Eso sí, no pierdas de vista que toda esta flexibilidad requiere más disciplina. El seguimiento de los backups, la monitorización y la política de retención deben estar muy claros. Porque ahora no hay excusas: puedes repartir la carga, pero también puedes complicarte la vida si no lo haces bien.

Conclusión

SQL Server 2025 traerá una mejora largamente esperada. Por fin podremos hacer backups completos y diferenciales en réplicas secundarias, de forma nativa y como parte del plan de recuperación. No es un parche ni una opción limitada, es un cambio real en cómo el motor entiende las responsabilidades de cada réplica.

Y si aún haces todos los backups desde la primaria, empieza a preguntarte por qué. Porque a partir de ahora, no es que se vaya a poder evitar: es que deberías.

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 LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 0 comentarios
08
Sep
2025

Novedades sobre el libro

Después de meses de trabajo, revisiones y mucha paciencia, puedo compartir tres novedades clave del libro SQL Server: La NO guía práctica de optimización:

  • El prólogo lo firma Fernando G. Guerrero, pionero en SQL Server y miembro histórico de la comunidad. Además de escribir unas palabras introductorias, ha contribuido en la revisión técnica.

  • Aquí está el índice completo, con los más de 40 capítulos organizados en 7 partes.

  • Y sí: la fecha de lanzamiento ya es oficial. El libro estará disponible a mediados de septiembre. Pronto os diré el día exacto

Índice completo

Parte 1 – Fundamentos del modelo relacional y la arquitectura
Desde la definición de base de datos relacional hasta la estructura física de páginas y archivos. El punto de partida sólido para entender qué hay detrás de cada consulta.

Parte 2 – T-SQL y construcción de consultas eficientes
SELECT, INSERT, UPDATE y DELETE como base, y a partir de ahí subconsultas, CTEs, funciones de ventana, vistas, procedimientos y ejecución de consultas. Todo lo que necesitas para escribir SQL que funcione en producción.

Parte 3 – Transacciones, concurrencia y aislamiento
Propiedades ACID, niveles de aislamiento, bloqueos, deadlocks y el nuevo modelo de bloqueos optimizados. Una sección clave para quien de verdad administre entornos críticos.

Parte 4 – Internals, configuración y mantenimiento
TempDB, almacenamiento, memoria, CPU, cardinalidad, parametrización, índices, estadísticas y particionado. La cocina interna del motor y cómo configurarlo sin hipotecar el rendimiento.

Parte 5 – Backup, recuperación y disponibilidad
Modelos de recuperación, estrategias de backup, restore, Log Shipping, Database Mirroring y Availability Groups. Todo lo que sostiene la continuidad de un entorno SQL Server serio.

Parte 6 – Seguridad y control de acceso
Principales, usuarios, roles, permisos y técnicas avanzadas de seguridad. Desde lo básico hasta RLS, cifrado y enmascaramiento de datos.

Parte 7 – Control, monitorización y diagnóstico
Herramientas internas y externas: Resource Governor, Activity Monitor, DMVs, Profiler, Extended Events, Query Store y PerfMon. Para que no solo administres, sino que entiendas qué ocurre bajo el capó.

Con este índice ya podéis ver que no es un manual de recetas rápidas, sino una guía estructurada de principio a fin para profesionales de SQL Server.

El lanzamiento será a mediados de septiembre y os avisaré en cuanto esté disponible en Amazon.

Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 0 comentarios
05
Sep
2025

Restringir el acceso a SQL Server por IP

A estas alturas de la película, todos los que llevamos tiempo en esto de la administración de SQL Server hemos recibido la misma pregunta en más de una ocasión: “¿Se puede bloquear el acceso a SQL Server según la máquina desde la que se conecta un usuario?” Spoiler: sí, se puede, pero no de la manera que muchos esperan. Y no, SQL Server no tiene un checkbox mágico para esto. Hay que ensuciarse las manos. Y aquí es donde entramos nosotros.

Lo que SQL Server no puede hacer (al menos por defecto)

No existe, al menos hasta el día de hoy, ninguna opción nativa en SQL Server que permita vincular un login a una IP específica. Ni en el Management Studio, ni en el registro, ni en las opciones avanzadas. No busques, que no está. Y no, tampoco hay un parámetro oculto de configuración que habilite esto.

Así que si lo que esperabas era marcar una casilla para decir “este login solo se conecta desde esta IP”… puedes dejar de leer aquí. Pero si estás dispuesto a ir un poco más allá, porque lo estás, hay una solución elegante (y eficaz): usar un trigger de tipo LOGON.

¿Un trigger de inicio de sesión? Sí, y bien usado

SQL Server permite crear triggers a nivel de servidor que se ejecutan justo cuando un usuario intenta iniciar sesión. Y es ahí donde podemos interceptar la conexión, comprobar desde qué IP se está intentando conectar, y decidir si le damos la bienvenida… o le cerramos la puerta en la cara.

Para obtener la IP del cliente, podemos usar la vista sys.dm_exec_connections, que nos da, entre otros muchos datos, la dirección desde la que se está estableciendo la sesión actual. Esa es la base de todo este invento.

Primer ejemplo: el caso clásico del login sa

Empezamos por el escenario más sencillo: restringir el acceso del usuario sa a una IP concreta (o, mejor aún, solo permitirle conexión desde el propio servidor).

Este es un ejemplo de trigger directo y sin florituras:

CREATE TRIGGER [RestrictSALogin]
ON ALL SERVER
FOR LOGON
AS
BEGIN
    DECLARE @client_ip VARCHAR(48);
    SELECT @client_ip = client_net_address
    FROM sys.dm_exec_connections
    WHERE session_id = @@SPID;

    IF ORIGINAL_LOGIN() = 'sa' AND @client_ip NOT IN ('192.168.101.202','<local machine>')
    BEGIN
        ROLLBACK;
        PRINT 'Acceso denegado para sa desde una máquina no autorizada.';
    END
END;
GO

Y ya está. Este trigger bloquea cualquier intento de conexión con el usuario sa desde una IP que no sea la del propio servidor o la que hayas indicado. Simple, efectivo y… sí, peligroso si no documentas bien la IP que estás autorizando. Porque si te equivocas y te bloqueas a ti mismo, te va a tocar entrar por modo seguro, y no será divertido.

Segundo escenario: múltiples usuarios, múltiples IPs

Ahora, pongámonos serios. No vas a crear un trigger por cada usuario. Ni tú, ni nadie. Para algo tenemos bases de datos. Vamos a externalizar la lógica de IPs permitidas en una tabla, y a hacer que el trigger se alimente de ahí.

Primero, creamos una base de datos auxiliar de configuración, por ejemplo ConfigSeguridad, y dentro, dos tablas: una con los logins permitidos y sus IPs, y otra (opcional) para registrar intentos fallidos de acceso.

CREATE DATABASE ConfigSeguridad;
GO
USE ConfigSeguridad;
GO
CREATE TABLE LoginsPermitidos (
    NombreUsuario NVARCHAR(100) NOT NULL,
    IPPermitida NVARCHAR(48) NOT NULL -- 'TODAS' si no hay restricción
);

Ahora podemos rellenarla con la lógica que queramos. Por ejemplo:

INSERT INTO LoginsPermitidos (NombreUsuario, IPPermitida) 
VALUES 
    ('sa', '192.168.101.225'),
    ('sa', '<local machine>'),
    ('admin', 'TODAS'),
    ('usuario1', '192.168.104.134');

Sí, aquí admitimos la palabra clave ‘TODAS’ como forma elegante de decir “este login puede conectarse desde cualquier parte del mundo, hasta desde el tren si hace falta”.

Y aquí viene el trigger maestro:

CREATE TRIGGER RestriccionLogins
ON ALL SERVER
WITH EXECUTE AS N'sa'
FOR LOGON
AS
BEGIN
    DECLARE @IPCliente NVARCHAR(48);
    DECLARE @NombreUsuario NVARCHAR(100);

    SELECT @IPCliente = client_net_address
    FROM sys.dm_exec_connections
    WHERE session_id = @@SPID;

    SET @NombreUsuario = ORIGINAL_LOGIN();

    IF NOT EXISTS (
        SELECT 1
        FROM ConfigSeguridad.dbo.LoginsPermitidos
        WHERE NombreUsuario = @NombreUsuario
          AND (IPPermitida = @IPCliente OR IPPermitida = 'TODAS')
    )
    BEGIN
        ROLLBACK;
        PRINT 'Acceso denegado: Usuario o IP no autorizados.';
    END
END;
GO

Este trigger es mucho más flexible. Puedes dar acceso a múltiples usuarios desde múltiples IPs, sin tener que tocar el código. Solo modificas los datos en la tabla. Que es como debe ser.

Y si, seguro que alguno está levantando la ceja por eso de usar EXECUTE AS ‘sa’ pero, es lo que hay. Es necesario para acceder a vistas como sys.dm_exec_connections si el usuario que se conecta no es sysadmin. No hay vuelta de hoja.

¿Y los errores? ¿Y los logs?

Todo esto está muy bien, pero cuando algo falla queremos saber qué ha pasado. Y sobre todo desde dónde.

Podemos mejorar el sistema añadiendo una tabla de log de errores y registrando ahí los intentos de conexión denegados:

CREATE TABLE LogErroresLogin (
    Fecha DATETIME DEFAULT GETDATE(),
    Usuario NVARCHAR(100),
    IPOrigen NVARCHAR(48),
    Motivo NVARCHAR(255)
);

Y dentro del trigger:

IF NOT EXISTS (...) -- como antes
BEGIN
    INSERT INTO ConfigSeguridad.dbo.LogErroresLogin (Usuario, IPOrigen, Motivo)
    VALUES (@NombreUsuario, @IPCliente, 'IP no permitida para este usuario');

    ROLLBACK;
END

De esta forma no solo protegemos, sino que auditamos. Que es justo lo que queremos cuando las cosas se tuercen.

Cuidado con las metidas de pata

Este tipo de trigger tiene mucha potencia, pero también un alto potencial para dejarte fuera como si hubieras olvidado las llaves dentro del coche. Si te bloqueas a ti mismo por error, hay dos formas de volver a entrar en el servidor y recuperar el control.

La primera es iniciar SQL Server en modo de inicio mínimo (-f) o modo de usuario único (-m), y eliminar el trigger desde ahí. Es incómodo, requiere reiniciar servicios, y si lo haces en un entorno en producción, más te vale tener una buena excusa preparada.

La segunda, más limpia y menos traumática, es conectarte a través de DAC (Dedicated Admin Connection). Esta conexión especial está activa en todos los SQL Server, pero ojo: el acceso remoto mediante DAC sí está deshabilitado por defecto. Y eso, en muchos casos, es como si no existiera, porque muchos de nosotros no administramos los servidores desde la consola local del host.

Puedes habilitar el acceso remoto a DAC con esta instrucción:

sp_configure 'remote admin connections', 1;
RECONFIGURE;

Y aquí viene la parte clave, no puedes usar DAC desde el GUI de SSMS. Olvídate de escribir ADMIN:servidor en el cuadro de conexión: eso no funciona. Para conectarte por DAC necesitas usar sqlcmd, ya sea desde la línea de comandos o desde el modo SQLCMD en SSMS (sí, ese modo raro que muchos ignoran hasta que es demasiado tarde).

Desde consola, la conexión se haría así:

sqlcmd -S ADMIN:NombreServidor\Instancia -E

Y desde ahí, puedes desactivar el trigger como si nada hubiera pasado.

Así que, si vas a jugar con triggers de inicio de sesión, valida bien tu tabla de permisos, habilita y prueba DAC remota, y ten sqlcmd a mano. Porque cuando el trigger se ponga tonto, el Management Studio no te va a sacar del apuro. Y cuando eso pase, querrás tener un plan B que no incluya reiniciar producción en hora punta.

Conclusión

Sí, se puede restringir el acceso a SQL Server por IP. No, no es una funcionalidad nativa. Pero con un poco de código y sentido común, se puede controlar quién entra y desde dónde. Es una capa de seguridad adicional que, bien usada, puede salvarte de más de un disgusto. Especialmente si aún sigues permitiendo conexiones con el usuario sa desde equipos de usuarios. Que eso sí que es una mala práctica de campeonato.

El código completo lo tienes en mi cuenta de GitHub, como siempre. Si lo vas a implementar, hazlo con cabeza. Aquí no venimos a jugar con triggers, venimos a proteger entornos que importan.

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!

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios