SQL Server

May

2025

Antivirus en servidores SQL Server: ni sin él, ni contra él

Cuando hablamos de proteger un entorno SQL Server, lo primero que nos viene a la cabeza suelen ser los backups, la alta disponibilidad, los roles de seguridad, incluso el cifrado. Pero curiosamente, uno de los elementos más básicos de la protección –el antivirus– sigue siendo tratado como un accesorio molesto, o lo que es peor, como una amenaza potencial para el rendimiento. Y claro, en ese dilema entre seguridad y rendimiento, muchas veces se acaba apostando por el camino más cómodo: desactivar o ignorar.

No vamos a defender aquí que el antivirus es la piedra angular de la seguridad (no lo es), pero tampoco podemos dejar que el miedo a una caída de rendimiento justifique decisiones negligentes. Lo que necesitamos es un enfoque racional: configurar el antivirus de forma que proteja sin interferir con la operación normal del motor de base de datos. *Spoiler*: se puede. Lo difícil es que alguien lo haga bien.

¿Qué hace el antivirus y por qué molesta (si lo dejamos)?

El trabajo del antivirus es inspeccionar archivos y procesos en busca de patrones maliciosos. Nada nuevo. Lo que sí suele pasarse por alto es *cómo* lo hace: analiza archivos al abrirse, al modificarse, y en ocasiones al cerrarse. También puede inspeccionar procesos en memoria, acceder a redes compartidas, lanzar escaneos programados… y todo eso suena bastante normal hasta que lo dejas funcionando en un servidor SQL Server con una carga seria.

Porque claro, cuando el antivirus decide inspeccionar `tempdb.mdf` mientras el motor está haciendo un `HASH JOIN` como si no hubiera un mañana, empieza la fiesta: bloqueos, ralentizaciones, timeouts y, si tenemos suerte, algún bonito `IO_COMPLETION` en el error log. Y no olvidemos el momento en que el antivirus escanea los archivos `.ldf` en pleno `checkpoint`. Porque sí, todo archivo es sospechoso, incluso los que cambian cien veces por segundo.

El problema no es el antivirus. El problema es no configurarlo.

Archivos y procesos que debemos excluir

Vamos al grano. Hay una serie de rutas, extensiones y procesos que deben quedar fuera del radar del antivirus si queremos mantener la estabilidad y el rendimiento del servidor SQL Server. No es opcional. No es debatible. Está documentado por Microsoft, y si no lo aplicas, estás jugando a la ruleta rusa con discos girando.

Empezamos por los archivos:

– Las bases de datos, claro: archivos `.mdf`, `.ndf` y `.ldf`. Eso incluye todas las rutas donde se ubiquen, incluyendo `tempdb`. Da igual si están en discos SSD, en cabinas SAN o en la nube: fuera del antivirus.

– Los archivos de backup: `.bak`, `.trn`, `.sqb`, `.dif`, etc. Si el antivirus decide escanear un `.bak` de 500 GB en pleno restore, luego no nos preguntemos por qué tarda 2 horas más de lo previsto.

– Los archivos de trace, log y dumps generados por SQL Server (`.xel`, `.trc`, `.dmp`). Algunos de ellos se escriben en caliente, y otros pueden ser enormes.

– Las rutas de instalación de SQL Server y sus binarios (`sqlservr.exe`, `sqlagent.exe`, etc.). Los procesos de SQL no deberían ser intervenidos por el antivirus, especialmente durante eventos como reinicios o cambios de configuración.

También conviene excluir herramientas relacionadas que trabajen cerca del metal, como agentes de backup de terceros (Veeam, Commvault, etc.), soluciones de monitorización, y carpetas temporales utilizadas en procesos ETL, especialmente si están en el mismo servidor.

Y por supuesto: nada de escaneos programados sobre las unidades donde residen estos archivos. ¿Queremos una caída de rendimiento nocturna «espontánea»? Pues eso.

El antivirus SI tiene cabida en un servidor SQL

Llegados a este punto, alguien siempre pregunta: «¿Y si directamente no pongo antivirus?». Bueno, también puedes dejar la puerta del CPD abierta por si alguien quiere entrar a ver qué hay. Todo es cuestión de prioridades.

Un servidor SQL Server, aunque no navegue por Internet, puede estar expuesto a amenazas reales. Las vías de entrada son múltiples: conexiones RDP inseguras, accesos compartidos, usuarios que suben archivos, integraciones con sistemas vulnerables, incluso malwares que viajan dentro de backups. Y no olvidemos el ransomware, que no necesita un navegador para hacer su trabajo. Lo único que necesita es una puerta entreabierta.

Así que sí, el antivirus es necesario. Pero como con cualquier otra herramienta, hay que usarla con cabeza.

Buenas prácticas de configuración del antivirus

Ya sabemos qué excluir, pero ¿qué más podemos hacer para convivir con el antivirus sin odiarlo?

Lo primero, usar soluciones corporativas que permitan configurar políticas centralizadas. Nada de versiones domésticas ni «freemium» que prometen IA mágica y acaban con el 30% de tu CPU. Necesitamos un antivirus que permita gestionar exclusiones, programar escaneos fuera del horario de carga, y monitorizar actividad sin interferir con los procesos críticos.

Lo segundo, documentar las exclusiones. Es increíble la cantidad de veces que se instala un nuevo motor, se configura bien, y meses después alguien cambia el antivirus o actualiza políticas sin revisar nada. Resultado, el rendimiento se degrada, y nadie sabe por qué. Tener un documento claro con las rutas y configuraciones esenciales debería ser parte del estándar de despliegue.

Tercero, coordinar con el equipo de seguridad. Sí, esos que mandan correos con gráficos de amenazas que nadie entiende. Hablad con ellos. Enseñadles los KB de Microsoft. Explicad por qué hay que excluir ciertos archivos. Si lo hacéis bien, es posible que incluso lo agradezcan. Al final, todos queremos lo mismo, que el sistema esté seguro y funcione bien.

Y por último, revisar con cada parche o actualización. Las rutas cambian, las versiones cambian, y lo que funcionaba en SQL Server 2016 puede no ser igual en 2022. La tecnología cambia más deprisa que las excusas para no leer la documentación.

Recursos recomendados (y válidos)

Si alguien necesitas pruebas documentales para convencer al comité de seguridad, que tire de lo oficial. Microsoft tiene un artículo actualizado con las exclusiones recomendadas para SQL Server que puedes encontrar aquí.

También hay buenas prácticas en la documentación de cada solución antivirus empresarial. Lo importante es no quedarse en lo básico: si hay un `.exe` que escanea un `.mdf`, eso es un problema.

Conclusión

El antivirus en un servidor SQL Server no es el enemigo. El enemigo es la ignorancia operativa. Dejar un antivirus sin configurar es tan irresponsable como dejar que todo el mundo sea `sysadmin`. Y no, no exageramos.

Podemos tener rendimiento y seguridad. Pero como casi todo en esta vida (excepto los planes de licenciamiento de Microsoft), requiere esfuerzo. Excluir bien, revisar políticas, hablar entre equipos y no asumir que las cosas «ya vienen bien puestas».

Si seguimos confiando en que el antivirus «sabrá lo que hace», luego no nos sorprendamos si decide escanear `master.mdf` en mitad de un failover. Porque ya lo hemos dicho antes: el antivirus no es malo. Lo malo es dejarlo pensar por sí mismo.

Y no, no vamos a acabar este artículo diciendo que “la seguridad empieza por uno mismo”. La seguridad empieza por no meter la pata.

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

SQL Server 2025: IA dentro del motor, T-SQL como interfaz para modelos, y SSMS 21

Por fin tenemos motivos sólidos para decir que esta versión no es otra iteración sin alma. SQL Server 2025 no se limita a una lista de mejoras de rendimiento, ni a tres nuevos tipos de índice que nadie usará hasta dentro de tres años. Aquí estamos ante un cambio de paradigma: el motor se vuelve semánticamente inteligente, el T-SQL habla con modelos de IA, y SSMS deja de vivir anclado en 2012. Todo esto sin que tengamos que reescribir la mitad de nuestra lógica de negocio. Milagro.

Buscando con IA, sin sacar los datos de la base

Hasta ahora, hacer vector search implicaba montar un servicio aparte, duplicar datos, sincronizar embeddings y cruzar los dedos para que todo estuviera alineado. Bien, pues eso se ha acabado. SQL Server 2025 incorpora búsqueda vectorial directamente en el motor, usando como base el algoritmo DiskANN (Disk Approximate Nearest Neighbor) para encontrar similitudes de forma eficiente.

Y no solo eso: el motor genera embeddings y fragmenta texto (chunking) como parte de T-SQL. Nada de pipelines raros ni servicios auxiliares. El motor habla semánticamente, y por fin podemos dejar de fingir que los LIKE ‘%palabra%’ son soluciones de búsqueda.

Imagina buscar documentos similares, tickets de soporte parecidos o patrones repetidos en logs… sin tener que montar un Frankenstein con Python, Redis y una esperanza. Aquí, directamente desde SQL Server.

T-SQL como orquestador de modelos

Otra joya que han metido: los modelos de IA se definen y consumen desde T-SQL, y se accede a ellos mediante REST. Esto permite conectar con Azure OpenAI, Azure AI Foundry, Ollama, HuggingFace o cualquier servicio que hable HTTP.

Pero la parte realmente interesante es que puedes probar distintos modelos sin cambiar el código T-SQL, simplemente apuntando a otro endpoint. Es decir: pruebas, evalúas, decides… y el código sigue funcionando como si nada. Esto convierte a SQL Server en un auténtico hub de orquestación para IA aplicada a los datos.

Sí, a esto lo han llamado “AI integration”, pero no es humo de marketing: esto es infraestructura real para desarrolladores y DBAs que no tienen tiempo para montar castillos de arena en cada nuevo proyecto.

RAG con sentido: integración nativa con LangChain y Semantic Kernel

Otra novedad clave: SQL Server 2025 incluye soporte nativo para patrones de RAG (Retrieval-Augmented Generation). Lo que antes requería montar conectores desde LangChain, ahora se hace con integración directa. Embeddings, índices vectoriales, chunking… todo desde el motor. LangChain y Semantic Kernel pueden consumir directamente los datos sin malabares.

Esto significa que puedes montar aplicaciones conversacionales, asistentes internos o flujos inteligentes que consulten tus datos empresariales sin tener que exportarlos a ninguna otra base. Tus datos siguen seguros, tu rendimiento también, y tu aplicación parece inteligente.

SSMS 21: Git, Copilot y 64 bits… y no es broma

SQL Server Management Studio 21 ha salido del túnel del tiempo. Basado en Visual Studio 2022, ahora es una aplicación nativa de 64 bits (ya era hora), con actualizaciones automáticas (gracias, por fin) y soporte directo para Git.

Y lo mejor: Copilot ya está integrado (en preview). Lo puedes instalar como workload adicional, y te ayuda a:

Escribir y corregir T-SQL con lenguaje natural.
Generar scripts de mantenimiento.
Explicar consultas y sugerir optimizaciones.
Administrar configuraciones complejas con algo de contexto real.

¿Sustituye a un DBA con criterio? Ni de lejos. Pero es una ayuda decente que, usada con cabeza, puede acelerar muchas tareas del día a día. O al menos, evitar que tengamos que explicar por enésima vez qué hace un LEFT JOIN.

Python, JSON y expresiones regulares: tres cosas que ya no dan vergüenza

Se ha anunciado también un nuevo driver Python open source, desde cero, eficiente, moderno y mantenido por Microsoft. Olvida los hacks sobre ODBC: esto es serio, y se instala con pip install.

Y sí, JSON ahora se soporta de forma nativa en T-SQL. Ya era hora. Por fin podemos trabajar con documentos sin castings ni funciones intermedias. Lo mismo con RegEx: expresiones regulares nativas, sin tener que invocar CLR ni enviar los datos a PowerShell.

Esto desbloquea muchos escenarios de enriquecimiento de datos, validación y transformación dinámica, sin salir del entorno SQL.

Change Event Streaming: eventos sin CDC (ni drama)

Una joya más: Change Event Streaming permite emitir eventos directamente desde el transaction log a Azure Event Hubs, sin usar CDC. Esto no solo reduce la sobrecarga de I/O, sino que habilita arquitecturas reactivas mucho más limpias.

Puedes montar sistemas en tiempo real, agentes inteligentes que reaccionan a eventos de negocio, y todo con trazabilidad real. Y sin romperte la cabeza con triggers que nadie quiere mantener.

Rendimiento, disponibilidad y seguridad: seguimos afinando el motor

SQL Server 2025 incluye más de 50 mejoras en el motor, muchas de ellas en HADR, Columnstore, y procesamiento inteligente. Entre ellas:

Optimized Locking con TID Locking y Lock After Qualification, para reducir consumo de memoria y minimizar bloqueos.
Query Store disponible en secundarios de solo lectura, algo que llevábamos pidiendo años.
Mejoras en Intelligent Query Processing que aportan rendimiento sin tocar el código (veremos si los milagros existen o no).
Compatibilidad total con Microsoft Entra ID, para usar identidades gestionadas de forma segura y sin líos.

Y sí, sigue siendo la base de datos más segura según NIST. Ya no hace falta decirlo, pero está bien recordarlo por si alguien pregunta.

Fabric y la analítica sin ETL (casi)

SQL Server 2025 soportará database mirroring en Microsoft Fabric, permitiendo que los datos operacionales estén disponibles para análisis en tiempo casi real sin mover una sola tabla. No es exactamente magia, pero se le parece. Un puente directo entre operaciones y analítica, sin romper nada.

Developer Edition Standard: pruebas con realismo

Una novedad muy práctica: nueva Developer Edition Standard, gratuita pero limitada a las capacidades de la edición Standard. Ideal para probar comportamientos y validar configuraciones sin necesidad de recurrir a hacks ni entornos de “prueba/producción camuflada”.

Conclusión

SQL Server 2025 no es un service pack disfrazado. Es un cambio real, tanto en cómo usamos el motor como en cómo lo extendemos. La IA no es un complemento, es parte del core. Y eso nos obliga a entenderla, usarla y evaluarla con el mismo rigor con el que optimizamos un índice o afinamos una transacción.

Copilot ayuda, pero no sustituye. Las búsquedas vectoriales abren un nuevo paradigma, pero siguen requiriendo estructura y lógica de negocio. Y SSMS 21… bueno, al menos ya no se siente como una aplicación de otra década.

¿Vamos a activar todo esto en producción mañana? No. ¿Vale la pena empezar a probarlo y adaptarse? Sin duda. Y si queréis ver ejemplos reales, scripts de prueba y escenarios que no salen en las demos de marketing, os espero por aquí. Como siempre, alguien tiene que hacer las pruebas que importan.

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.

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.

SQL Server

Antivirus en servidores SQL Server: ni sin él, ni contra él

¿Qué hace el antivirus y por qué molesta (si lo dejamos)?

Archivos y procesos que debemos excluir

El antivirus SI tiene cabida en un servidor SQL

Buenas prácticas de configuración del antivirus

Recursos recomendados (y válidos)

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes