SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

May

2025

Versiones de SQL Server en Amazon AWS

Cuando hablamos de SQL Server en AWS, lo primero que debemos hacer es dejar atrás esa idea ingenua de que “en la nube todo es más fácil”. No, no lo es. Solo es diferente, y en muchos casos, más complejo. Porque cuando mezclamos la gestión de SQL Server con la selva de servicios de AWS, las posibilidades se multiplican… junto con los puntos de fallo. Así que vamos a desgranar, con precisión quirúrgica y sin evangelismos nublados por el marketing, qué opciones reales tenemos cuando queremos desplegar SQL Server en Amazon Web Services.

SQL Server en AWS: más allá del “lift and shift”

Hay dos grandes formas de ejecutar SQL Server en AWS: usar máquinas virtuales (EC2) o servicios gestionados (principalmente RDS). Y sí, hay matices, capas y excepciones, pero si no entendemos esta dicotomía básica, mejor volvemos a estudiar para el examen de certificación.

En esencia, EC2 nos da el control total (y la responsabilidad completa). RDS nos quita dolores de cabeza, pero también libertad. ¿Queremos hacer magia negra con xp_cmdshell, afinar a mano el maxdop, o aplicar un Service Pack que aún no ha salido oficialmente? Entonces EC2. ¿Preferimos que AWS se encargue de los backups, los parches y la alta disponibilidad con solo marcar unas casillas? RDS es nuestro nuevo amigo.

Amazon AWS EC2 con SQL Server: libertad para vivir al límite

Al desplegar SQL Server en instancias EC2, estamos hablando de IaaS de libro. Tú eliges el sistema operativo (Windows, claro, porque hablamos de SQL Server), tú instalas SQL Server, tú configuras todo. También tú lo rompes y lo arreglas.

La ventaja evidente es que puedes usar cualquier edición de SQL Server: Express, Web, Standard o Enterprise. Puedes traer tu propia licencia (BYOL, Bring Your Own License) o usar las licencias incluidas en la AMI (Amazon Machine Image) oficial con licencia de pago por uso.

Esta opción brilla en entornos que necesitan configuraciones exóticas o donde el cumplimiento normativo exige control absoluto sobre el sistema. También en arquitecturas donde SQL Server no está solo, sino embebido en un sistema complejo que se despliega como un todo.

¿El coste? Altísimo si no controlamos los recursos. Sí, puedes tener una r6i.16xlarge para presumir, pero luego no te quejes cuando el informe mensual de AWS te haga llorar más que un RAISERROR con severidad 25.

Amazon AWS RDS para SQL Server: el camino del zen (limitado)

RDS (Relational Database Service) ofrece SQL Server como servicio gestionado. Lo eliges desde la consola, eliges la edición, el tamaño, las opciones de almacenamiento, y listo: tienes una instancia SQL Server “as a service”.

Aquí puedes elegir entre las ediciones Web, Standard y Enterprise. Express solo está disponible en RDS para desarrollo y pruebas muy básicas. Las versiones van desde SQL Server 2012 hasta 2022, aunque las más antiguas ya huelen a rancio y deberían estar fuera de toda conversación seria.

AWS se encarga del parcheo, los backups automáticos, la monitorización con CloudWatch, la alta disponibilidad con Multi-AZ, y hasta de restaurarte una base de datos si te la cargas (dentro del periodo de retención). Muy cómodo, sí. Pero el precio de esa comodidad es la limitación.

Por ejemplo, no puedes usar funciones como FILESTREAM, SQL Server Agent personalizado, CLR Unsafe, xp_cmdshell, ni muchos otros elementos avanzados. Tampoco puedes instalar software adicional en el sistema operativo ni afinar el motor a nivel de sistema. ¿Es suficiente para la mayoría de los casos de uso? Sí. ¿Es frustrante cuando necesitas hacer algo fuera del guión? También.

¿Qué ediciones están disponibles en AWS y cuándo usarlas?

Aquí es donde las diferencias entre EC2 y RDS se hacen más evidentes. En EC2 puedes instalar lo que quieras, como si estuvieras en tu CPD de toda la vida. RDS, en cambio, restringe la elección a ediciones licenciadas por AWS.

SQL Server Express: limitada hasta el absurdo. Solo útil en pruebas o en ese ERP vintage que aún cabe en 10 GB. Está disponible en EC2 y en RDS.
SQL Server Web Edition: solo para aplicaciones web y bajo ciertas condiciones. Más barata que Standard, pero con muchas limitaciones. Solo disponible en RDS si tu contrato lo permite.
SQL Server Standard: el caballo de batalla. Lo suficientemente potente para la mayoría de workloads OLTP, con soporte de hasta 128 GB de RAM y sin las florituras de Enterprise. Disponible tanto en EC2 como en RDS.
SQL Server Enterprise: para cuando ya no hablamos de bases de datos, sino de feudos de datos. Requiere justificar su coste, pero habilita funciones como Always On, compresión de datos, particionamiento, y el Query Store decente (no el recortado de Standard). También disponible en ambas opciones.

Versiones disponibles en AWS: sí, también hay letra pequeña

En RDS, las versiones disponibles van desde SQL Server 2012 hasta 2022 (según la región y el tipo de instancia). Pero no siempre están todas. Hay regiones donde 2022 aún no está disponible o donde ciertas ediciones se ofrecen solo en ciertas clases de instancias. Y no esperes instalar CUs al día siguiente de su publicación: AWS sigue su propio calendario de validación, lo cual está bien si valoramos la estabilidad… y menos bien si necesitamos esa CU concreta para resolver un bug que nos está friendo en producción.

En EC2, como tú te lo guisas, tú decides qué versión instalar. Pero no te olvides de los ciclos de soporte. Instalar SQL Server 2016 en 2025 es como llevar un Nokia 3310 a una reunión de arquitectura cloud: nostálgico, pero absurdo.

Y si hablamos de costes… prepara la cartera

Ni EC2 ni RDS son baratos si no se diseñan con cabeza. RDS tiene costes predecibles, pero no siempre bajos. EC2 puede salir caro si dejamos las instancias encendidas todo el mes sin monitorizar nada. Y el coste de las licencias es otra historia. SQL Server no es barato, y Amazon lo sabe.

En RDS pagamos licencia por hora. En EC2 podemos traer nuestras licencias con Software Assurance, lo cual puede ahorrar bastante en escenarios Enterprise. Pero si lo haces mal, puedes terminar pagando el doble por rendimiento inferior. La arquitectura importa, y mucho.

¿Y qué pasa con la alta disponibilidad en AWS?

En EC2, la alta disponibilidad te la montas tú: con Always On Availability Groups, con failover clustering, o con lo que prefieras… y se te ocurra mantener. En RDS, basta con activar la opción Multi-AZ y dejar que AWS haga el trabajo sucio. Pero no confundamos Multi-AZ con Always On: RDS usa su propio sistema de replicación bajo el capó, que no es transparente ni configurable.

Si necesitas un AG real con réplicas legibles, bienvenido a EC2. Y prepárate para montar la infraestructura necesaria: subredes, listeners, quórum, test de failover, etc. ¿Merece la pena? Depende de lo que estés dispuesto a sacrificar por la comodidad.

Te recomiendo ver la sesión de Francisco Amat sobre este tema para llevar tu alta disponibilidad al siguiente nivel.

Conclusión

No hay una única respuesta correcta a la pregunta “¿cómo desplegamos SQL Server en AWS?”. Hay decisiones técnicas, estratégicas y económicas que tomar. EC2 es más flexible, pero también más arriesgado. RDS es más cómodo, pero impone más restricciones.

La elección depende del tipo de carga, del nivel de control que necesitamos, de los costes que estamos dispuestos a asumir y, por supuesto, de cuántos fuegos queremos apagar a las tres de la madrugada.

Así que no, no es cuestión de levantar una base de datos “en la nube” y seguir con nuestra vida. Es cuestión de entender cada opción, sus límites y sus consecuencias. Porque en AWS, igual que en la vida, cada elección tiene su precio. Y a veces, ese precio se mide en IOPS… o en dignidad.

¿Quieres rendimiento extremo, fine-tuning y llorar en modo sysadmin? EC2. ¿Prefieres comodidad, escalabilidad rápida y vivir con algunas restricciones? RDS. Tú decides. Pero decide con conocimiento, no con fe ciega en el marketing cloud.

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!

May

2025

¿Qué puede aportar ITIL a la administración de SQL Server?

Solo pronunciar la palabra ITIL en una reunión técnica ya provoca dos reacciones inmediatas: o la mirada perdida del que recuerda noches eternas rellenando formularios, o el entusiasmo contenido del que cree que un diagrama de flujo puede resolver cualquier crisis. Ni tanto, ni tan poco. ITIL no es el enemigo, pero tampoco es la salvación definitiva. Y en el mundo de SQL Server, si sabemos adaptar sus principios con criterio, puede marcar la diferencia entre sobrevivir y gestionar con cabeza.

Sí, ITIL nació en un entorno más orientado a servicios IT generales, con vocación de biblioteca pesada y burocracia estructurada. Pero entre tanta sigla y proceso hay ideas útiles, aplicables a nuestro día a día como DBAs. El truco está en no convertirlo en un ministerio de tickets que nadie entiende, sino en un marco de trabajo razonable que nos ayude a ser menos reactivos y más estratégicos.

Vamos a bajar ITIL al barro del SQL Server. Y a hacerlo sin perder el alma en el intento.

Incidencias, problemas en ITIL: el arte de no confundir las cosas

Una de las primeras cosas que ITIL pone sobre la mesa —y que en el mundo DBA muchas veces ignoramos por pereza o costumbre— es la diferencia entre una incidencia y un problema. Parece menor, pero no lo es.

Una incidencia es un evento que interrumpe un servicio o reduce su calidad. Ejemplo: el job de backups ha fallado esta noche. Salta alerta, lo reejecutamos, y listo. Un problema, en cambio, es la causa raíz de una o más incidencias. Si ese job falla cada martes a las 2:00 porque coincide con una tarea de antivirus que bloquea el acceso al disco, eso es un problema.

Y aquí viene la parte divertida: si tratamos cada incidencia como un caso aislado, nos convertimos en técnicos de soporte en bucle, reiniciando servicios y ejecutando scripts hasta la eternidad. Pero si aplicamos la gestión de problemas de ITIL con cabeza, empezamos a ver patrones, causas reales y soluciones permanentes.

En resumen: no todo lo que rompe un proceso requiere abrir un post-mortem. Pero tampoco todo lo que se resuelve fácil está realmente arreglado.

Gestión de cambios en ITIL: ni todos los cambios necesitan CAB ni todo vale en producción

¿Has hecho un cambio menor en una base de datos y se ha caído media aplicación? Bienvenido al club. La gestión de cambios de ITIL no es solo para empresas con equipos de 200 personas y reuniones semanales de CAB (Change Advisory Board) donde nadie sabe qué se está aprobando. También tiene su lugar en entornos más pequeños y técnicos, si la aplicamos con lógica.

La clave está en clasificar los cambios. Un cambio estándar (como añadir una columna no crítica en una tabla interna) no necesita tres aprobaciones y un PowerPoint. Pero un cambio significativo (como migrar índices a un nuevo filegroup, o modificar la lógica de un procedimiento que usan 40 aplicaciones) sí debe planificarse, testearse y validarse. No por gusto, sino porque sabemos lo que puede pasar si no lo hacemos.

¿Necesitamos herramientas carísimas para esto? No. Un control de versiones decente, documentación clara y una mínima validación con otro DBA ya marcan la diferencia. Lo que no se puede seguir haciendo es modificar objetos en producción directamente “porque era urgente”. ITIL no lo permite, y nuestra salud mental tampoco.

SLAs en ITIL: prometer menos, cumplir más

Uno de los capítulos más ignorados de ITIL en entornos de administración de bases de datos es el de los SLA. Y no por falta de interés, sino porque muchos creen que los SLAs son cosas que firman los proveedores con sus clientes, no algo que debamos aplicar en un equipo interno de IT. Error.

Tener acuerdos de nivel de servicio realistas nos permite dejar de correr detrás de expectativas imposibles. Si el SLA dice que las restauraciones completas deben estar disponibles en 1 hora y tú sabes que el backup de 1,2 TB tarda 3 horas en copiarse por red… tenemos un problema. Y no es técnico, es de expectativas mal gestionadas.

Definir SLAs internos para cosas como tiempos de recuperación, respuestas a tickets críticos o disponibilidad de entornos de desarrollo nos da aire. Y, sobre todo, nos da un marco para decir “esto no es un fallo nuestro, es un riesgo aceptado”.

Por cierto, si tu jefe quiere un SLA del 99,999% pero no quiere gastar en alta disponibilidad… enséñale el coste real del «cinco nueves» y deja que saque la calculadora.

Cómo aplicar ITIL sin acabar atrapado en una burocracia kafkiana

La gran crítica a ITIL (y no sin razón) es que si se aplica sin cabeza, se convierte en un monstruo de procesos que matan la agilidad. Pero se puede hacer de forma sensata.

Para la gestión de incidencias, basta con tener un sistema de seguimiento que no sea una libreta o el correo de soporte. Un sistema sencillo, con prioridad real (no todo es “crítico”), histórico y cierre con causa anotada. Un Excel bien estructurado ya es mejor que el caos.

Para la gestión de problemas, necesitamos tiempo y foco. Una revisión semanal o mensual de incidencias repetidas, análisis de tendencias y propuestas de mejora. Nada de reuniones eternas, sino una hora técnica bien aprovechada.

Y para la gestión de cambios, un flujo simple: idea → validación técnica → test → ejecución → revisión. Si podemos automatizar despliegues, mejor. Si no, al menos que haya trazabilidad. Lo importante es que nadie toque sin avisar ni se entere el lunes por los logs de errores.

¿Hay herramientas que nos ayuden?

La buena noticia es que muchas de estas prácticas pueden integrarse en herramientas que ya usamos: Azure DevOps, Jira, ServiceNow, incluso PowerShell con Git. No necesitas montar un ITSM completo si estás en un entorno más técnico o ágil, pero sí necesitas orden, visibilidad y un mínimo de formalidad.

ITIL no va de rellenar formularios absurdos. Va de saber qué pasa, por qué pasa y qué se está haciendo para evitar que vuelva a pasar. En SQL Server, eso se traduce en menos emergencias y más control. Y eso, amigos, se agradece.

Conclusión

ITIL no es una religión, ni una cárcel de procesos. Es una caja de herramientas. Usada con criterio, puede ayudarnos a distinguir entre apagar fuegos y rediseñar el sistema contra incendios.

Como DBAs, podemos ignorarla y seguir a salto de mata, o podemos aplicar sus principios sin convertirnos en burócratas. Si lo hacemos bien, el resultado es menos caos, menos sorpresas y más tiempo para lo que realmente importa: anticiparnos a los problemas antes de que sean noticias en la monitorización.

Y si encima podemos justificar nuestras decisiones con un marco reconocido, mejor que mejor. Aunque nunca llegues a decir que «sigues ITIL», si aplicas sus principios con cabeza, se va a notar. Y eso, en esta profesión, ya es mucho.

May

2025

Roles de base de datos en SQL Server

Después de explorar los roles de servidor predefinidos en SQL Server, es lógico continuar analizando el otro gran componente del modelo de permisos: los roles de base de datos. Mientras que los primeros afectan a toda la instancia, estos últimos actúan dentro de una base de datos concreta, permitiéndonos aplicar controles más finos sobre quién puede hacer qué, cómo y dónde dentro del entorno de datos.

Gracias a los roles de base de datos, podemos organizar el acceso de usuarios, aplicaciones y servicios en función de necesidades específicas, minimizando el riesgo de accesos indebidos y facilitando la administración. Su correcta utilización es clave para implantar políticas de seguridad sostenibles y alineadas con el principio de privilegio mínimo.

¿Qué son los roles de base de datos y cómo se diferencian de los de servidor?

Los roles de base de datos son “contenedores de permisos” que se aplican dentro del ámbito de una única base de datos. Un usuario puede pertenecer a distintos roles en diferentes bases, con permisos completamente independientes. A diferencia de los roles de servidor, no otorgan privilegios sobre la instancia ni sobre otras bases de datos.

Por ejemplo, un usuario podría ser db_datareader en una base y db_owner en otra, sin que eso afecte a su capacidad de acceder a la configuración global del servidor o a otras bases no relacionadas. Para ser estrictos, cada base de datos tendrá su usuario que pertenece a sus roles y estos usuarios estarán enlazados a un mismo login.

Esta independencia permite diseñar estrategias de seguridad muy detalladas, en las que cada usuario o grupo recibe únicamente los permisos necesarios en cada base, sin arrastrar privilegios innecesarios.

Roles fijos de base de datos

SQL Server incluye una serie de roles fijos que vienen predefinidos en cada base de datos y cubren los escenarios más habituales de gestión y uso:

db_owner otorga control total sobre todos los objetos y permisos de la base de datos. Es el equivalente a un administrador local. Su uso debe restringirse, ya que un miembro de este rol puede concederse cualquier permiso, incluso eliminar datos o activar configuraciones peligrosas como TRUSTWORTHY.
db_securityadmin permite gestionar permisos, roles y pertenencias, sin acceso directo a los datos. Se utiliza en contextos donde la administración de seguridad está delegada a un equipo diferente del que desarrolla o explota la base.
db_accessadmin se centra en controlar qué inicios de sesión pueden acceder a la base de datos, sin permitir alterar los objetos.
db_ddladmin permite crear y modificar objetos, como tablas, procedimientos o funciones, pero no ejecutar o leer datos si no se concede ese permiso explícitamente.
db_datareader y db_datawriter permiten leer o escribir en todas las tablas y vistas de la base, respectivamente. Su uso está muy extendido en entornos donde se busca una división clara entre consumo y generación de datos.
db_backupoperator da acceso a realizar copias de seguridad de la base, pero no restaurarlas ni acceder al contenido.

También existen dos roles especiales diseñados para denegar explícitamente el acceso a los datos.

db_denydatareader impide leer cualquier tabla o vista, incluso si otros roles o permisos lo permiten.
db_denydatawriter bloquea la capacidad de insertar, actualizar o eliminar datos.

Además, todos los usuarios pertenecen al rol public, que funciona como contenedor de permisos comunes. Conviene auditar este rol, ya que cualquier permiso que se le conceda afectará a todos los usuarios de la base, sin excepción.

Roles definidos por el usuario: flexibilidad con control

Los roles fijos no cubren todos los escenarios. En bases de datos complejas, necesitamos diseñar roles personalizados que agrupen permisos según criterios funcionales, de negocio o de seguridad. SQL Server permite crear estos roles mediante la instrucción CREATE ROLE, y a partir de ahí podemos asignarles permisos (GRANT, DENY, REVOKE) y miembros (ALTER ROLE … ADD MEMBER).

Esto nos permite definir roles como lectura_finanzas, escritura_marketing, administrador_reportes o cualquier otro nombre que represente una necesidad específica de acceso.

Una ventaja clara de este enfoque es que facilita la administración a largo plazo: si mañana se incorpora una nueva persona al equipo de marketing, basta con agregarla al rol correspondiente, sin tener que revisar permisos individuales.

También permite mantener las políticas de seguridad documentadas, auditables y fácilmente transferibles entre entornos.

Buenas prácticas en la asignación de roles de base de datos

Diseñar una estrategia sólida de roles no consiste solo en conocer los disponibles, sino en aplicarlos con criterio. No debemos asignar permisos directamente a usuarios individuales. En su lugar, se crean roles personalizados y se asignan los permisos al rol, manteniendo la lógica de acceso desacoplada de los usuarios.

Otra recomendación es que el rol db_owner debe reservarse para tareas excepcionales o de mantenimiento. En la mayoría de los casos, podemos cubrir todas las necesidades combinando db_ddladmin, db_datareader, db_datawriter y roles personalizados.

Como ya hemos comentado antes, revisar el contenido del rol public en cada base de datos es fundamental. En muchas implementaciones antiguas se le han otorgado permisos de lectura general como solución rápida, pero esto impide auditar correctamente qué usuarios acceden a qué objetos.

Por último, documentar el propósito de cada rol, quiénes lo integran y qué permisos tiene asignados nos permitirá mantener el sistema bajo control con el paso del tiempo.

El rol inexistente db_executor: ¿Por qué no existe y cómo crearlo?

Un error común al comenzar a trabajar con SQL Server es suponer que existe un rol fijo llamado db_executor, similar a db_datareader o db_datawriter, que permita ejecutar todos los procedimientos almacenados de una base de datos. Sin embargo, SQL Server no incluye por defecto un rol con este nombre ni con ese comportamiento. Tampoco los roles db_datareader o db_datawriter permiten la ejecución de procedimientos almacenados.

Esto suele generar confusión porque ejecutar procedimientos es una necesidad frecuente, especialmente en entornos donde las aplicaciones solo deben invocar lógica encapsulada sin acceder directamente a las tablas. La buena noticia es que podemos crear este rol manualmente en cualquier base de datos y dotarlo de los permisos necesarios para cumplir esa función. Para ello, basta con ejecutar las siguientes instrucciones:

CREATE ROLE db_executor;
GRANT EXECUTE TO db_executor;

Con esto estamos creando un nuevo rol llamado db_executor y concediéndole el permiso EXECUTE sobre todos los objetos ejecutables de la base. A partir de ese momento, cualquier usuario que añadamos al rol podrá ejecutar procedimientos, funciones o scripts definidos por el usuario, sin necesidad de acceder a las tablas directamente.

Este enfoque es muy útil para separar claramente los permisos de lectura, escritura y ejecución, y encaja perfectamente con una arquitectura basada en acceso controlado mediante procedimientos almacenados. Además, permite mantener el principio de encapsulamiento: los usuarios no necesitan saber cómo se obtiene un dato, solo deben poder invocar la lógica que lo proporciona.

Aunque no sea un rol predefinido, db_executor se ha convertido en una práctica ampliamente aceptada en entornos corporativos y en desarrollos donde se prioriza la seguridad y la trazabilidad de accesos.

Conclusión

Los roles de base de datos en SQL Server nos permiten construir un modelo de seguridad sólido, escalable y alineado con las necesidades reales de uso de cada entorno. Si aprendemos a usarlos correctamente, sin abusar de db_owner, sin asignar permisos individuales y combinándolos con el uso estratégico de esquemas, dispondremos de una estructura de permisos fácil de mantener, auditar y adaptar a los cambios del negocio.

Cuando los roles de servidor y de base de datos se combinan adecuadamente, conseguimos un entorno donde la delegación de tareas y el control de seguridad no son opuestos, sino aliados.

May

2025

¿Qué significa cada rol de servidor en SQL Server?

Cuando administramos SQL Server en entornos de producción o de desarrollo colaborativo, una de las tareas más críticas y delicadas es la asignación de permisos. Necesitamos asegurarnos de que cada persona o aplicación tenga exactamente el nivel de acceso necesario: ni más, ni menos. Para facilitar esa labor, SQL Server proporciona una serie de roles de servidor predefinidos que nos permiten, añadiendo logins a un rol, delegar tareas administrativas sin comprometer la seguridad general del sistema.

Estos roles abarcan un amplio espectro de privilegios, desde el acceso total hasta responsabilidades muy concretas. Entender qué puede y qué no puede hacer cada uno es esencial si queremos implementar una estrategia de seguridad sólida, auditada y coherente con los principios de privilegio mínimo y separación de funciones.

¿Qué son los roles de servidor en SQL Server?

Antes de entrar en detalles, conviene matizar que los roles de servidor se aplican a nivel de instancia, no de base de datos. Esto los diferencia de los roles de base de datos, que tienen un ámbito mucho más localizado. Al pertenecer a un rol de servidor, un inicio de sesión adquiere permisos que pueden afectar a cualquier base de datos, a la configuración del motor, a los recursos del sistema o incluso a las operaciones de seguridad globales.

SQL Server incorpora varios roles fijos de servidor que no se pueden modificar, ni eliminar, ni asignar permisos adicionales. La única acción permitida es agregar o quitar inicios de sesión como miembros. Estos roles están pensados para cubrir la mayoría de escenarios comunes de administración.

Rol sysadmin: control total sin restricciones

El rol sysadmin es, sin lugar a dudas, el más poderoso de todos. Los miembros de este rol pueden realizar cualquier acción en la instancia de SQL Server, incluyendo todas las bases de datos presentes y futuras. No existe ninguna comprobación adicional de permisos cuando el inicio de sesión pertenece a sysadmin, lo que significa que cualquier restricción desaparece.

En la práctica, este rol debería reservarse exclusivamente para los administradores de bases de datos principales y, si es posible, nunca usarse como cuenta de servicio ni asignarse a desarrolladores, aunque sean senior. Desde el punto de vista de seguridad, es recomendable que exista más de una cuenta con este rol (para evitar bloqueos administrativos), pero siempre bajo un control estricto.

Rol serveradmin: configuración del servidor

El rol serveradmin otorga privilegios para cambiar opciones de configuración a nivel de servidor. Esto incluye aspectos como la habilitación de características avanzadas, la configuración de opciones con sp_configure, el arranque de la instancia o incluso el apagado del servicio.

Aunque puede parecer menos crítico que sysadmin, en la práctica sus acciones pueden afectar a todo el sistema, por lo que también debe asignarse con cautela. Es útil en escenarios donde existe un equipo de infraestructura que gestiona SQL Server sin necesidad de intervenir en los datos.

Rol securityadmin: gestión de la seguridad

Este rol permite crear inicios de sesión, asignar permisos a nivel de servidor, administrar certificados y credenciales, así como controlar los roles de servidor. Los miembros de securityadmin tienen una capacidad indirecta de elevar privilegios, ya que podrían agregarse a sí mismos a otros roles, incluyendo sysadmin.

Por esa razón, este rol suele considerarse muy sensible, aunque no tenga acceso directo a los datos. Resulta especialmente útil en entornos donde la seguridad está delegada a otro equipo distinto del que administra las bases de datos.

Rol processadmin: control de procesos

Con este rol se puede finalizar procesos que se estén ejecutando en la instancia. Esto incluye la posibilidad de matar sesiones activas, algo especialmente útil en situaciones de bloqueo o recursos en conflicto. Aunque no otorga permisos para ver o manipular los datos, ni para cambiar configuraciones del sistema, debemos ser cuidadosos, pues si que puede llegar a ser posible capturar información sensible de los planes de ejecución.

Asignar este rol a ciertos operadores puede facilitar la resolución de incidencias sin conceder acceso completo al sistema.

Rol setupadmin: gestión de linked servers

Aunque su uso es mucho menos frecuente hoy en día, setupadmin sigue teniendo sentido en contextos donde se gestionan servidores vinculados (linked servers). Los miembros pueden agregar, modificar o eliminar estas configuraciones, que permiten realizar consultas distribuidas o transferencias de datos entre instancias.

Dado que un linked server puede convertirse en una puerta de entrada a otros entornos, conviene tener claro quién gestiona estos objetos y auditar su uso regularmente.

Rol bulkadmin: importación masiva de datos

Este rol otorga permiso para ejecutar instrucciones BULK INSERT, una opción muy utilizada en procesos de carga masiva de datos, especialmente cuando se trabaja con ficheros planos. Al estar acotado a una funcionalidad muy concreta, resulta adecuado para ciertos perfiles técnicos, como equipos de integración o ETL, que no necesitan más permisos.

Es importante tener en cuenta que la instrucción BULK INSERT puede acceder a archivos del sistema, por lo que, desde un punto de vista de seguridad, también implica cierto riesgo si se combina con rutas de red o recursos compartidos.

Rol diskadmin: gestión de archivos de respaldo

El rol diskadmin es otro de los menos utilizados hoy en día, dado que su funcionalidad está relacionada con la creación y eliminación de archivos de backup desde SQL Server. Su uso tiene sentido solo cuando se utilizan dispositivos lógicos (backup devices), algo cada vez más inusual.

En entornos modernos, donde se realizan backups directamente a rutas del sistema de archivos gestionadas por políticas externas, este rol ha perdido gran parte de su relevancia.

Rol dbcreator: creación y modificación de bases de datos

Este rol permite crear, modificar, adjuntar o restaurar bases de datos. No concede acceso a los datos una vez creadas, pero sí permite establecer configuraciones iniciales que podrían ser utilizadas para ataques indirectos, como por ejemplo habilitar trustworthy o activar clr.

Suele utilizarse para tareas de despliegue automatizado de bases de datos o en escenarios de desarrollo donde los equipos necesitan crear y eliminar bases de datos de forma frecuente. Aun así, es necesario auditar su uso con cierta periodicidad.

Rol public: el rol olvidado

Aunque no se considera un rol de servidor como tal, conviene recordar que todos los inicios de sesión son miembros del rol public, tanto a nivel de servidor como en cada base de datos. Los permisos asignados a este rol afectan a todos los usuarios, por lo que es buena práctica revisar qué privilegios tiene. En general, no deberíamos asignar permisos explícitos al rol public, ni siquiera por comodidad.

Los nuevos roles: control más específico

En versiones recientes de SQL Server, especialmente desde la edición 2022, Microsoft ha introducido una nueva serie de roles de servidor predefinidos que comienzan por el prefijo ##MS_. Estos roles permiten una administración mucho más granular, respondiendo a las necesidades actuales de seguridad y cumplimiento normativo.

A diferencia de los roles tradicionales, que solían abarcar conjuntos amplios de privilegios, estos nuevos roles están diseñados para conceder exactamente el acceso necesario a tareas muy específicas sin otorgar capacidades colaterales. Encontramos, por ejemplo, roles que permiten únicamente conectarse al servidor sin otros permisos (##MS_DatabaseConnector##), gestionar la creación de bases de datos propias (##MS_DatabaseManager##) o administrar inicios de sesión con limitaciones muy concretas (##MS_LoginManager##).

También se han añadido roles orientados a lectura, como los que permiten consultar definiciones de objetos, configuraciones de seguridad o estados de rendimiento del sistema, sin capacidad para alterarlos. Este enfoque resulta especialmente útil en escenarios donde es necesario conceder visibilidad a herramientas de monitorización, auditores, desarrolladores o personal de soporte sin comprometer la integridad del entorno.

En conjunto, estos nuevos roles suponen un avance significativo en la estrategia de seguridad de SQL Server, ya que permiten delegar responsabilidades sin caer en el uso excesivo del rol sysadmin, que históricamente se ha utilizado por comodidad pero a costa de debilitar los controles de acceso. Su correcta implementación no solo mejora la trazabilidad y reduce el riesgo operativo, sino que también facilita el cumplimiento de estándares como ISO 27001, NIST o CIS Benchmarks.

A medida que se estandariza su uso, es previsible que se conviertan en una herramienta clave para los equipos de administración que gestionan entornos compartidos, automatizados o con altos requerimientos de control.

Conclusión

Los roles de servidor predefinidos de SQL Server ofrecen una manera estructurada de delegar funciones administrativas, manteniendo al mismo tiempo el control sobre la seguridad. Una comprensión clara de sus capacidades y limitaciones es imprescindible para cualquier DBA que gestione entornos con múltiples usuarios, distintos niveles de responsabilidad y necesidades operativas bien definidas.

No se trata de asignar permisos por intuición o costumbre, sino de diseñar una política de acceso coherente, auditable y alineada con la realidad operativa de cada empresa. Porque en administración de bases de datos, dar un permiso de más puede ser tan peligroso como no dar ninguno.

May

2025

¿Qué podemos aplicar de la metodología Six Sigma a SQL Server?

Aunque Six Sigma suena a fábricas, líneas de producción y tipos con casco revisando procesos con una tablet que no entienden del todo, sus principios encajan sorprendentemente bien en el día a día de quienes administramos bases de datos. ¿Queremos estabilidad, rendimiento y menos sustos en producción? Esto también va con nosotros.

No hace falta creerse un cinturón negro (literalmente, Six Sigma va por cinturones como el karate) para entender lo que propone. Six Sigma se centra en reducir la variabilidad, eliminar errores y optimizar procesos. ¿Te suena familiar? Claro. En el fondo, cuando hacemos tuning, revisamos procesos de mantenimiento o auditamos un servidor que se arrastra desde hace meses, estamos buscando lo mismo: eficiencia y control. La diferencia es que, con Six Sigma, lo hacemos con un marco claro, basado en datos y no en corazonadas.

DMAIC: el ciclo Six Sigma que también entiende un DBA

Six Sigma gira en torno a un ciclo de mejora continua llamado DMAIC. No, no es una broma con las siglas de alguna empresa de hosting dudosa. Hablamos de cinco fases perfectamente aplicables a SQL Server: Definir, Medir, Analizar, Mejorar y Controlar.

Fases del ciclo DMAIC de Six Sigma

Definir (Define) es identificar claramente qué proceso o componente queremos mejorar. Nada de “el servidor va lento” como diagnóstico. ¿Son los backups que tardan siglos? ¿Consultas que convierten CPUs en tostadoras? ¿El sistema de auditoría que escribe más que Kafka? Si no sabemos qué, no sabremos cómo.

Medir (Measure) exige recopilar datos reales. No lo que creemos, no lo que el desarrollador «recuerda que antes iba más rápido», sino métricas objetivas. Aquí entran herramientas como Query Store, Extended Events o, si nos ponemos clásicos, una buena captura de sys.dm_exec_requests. Medimos tiempos, recursos consumidos, ratios de deadlocks, tiempos de espera. Medimos lo que importa.

Analizar (Analyze) nos lleva a buscar la causa raíz, no el síntoma. ¿Es un índice mal diseñado? ¿Una estadística obsoleta? ¿Un plan de ejecución que cambió por un parámetro traicionero? No vale con saber que una query tarda 40 segundos; hay que saber por qué.

Mejorar (Improve) significa actuar. No nos quedamos con el diagnóstico para contarlo en la próxima daily. Aquí afinamos consultas, revisamos planes de ejecución, creamos (o eliminamos) índices, y, si hace falta, activamos OPTIMIZE FOR o le damos una vuelta al esquema. Mejora implica intervención con sentido, no aplicar la última sugerencia de Stack Overflow como quien lanza dados.

Controlar (Control) es cerrar el círculo. Asegurar que el problema no reaparezca en tres semanas cuando nadie mire. Esto implica monitorización continua, alertas, revisiones periódicas, e incluso políticas formales que eviten el caos reincidente. El control no es micromanagement, es prevención profesional.

Todo esto puede parecer obvio para quien ya lleva años en esto, pero seamos honestos: ¿cuántas veces resolvemos un problema y nos olvidamos de controlarlo?

Ciclo DMAIC en versión DBA

Visualiza este ciclo aplicado a nuestro mundo:

Sí, es cíclico. Y no, no se termina nunca. Como los correos de usuarios pidiendo acceso de sysadmin.

Ejemplos prácticos: aplicando Six Sigma SQL Server

Vamos a bajar a tierra cada fase con escenarios reales. Porque sí, queda muy bien hablar de metodologías, pero lo importante es aplicarlas sin parecer un consultor que no ha tocado un Management Studio en años.

Fases de análisis

Definir: Imaginemos que tenemos backups nocturnos que cada vez tardan más. O una aplicación web que de repente responde como si estuviera en un 3G con cobertura dudosa. O usuarios que se quejan de bloqueos cada lunes a las 10. Aquí no hablamos de «mejorar el rendimiento», sino de «disminuir el tiempo de backup de 90 a 45 minutos», «reducir el tiempo de respuesta de la API a menos de 300 ms», o «eliminar los bloqueos en el proceso X». Concreción, no filosofía.

Medir: Nada de adivinar. Nos vamos a Query Store a ver los planes de ejecución históricos, capturamos métricas con Extended Events, analizamos wait stats, miramos IO con sys.dm_io_virtual_file_stats, y sacamos ratios de bloqueos por segundo. Si no lo podemos medir, no lo podemos mejorar. Así de simple.

Y ya que estamos, digámoslo claro: el 90% de los “problemas de rendimiento” no son problemas de rendimiento. Son problemas de diseño sin medir.

## Analizar: Ya con los datos en mano, toca ver qué está pasando de verdad. ¿El backup tarda por una fragmentación absurda en los logs? ¿La consulta lenta está usando un plan de ejecución malo? ¿El índice no se usa porque las estadísticas llevan semanas sin actualizarse? Esta fase separa a los DBA de verdad del resto. El análisis técnico y profundo no se improvisa.

Fases de resolución

Mejorar: Aquí toca mancharse las manos. Creamos índices, ajustamos queries, reescribimos procedimientos o configuramos Resource Governor para evitar que un proceso devore todo. Aplicamos cambios, sí, pero con criterio y midiendo impacto.

Controlar: Una vez resuelto, dejamos trazas para volver atrás si algo falla, implementamos alertas y documentamos el cambio. Porque el control no es una fase de “paz mental”. Es garantizar que el mismo marrón no vuelva como un bug de Windows Update.

Six Sigma no es solo humo de colores

Six Sigma no es una receta mágica, pero su enfoque metódico y basado en datos encaja como anillo al dedo en entornos SQL Server donde lo que no se mide, se convierte en intuición. Y las intuiciones son como los SELECT *: muy populares, muy cómodas… y muy peligrosas.

Además, adoptar esta filosofía nos permite algo clave: dejar de apagar fuegos y empezar a diseñar para que no haya incendios. El DBA reactivo sobrevive. El DBA proactivo duerme tranquilo (o al menos, algo más).

Y si alguna vez tienes que enfrentarte a una auditoría o a justificar por qué se ha invertido en monitorización o en refactorizar consultas, hablar de Six Sigma y DMAIC te da un marco claro y defendible. Además, queda muy bien en el CV. Aunque no sepas karate.

Conclusión

Aplicar Six Sigma en el entorno de SQL Server no es ponerse un casco ni hablar en jerga industrial. Es adoptar una mentalidad que exige claridad, datos, análisis y control continuo. Es lo que ya deberíamos estar haciendo, pero con estructura.

¿Queremos servidores que no den sustos, procesos que rindan como deben y decisiones que se basen en hechos? Pues dejemos de improvisar y empecemos a aplicar lo que funciona. DMAIC no es magia. Pero en manos de un buen DBA, casi lo parece.

May

2025

10 cosas que debe tener tu DRP de SQL Server

Un buen Plan de Recuperación ante Desastres (DRP) en SQL Server no se improvisa con prisas ni se resuelve con un backup semanal en una carpeta compartida. Quien piense lo contrario probablemente también crea que los backups verificados se restauran solos por arte de magia. Aquí venimos a poner orden. Vamos a repasar diez elementos que deben estar presentes en cualquier DRP decente, serio y pensado por alguien que sabe lo que significa tener producción caída más de 15 minutos.

DRP Check 1: Inventario de instancias y bases de datos críticas

Antes de correr a hacer backups como si el mundo se acabara, hace falta saber qué estamos protegiendo. Un DRP sin inventario es como un GPS sin destino. Documentar todas las instancias SQL Server, su versión, configuración, bases de datos alojadas, y cuál de ellas es crítica es el primer paso. Sin eso, el resto del plan será un ejercicio de fe.

Esto incluye nombres, versiones, configuración regional, nivel de compatibilidad, y por supuesto, si estamos hablando de SQL Server On-Prem, en Azure, en máquinas virtuales o en una mezcla caótica digna de una pesadilla DevOps.

DRP Check 2. Estrategia de copias de seguridad (real y testada)

Esto no va de tener un script que haga BACKUP DATABASE, sino de tener un plan de backups bien definido, ajustado al SLA del negocio y validado con restauraciones periódicas. Porque sí, hacer backups sin probar restores es como llenar el depósito del coche sin saber si tienes motor.

Y recuerda debes incluir backups completos, diferenciales y de logs si la base está en FULL.

DRP Check 3. Plan de restauración documentado (y probado, otra vez)

Vale, ya tenemos backups. ¿Y ahora qué? Un DRP sin un procedimiento claro de restauración es solo un acto de fe. Hay que documentar cómo restaurar cada tipo de backup, en qué orden, en qué entorno, y cuánto tiempo se estima que llevará. No valen suposiciones.

¿Se han probado esas restauraciones en un entorno aislado? ¿Se ha medido el tiempo real? ¿Se ha verificado que la aplicación vuelve a levantar sin errores? Si la respuesta es no, el DRP es papel mojado.

DRP Check 4. Topología de alta disponibilidad y replicación

La disponibilidad no es solo cosa del DRP, pero forma parte de él. Un clúster de Always On, una replicación transaccional o un Log Shipping bien montado pueden ser la diferencia entre una caída de horas y una recuperación en minutos.

Aquí hay que documentar cómo están montadas esas soluciones, cómo se comportan ante fallos y, lo más importante, cómo se revierte o se conmutan sin pérdida de datos. Porque el botón “Failover” no es magia, y conviene saber qué pasa antes de pulsarlo.

DRP Check 5. Matriz de responsabilidad (quién hace qué y cuándo)

En medio del caos no hay tiempo para preguntar «¿quién se encarga de esto?». Un DRP debe tener definidos claramente los roles: quién inicia el protocolo, quién comunica a negocio, quién ejecuta los scripts, quién valida y quién da el OK final.

Y no, no vale con poner “El DBA” para todo. Porque el DBA también duerme (al menos en teoría) y puede que no esté disponible a las 3:00 de la mañana un festivo. Así que planifica relevos, turnos y contactos de emergencia. Y por supuesto, guarda esa información fuera del entorno afectado.

DRP Check 6. Procedimiento para activar el DRP

No todo fallo es un desastre. Un plan serio define umbrales: ¿cuándo se considera que hay que activar el DRP? ¿Cuánto tiempo puede estar caída una instancia sin que salten las alarmas? ¿Hay una ventana para intentos de recuperación antes de iniciar failover?

Este punto es crítico. Muchos planes fallan porque nadie sabe cuándo hay que usarlos. Y cuando se deciden, ya es tarde y el daño está hecho. Un buen DRP se activa con decisión, no con debates.

DRP Check 7. Infraestructura de recuperación (y entorno preconfigurado)

Recuperar una base de datos en un entorno que no existe es una broma de mal gusto. El DRP debe incluir un entorno de recuperación configurado con antelación: máquinas, redes, almacenamiento, seguridad… todo listo para levantar una instancia funcional.

Si estás en Azure o AWS, tener imágenes de máquinas o plantillas ARM listas para desplegar reduce el tiempo de recuperación drásticamente. Si estás en On-Prem, tener máquinas físicas o virtuales reservadas para contingencias no es un lujo, es prevención.

DRP Check 8. Automatismos y scripts listos para ejecutar

En medio del desastre, lo último que queremos es escribir scripts a mano o copiar/pegar desde un correo de 2017. El DRP debe contener los scripts ya preparados para tareas como restaurar backups, reconfigurar logins, recrear jobs, reiniciar endpoints y comprobar integridad.

Cuanto más automático esté todo, menos errores y más rapidez. Pero cuidado: automatizar sin entender es un atajo al desastre. Automatización sí, pero documentada, validada y revisada.

DRP Check 9. Validación post-recuperación

El DR no termina cuando el servidor levanta. Termina cuando la aplicación vuelve a funcionar, los usuarios acceden y nadie grita por Teams. El plan debe incluir validaciones técnicas (integridad, acceso, jobs funcionando, monitoreo operativo) y funcionales (consultas clave, flujos de negocio).

Aquí es donde muchos se relajan demasiado pronto. Recuperar una base sin comprobar que los índices no están corruptos o que el SQL Agent arranca, es como arreglar un coche y no probar que arranca. Todo debe quedar verificado y documentado.

DRP Check 10. Revisión y simulacros regulares

Por último, un DRP no es un PDF que se guarda en una carpeta y se olvida. Es un documento vivo que hay que revisar y probar. Idealmente, al menos una vez al año (y si el entorno cambia, con cada cambio relevante).

Los simulacros revelan errores, tiempos reales, dependencias ocultas y, sobre todo, preparan al equipo. No hay vergüenza en fallar en un simulacro. La vergüenza viene cuando el desastre es real y nadie sabe ni por dónde empezar. Y sí, si nunca has hecho un simulacro y crees que todo va a salir bien, te deseo la mejor de las suertes. La vas a necesitar.

Conclusión

Un DRP de SQL Server no es un archivo bonito con diagramas de PowerPoint. Es una estrategia detallada, técnica y validada que te permite dormir un poco más tranquilo (solo un poco). Tiene que estar alineado con el negocio, ejecutado por profesionales y probado con rigor.

Dejarlo para otro día es como ignorar un CHECKDB con errores porque “no ha fallado nada todavía”. Lo sabes tú, lo sabemos todos: el desastre no avisa. Pero sí se entrena. Así que más vale tener el plan listo y no necesitarlo, que necesitarlo y tener que improvisar.

May

2025

Introduccion a Service Broker

Hay funcionalidades de SQL Server que llevan años en la sombra, casi como reliquias de una época en la que creíamos que todo tenía que resolverse con triggers, cursores o, peor aún, con consultas agresivas cada 30 segundos. Entre esas joyas ignoradas, olvidadas o simplemente mal comprendidas, destaca Service Broker. No es nuevo, no es trendy y desde luego no tiene marketing detrás, pero cuando se entiende y se usa bien, hace cosas que ni Kafka ni RabbitMQ pueden soñar… al menos no sin invitar a medio equipo de infraestructura.

¿Qué es Service Broker y por qué sigue vivo?

Service Broker es el subsistema de mensajería nativo de SQL Server. Está ahí desde la versión 2005, y a diferencia de muchas promesas de aquella época, sigue funcionando sin necesidad de parches ni microservicios externos. La idea es sencilla: permitir que dos o más bases de datos se comuniquen de forma asíncrona, fiable, y con garantías de entrega, utilizando colas, mensajes y contratos definidos dentro del propio motor.

¿Parece demasiado bonito? Lo es, si lo usas bien. Pero claro, como todo en SQL Server, si lo activas sin entenderlo, puede acabar como aquel CLR que alguien dejó en producción y que ahora nadie se atreve a tocar.

Mensajes, contratos y colas: bienvenidos al lenguaje de Service Broker

La arquitectura de Service Broker se apoya en tres conceptos fundamentales: mensajes, contratos y colas.

Los mensajes son lo que uno espera: trozos de datos enviados de un punto a otro. Pueden llevar XML, texto, JSON, o lo que se te ocurra empaquetar mientras quepa en varbinary(max). Pero cuidado: si lo que mandas es basura, lo que recibes es basura asincrónica.

Los contratos definen qué tipos de mensajes se pueden intercambiar y quién puede enviarlos. Un contrato no es un capricho burocrático, es la única barrera entre un sistema robusto y un caos de mensajes huérfanos flotando en una cola sin dueño.

Las colas, por su parte, son objetos de base de datos donde se almacenan los mensajes. Pueden estar enlazadas a una tabla de activación, y de ahí lanzar procedimientos almacenados automáticamente cuando llega un mensaje. Y aquí es donde empiezan las posibilidades interesantes: procesamiento asíncrono, desacoplamiento lógico, incluso orquestación de tareas complejas sin necesidad de middleware externo.

Activación interna: el punto en el que Service Broker se vuelve interesante

Service Broker permite asociar una cola a un procedimiento almacenado. Cuando llegan mensajes nuevos, SQL Server puede lanzar automáticamente una instancia de ese procedimiento. Esto permite procesar eventos en tiempo real (bueno, en SQL-real) sin que el cliente tenga que esperar.

¿Significa esto que podemos hacer procesamiento paralelo dentro de SQL Server sin tocar SSIS, sin montar microservicios ni invocar APIs REST desde T-SQL? Exactamente. Con matices, claro. Esto no es Node.js, ni pretende serlo. Pero si lo que necesitas es procesar tareas, disparar workflows o mover datos entre bases, sin acoplar todo a una única transacción gigantesca, entonces estás en el lugar adecuado.

Un ejemplo real: procesar tareas sin freír el servidor

Supongamos que tenemos un sistema que necesita registrar operaciones de auditoría cada vez que un usuario modifica un registro crítico. Antes de que alguien proponga otro trigger que escriba directamente en la tabla de auditoría (y ralentice la operación principal), pensemos con más cabeza: ¿por qué no delegar esa escritura a un sistema asincrónico?

Con Service Broker, podemos:

Crear un mensaje con la información de auditoría.
Enviarlo a una cola específica.
Tener un procedimiento almacenado escuchando esa cola.
Procesar el mensaje y escribir la auditoría sin interferir con la transacción principal.

Esto no sólo mejora el rendimiento, sino que evita que un fallo en la auditoría reviente una operación de negocio. Sí, lo sabemos: no siempre se puede hacer, pero cuando se puede, es una diferencia de nivel.

Seguridad, rutas y conversación: lo que hay que saber de service Broker

Service Broker funciona bajo un modelo de «conversaciones» entre servicios. Sí, como las conversaciones de WhatsApp, pero con contratos y sin stickers. Estas conversaciones son bidireccionales y tienen estado, lo que permite enviar múltiples mensajes en ambos sentidos de forma controlada.

Para que todo esto funcione entre diferentes bases de datos o instancias, necesitamos definir servicios, rutas, y a veces, incluso certificados si vamos a cruzar servidores. Aquí es donde muchos tiran la toalla, porque no es trivial y la documentación oficial tiene ese encanto críptico tan característico de Microsoft cuando parece que no quiere que usemos algo.

Pero si superamos esta curva de aprendizaje pronunciada, podremos tener mensajería distribuida transaccional entre instancias SQL Server sin necesidad de colas externas, sin middleware y sin lag de 10 segundos.

¿Por qué no se usa más?

Primero, porque no está de moda. Service Broker no tiene un logo molón, ni una conferencia anual, ni camisetas con chistes de desarrolladores de colas. Pero eso no lo hace menos útil. Segundo, porque requiere entender T-SQL más allá del SELECT con JOIN, y eso ya elimina a cierto porcentaje de desarrolladores.

Y tercero, porque no se ha enseñado bien. Muchos lo han visto como «algo para entornos muy específicos», sin darse cuenta de que puede resolver problemas cotidianos: colas de trabajo, asincronía controlada, desacoplamiento entre componentes de una aplicación.

Cuándo usar Service Broker y cuándo no

No todo es un clavo, y Service Broker no es un martillo universal. Si necesitas alta escalabilidad, integración con sistemas heterogéneos o necesitas exponer eventos a sistemas no-SQL, probablemente debas mirar soluciones como Azure Service Bus, RabbitMQ o Kafka.

Pero si tu universo es SQL Server, si el cuello de botella está en las transacciones, y si quieres que los procesos se comuniquen entre sí dentro del mismo motor, entonces estás dejando pasar una oportunidad de oro si ignoras Service Broker.

Conclusión

Service Broker no es una bala de plata, ni pretende serlo. Pero es una de esas funcionalidades que, bien comprendidas, permiten diseñar soluciones limpias, escalables y robustas sin necesidad de inventarse una arquitectura de microservicios para cada cosa.

Y lo mejor es que ya está en tu SQL Server. Solo tienes que activarlo, entenderlo, y no cometer los errores de quienes pensaron que podían usarlo sin leer el manual. Porque sí, hay que cerrar las conversaciones, y no, no es opcional. Como dejar un BEGIN CONVERSATION sin END CONVERSATION: es como dejar una transacción abierta esperando que alguien más la cierre. O que venga un unicornio.

SQL Server

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes