SQL Server

Jun

2025

DevOps y SQL Server: amor, odio y pipelines con fugas

El romance entre DevOps y SQL Server es complicado. Como esas parejas que se quieren a gritos, viven juntas, pero uno duerme en el sofá y el otro con el gato. Porque claro, DevOps suena precioso sobre el papel: integración continua, despliegues automáticos, infraestructura como código y todo ese rollo de agilidad infinita. Pero cuando llevamos eso a una base de datos relacional que todavía tiene stored procedures escritos en 2009 por alguien que ya no trabaja en la empresa… el cuento cambia.

Nosotros, los DBAs, vivimos en esa intersección peligrosa entre los mundos del código y los datos. Y cuando alguien decide que ahora todo tiene que ir por pipelines de CI/CD porque “lo ha dicho el consultor de DevOps”, hay que tener cuidado. Porque sí, automatizar es maravilloso. Pero automatizar sin entender es como montar un sistema de riego automático sin comprobar si hay goteras. Spoiler: las hay. Y en producción.

Vamos a ver cómo podemos integrar nuestro trabajo como DBAs en ese ciclo CI/CD sin que todo explote. O al menos, sin que explote demasiado.

DevOps, el síndrome del pipeline perfecto y la realidad del script roto

Hay que empezar aclarando una cosa: el mundo del desarrollo de software y el de las bases de datos no evolucionan igual. Mientras los desarrolladores compilan, versionan y despliegan sin mirar atrás, nosotros lidiamos con sistemas vivos. La base de datos no se borra y se vuelve a levantar como si fuera un contenedor. Cada ALTER TABLE toca datos reales. Y cada script mal planteado puede dejar un sistema en coma.

El enfoque de Database as Code nos ayuda a acercarnos al modelo DevOps. Usar herramientas como SSDT, Flyway, Liquibase, Redgate SQL Change Automation o, incluso, migraciones de Entity Framework, nos permite tener nuestros objetos versionados, controlar los cambios y desplegar de forma coherente. Hasta aquí, todo bien.

Pero claro, la teoría no menciona qué pasa cuando hay diferencias de collation entre entornos, cuando un índice tarda 45 minutos en crearse o cuando un trigger olvidado lanza una tormenta de inserts en cascada. Eso no lo arregla ningún pipeline.

Por eso, antes de lanzarnos a automatizar, necesitamos tener una estrategia de cambios bien pensada, un control de versiones sólido y, sobre todo, scripts que no se limiten a “funcionar en desarrollo”. El típico CREATE TABLE que nadie probó con un insert de 10 millones de filas no es infraestructura como código: es una amenaza.

Automatización con cabeza: lo que sí y lo que no en DevOps

No todo se debe automatizar. Sí, lo he dicho. Y lo repito. Hay tareas que siguen necesitando supervisión humana porque los datos no perdonan errores.

Automatiza los despliegues de cambios de esquema cuando están bien versionados y han pasado por entornos intermedios. Automatiza los backups, los restores de prueba, las revisiones de espacio en disco y las tareas de mantenimiento. Automatiza las revisiones de cumplimiento de convenciones con linting de scripts. Incluso automatiza los unit tests con tSQLt si tienes valor.

Pero no automatices, por ejemplo, la ejecución de un DROP COLUMN en producción sin que nadie revise qué otras vistas o procedimientos dependían de ella. Tampoco automatices sin revisión los despliegues que incluyen cambios destructivos o transformaciones masivas de datos. Y por supuesto, no pongas en un pipeline un script que actualiza 300 millones de registros en una tabla sin particiones y sin índices adecuados. Eso no es DevOps. Eso es sabotaje con CI/CD.

Porque sí, puedes tener despliegues automáticos cada cinco minutos. Pero si lo que despliegas son bombas lógicas, lo que estás haciendo no es integración continua: es desastre continuo.

DevOps si, pero con backups

Convertir la base de datos en código es un avance necesario. Repositorio Git, revisiones con Pull Requests, validaciones automáticas, historial de cambios… todo eso mejora la calidad y la trazabilidad. Nos permite dormir un poco más tranquilos. Por algo SSMS 21 incorpora soporte Git.

Pero ojo: base de datos como código no significa que los datos también lo sean. Los objetos son versionables. Los datos no lo son. No de la misma forma.

Por eso, ningún pipeline que toque la base de datos debería existir sin un buen backup previo. Y no, no vale con el backup nocturno. Un BACKUP DATABASE justo antes del despliegue, con nombre identificable y retención clara. Si algo va mal, hay que poder volver atrás. Nada de rezar a San Point-in-Time-Restore.

Además, si versionamos la base de datos, también hay que versionar los scripts de recuperación. ¿Qué haces si se despliega una función que rompe una lógica crítica? ¿Esperar a que el desarrollador vuelva de comer? No. Hay que tener plan B. Y plan C.

Roles y responsabilidades: DevOps no sustituye al DBA

En algunos modelos DevOps mal entendidos, parece que el DBA es prescindible. “Ya tenemos pipelines”, dicen. Claro. Y también tienes un coche, pero no han desaparecido los talleres mecánicos porque ahora sabes cambiar una rueda.

El rol del DBA en DevOps es más importante que nunca. Porque ahora, además de saber mantener sistemas estables, necesitamos saber cómo se integran en procesos automáticos, cómo se controlan los cambios, cómo se auditan los scripts y cómo se asegura la integridad del sistema en cada paso.

El DBA no solo ejecuta. Diseña el flujo. Revisa los PR. Define los checks de calidad. Valida la coherencia entre entornos. Y, sobre todo, es quien entiende que los datos no son líneas de código: son el corazón del negocio. Si fallan, no hay rollback que salve la reputación.

¿Y si todo explota igual?

Spoiler: alguna vez explotará. No importa lo bueno que sea tu pipeline. Alguien olvidará algo. Un script fallará. Una tabla no tendrá stats. Un índice nuevo matará el plan de ejecución.

Lo importante es que cuando eso pase, tengas herramientas para detectar, reaccionar y recuperar rápido. Logging detallado. Monitores activos. Backups listos. Versionado claro. Y sobre todo, un equipo que sepa que los despliegues no son cosa del azar, sino de la preparación. Herramientas como la de Four9s (sponsor de nuestros eventos online mensuales) ayudan a monitorizar estos cambios.

Porque en DevOps, como en SQL Server, todo funciona… hasta que no.

Conclusión

Integrar SQL Server en un entorno DevOps no es imposible, pero tampoco es trivial. Exige entender los riesgos, planificar con cabeza y automatizar sin perder el control. Versionamos código, sí. Pero protegemos datos. Y eso no se hace con fe ciega en YAMLs.

No somos un estorbo para la agilidad. Somos los que impedimos que se despliegue una migración irreversible a las 18:00 del viernes. Así que, si vamos a vivir en este nuevo mundo de CI/CD, vivamos con dignidad. Con backups. Con validaciones. Y con esa sospecha saludable de que un script sin revisar es una granada sin anilla.

El amor entre DevOps y SQL Server existe. Pero como todo amor real, necesita trabajo, comunicación y saber cuándo decir: “Esto mejor lo revisamos antes de darle al botón.”

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!

Jun

2025

¿Qué es xp_cmdshell y por qué deberías limitar su uso?

Hay ciertas funciones en SQL Server que tienen más leyenda que documentación, y una de ellas es xp_cmdshell. Mencionarla en una reunión de seguridad es como decir “TRIGGER” en una daily de DBAs: inmediatamente empiezan los sudores fríos. Pero como buenos profesionales de bases de datos, no podemos permitirnos el lujo de ignorarla. Hay que entender qué hace, cómo se usa (o se abusa), y sobre todo por qué en la mayoría de los casos deberíamos tenerla bien atada, o mejor aún, desactivada.

¿Qué es xp_cmdshell?

Para los recién llegados (o para los que han tenido la suerte de no cruzárselo nunca), xp_cmdshell es un extended stored procedure que permite ejecutar comandos del sistema operativo directamente desde SQL Server. Tal cual. Es decir, desde una sesión de SQL puedes invocar comandos como si estuvieras en la consola de Windows: copiar ficheros, lanzar scripts batch, ejecutar aplicaciones externas… o destruir medio sistema si tienes permisos suficientes y pocas luces.

El siguiente ejemplo es inocente (más o menos), pero ilustra la idea:

EXEC xp_cmdshell 'dir C:\';

SQL ejecuta el comando y te devuelve el resultado como si estuvieras en una consola de MS-DOS de los 90. Y sí, es tan peligroso como suena.

¿Para qué se usa xp_cmdshell legítimamente?

Hay quien justifica su uso con casos reales: automatización de procesos que interactúan con el sistema de archivos, lanzamiento de tareas administrativas, scripts que integran SQL con otros procesos batch o herramientas de terceros. Incluso estos ojos han visto escenarios donde se usaba para invocar clientes FTP y descargar archivos que luego se importaban con BULK INSERT o mover backups entre servidores.

Y aunque todo esto se puede hacer, la pregunta es: ¿debería hacerse así? Spoiler: no. O al menos, no sin un análisis serio de riesgos y alternativas. Porque una cosa es poder, y otra muy distinta es tener criterio.

La seguridad, el verdadero problema de xp_cmdshell

El mayor problema de xp_cmdshell no es su existencia, sino su potencia. Ya sabes, eso de que un gran poder conlleva una gran responsabilidad. Este procedimiento ejecuta los comandos en el contexto de seguridad de la cuenta del servicio de SQL Server, lo que, si no se ha configurado adecuadamente, puede significar ejecutar con privilegios elevados. Y eso convierte cualquier brecha de seguridad en una puerta abierta al sistema operativo, red y mil cosas más.

Por defecto, xp_cmdshell viene desactivada. Microsoft no es tonta, y sabe que dejar esto habilitado por defecto sería como enviar servidores a producción con el firewall desactivado. Pero como casi todo en SQL Server, se puede activar fácilmente:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Y una vez activada, el riesgo está servido. Cualquier usuario que tenga permisos para ejecutarla puede comprometer el servidor. Si encima tiene permisos sysadmin (y aún hay entornos donde todo el mundo es sysadmin «porque así funciona»), la fiesta está asegurada.

¿Se puede usar xp_cmdshell de forma segura?

La teoría dice que sí. Microsoft introdujo ciertas medidas para controlar su uso. Por ejemplo, si el usuario no es sysadmin, se puede configurar una cuenta proxy mediante el procedimiento almacenado sp_xp_cmdshell_proxy_account que limita los permisos con los que se ejecutan los comandos.

EXEC sp_xp_cmdshell_proxy_account 'DOMINIO\usuario', 'contraseña_segura';

Esto permite definir una credencial para que el comando xp_cmdshell se ejecute con los permisos de ese usuario en lugar de usar la cuenta del servicio. Pero seamos serios: ¿cuántas veces se hace esto bien en entornos reales? ¿Cuántas veces se revocan luego los permisos cuando ya no hacen falta? ¿Y cuántos servidores en producción tienen la proxy account configurada pero también usuarios sysadmin “temporales” que llevan ahí desde 2016?

Además, aunque configures la cuenta proxy correctamente, sigue siendo un punto de entrada que puede explotarse si no se audita y controla su uso. El riesgo persiste, solo se disfraza de buena práctica.

Alternativas reales y razonables a xp_cmdshell

Casi todo lo que se hace con xp_cmdshell se puede hacer mejor y con más control desde fuera de SQL Server. Si necesitas mover archivos, usar PowerShell o scripts externos lanzados desde un agente de automatización como SQL Server Agent o un sistema de orquestación decente (¿alguien ha dicho Azure Data Factory?) es mucho más razonable.

Para transferencias FTP o SFTP, hay herramientas modernas que no requieren meter comandos del sistema operativo en medio del motor de base de datos. Y si lo que se busca es coordinación entre procesos, los servicios de Windows, los job schedulers o incluso Integration Services son alternativas mucho más limpias.

SQL Server es un motor de bases de datos, no un sistema operativo ni un centro de comandos. Empezar a usarlo como tal es como usar un bisturí para abrir latas: técnicamente se puede, pero no es lo suyo y probablemente acabes con un desastre.

Auditar, controlar, eliminar

Si estás heredando un sistema y no sabes si xp_cmdshell está activa, revísalo. Yo personalmente es de las primeras cosas que compruebo. Para verlo es tan fácil como ejecutar:

EXEC sp_configure 'xp_cmdshell';

Si el valor de «config_value» es 1, está habilitado. Si no se está utilizando (y muchas veces no lo está, pero nadie se atreve a desactivarla “por si acaso”), desactívalo sin piedad:

EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

Y si alguien protesta, que traiga el caso de uso documentado, el análisis de riesgos y una alternativa propuesta. Si no puede justificarlo, no es necesario. Punto. No admito discusiones.

Además, si en algún entorno necesitas activarlo temporalmente, documenta cuándo y por qué, y asegúrate de desactivarla después. Y lo más importante: registra quién tiene permisos para usarlo, y controla ese acceso como si fuera el código para activar el botón rojo nuclear. Porque en cierto sentido, lo es.

Conclusión

xp_cmdshell es una herramienta poderosa, pero como todas las herramientas poderosas, puede causar más daño que beneficio si se usa mal. No está pensada para ser parte habitual de ningún flujo de trabajo moderno en SQL Server. Su existencia tiene sentido en contextos muy controlados, con auditoría, justificación y planificación. Pero la realidad es que en la mayoría de los entornos en los que aparece, lo hace como un parche rápido, una chapuza heredada o un atajo que algún valiente implementó sin medir consecuencias.

Limitar o eliminar su uso no solo mejora la seguridad del entorno, sino que obliga a buscar soluciones más sostenibles, limpias y profesionales. Porque si nuestra base de datos necesita ejecutar scripts del sistema para funcionar, igual el problema no está en xp_cmdshell, sino en cómo hemos diseñado la arquitectura.

Y si aún piensas que «no pasa nada por tenerla habilitada», revisa tus backups. Puede que los necesites antes de lo que crees, o que alguien los haya borrado desde xp_cmdshell.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Jun

2025

Búsquedas semánticas con IA en SQL Server 2025

En algún momento entre pelear con índices zombis y migraciones eternas, Microsoft ha decidido que SQL Server también podía ser inteligente. Y no me refiero al tipo de inteligencia que esperas de un MERGE bien hecho (que ya sabemos que es difícil de ver), sino a IA de verdad: modelos de lenguaje, embeddings, vectores y búsquedas semánticas integradas directamente en el motor. Sí, en nuestro motor de base de datos favorito.

En este artículo vamos a desmenuzar la nueva funcionalidad de SQL Server 2025 que permite integrar modelos de IA para realizar búsquedas semánticas directamente desde SQL. Sin inventos raros y, lo más sorprendente, sin tener que abandonar nuestro entorno habitual. Ahora podemos chatear con nuestros datos sin salir del Management Studio.

Inteligencia artificial en SQL Server: la cosa se pone serIA

(Perdón por el chiste. Es malísimo, lo sé)

Esto no es un plugin experimental ni una feature de análisis de datos metida con calzador. Microsoft ha incorporado capacidades de IA directamente en el motor de SQL Server. Y eso significa que podemos invocar modelos de lenguaje desde procedimientos almacenados, generar embeddings, indexarlos y hacer comparaciones semánticas en caliente.

Y todo sin que los datos salgan del servidor. La seguridad y el rendimiento siguen siendo prioridad: lo que hacemos es pasar una consulta a un modelo que genera un vector (el embedding) y lo compara con los vectores previamente almacenados localmente. Resultado: respuestas rápidas, semánticamente relevantes y sin montar un chiringuito en Azure (solo unos pocos clicks).

Vectores, embeddings y cosenos: la IA no entiende palabras, entiende números

Esto tiene que quedar claro desde el principio, la IA no trabaja con texto. Aunque lo parezca, la IA no sabe leer. Internamente trabaja con vectores, que son representaciones matemáticas de conceptos. Un vector es simplemente una lista ordenada de números (normalmente de 1536 dimensiones) que representa el “significado” de algo.

Cuando decimos “bicicleta para descenso de montaña”, un modelo de lenguaje genera un vector que encapsula ese significado. Ese vector es un embedding. Y lo interesante es que podemos comparar ese embedding con otros ya almacenados, usando la similitud de coseno, para encontrar los conceptos más cercanos.

Cuanto más cercano es el ángulo entre dos vectores, más parecido es su significado. No hay magia. Hay trigonometría. Pero no te preocupes, que no vas a tener que calcularlo tú: eso se lo dejamos al motor, que para eso está.

¿Cómo implementar esta IA?

En mis pruebas he usado AdventureWorks, cómo no. Desde la tabla de productos, extraemos las descripciones y, a esas descripciones, les generamos embeddings usando un procedimiento almacenado que recibe un texto y lo envía al modelo modelo en Azure OpenAI (podría ser otro, incluso en local, pero aquí opte por ir a lo fácil y rápido). Importante guardar estos embeddings en una tabla separada: más limpio y mejor rendimiento.

Por último, creamos un segundo procedimiento almacenado que recibe una frase, genera su embedding con el SP anterior y, una vez obtiene su embedding lo compara con los embeddings almacenados en base para devolver los más cercanos. Y sí, todo desde SQL. Llamadas REST mediante, pero dentro de una SP.

Así obtenemos resultados en milisegundos. Eso es lo que tarda en calcular el embedding de una petición y compararlo con los datos. Rápido, elegante, sin ETLs de por medio y sin mover los datos de casa (siempre que uses un modelo local, claro).

¿Qué es esto de las búsquedas semánticas? La magia de la IA en SQL

Este es el verdadero factor diferenciador. No estamos hablando de una búsqueda con like ni de índices de texto completo (Full Text Indexes). Los embedding representan el significado de las palabras de manera que aspectos como sinónimos o incluso, el idioma de la búsqueda dejan de ser un impedimento.

En mis pruebas las descripciones de producto están en inglés, francés o incluso en chino. Yo he probado con prompts en español, inglés e incluso con redacciones ambiguas. El modelo entiende el significado, no la forma. Así que da igual si pides “bicicleta de descenso” o “bike for downhill mountain racing”: el embedding será muy similar y los resultados coherentes.

Una vez que te acostumbras, el LIKE te empieza a parecer una piedra tallada con cincel.

Aplicaciones reales más allá del hype

Vale, comparar descripciones de productos es “la demo fácil”. Pero no significa que no tenga valor ni que esto no se pueda llevar mucho más allá.

Gracias a esta funcionalidad puedes recomendar artículos relacionados en tu tienda web. Pero no es el único caso de uso.

¿Tienes transcripciones de llamadas de soporte técnico? Embeddings. ¿Tienes feedback de clientes en la web? Embeddings. ¿Quieres analizar opiniones para saber si tu producto gusta o no? Más embeddings. Puedes clasificar sentimientos, detectar patrones de insatisfacción, anticipar problemas o simplemente automatizar búsquedas que hasta ahora eran imposibles sin intervención humana.

Y todo desde SQL Server. Sin montar pipelines, sin exportar a otro sistema, sin líos innecesarios. Aquí, en casa. Y eso, para un DBA con años de cicatrices, es música celestial pero también asusta. ¿Cómo va a impactar esto en nuestros sistemas? Solo el tiempo y el uso en cada escenario lo dirá.

Comparaciones por dentro: un vistazo rápido al cálculo de la IA

[Modo TryHard Activado] Por si tienes curiosidad matemática (o simplemente quieres saber si todo esto tiene sentido), el cálculo de similitud se basa en cosenos. Lo que estamos haciendo es comparar dos vectores, en nuestro caso el del prompt y el del producto. Para eso lo que se hace es calcular su producto escalar, sus magnitudes, y aplicar la fórmula del coseno.

Similitud = cos(θ) = (A·B) / (||A|| * ||B||)

Y la distancia, por si necesitas algo más crudo, es simplemente 1 – similitud. Cuanto más cercana a cero, más similares. Cuanto más cerca de uno, más distintos.

¿Y qué hacemos con eso? Ordenamos por similitud y nos quedamos con los más relevantes. No hay magia negra. Es álgebra lineal.

Conclusión

Esto no es hype. No es una demo para sorprender en eventos. Es una funcionalidad real, integrada, segura y rapidísima que cambia la forma en la que interactuamos con los datos.

SQL Server 2025 ha dejado de ser solo un motor relacional. Ahora también es un intérprete semántico. Y eso abre puertas que antes ni sabíamos que existían.

Lo dicho: si pensabas que lo habías visto todo en SQL, ya puedes ir quitándote esa idea de la cabeza. Y si no empiezas a trastear con embeddings, búsquedas semánticas y llamadas a modelos de lenguaje… no digas luego que no te avisamos.

Esto ha venido para quedarse. Y aquí, como siempre, trataré de analizarlo en condiciones.

May

2025

Lean para DBAs: eliminar el desperdicio (y el cursillo de moda)

Vamos con otro artículo de metodología aplicada a SQL Server. Hoy toca una metodología menos conocida pero para mi de gran valor, LEAN. Lean es la palabra mágica que hace que cualquier presentación aburrida parezca una revolución. Hay quien piensa que Lean consiste en ponerse una camiseta con el logo de Toyota (precursores de esta metodología) y hablar de “mejora continua” sin decir nada concreto. Pero aquí no venimos a vender humo ni a repetir mantras vacíos. Aquí hablamos de cómo aplicar Lean en serio a nuestro trabajo como DBAs. Sin PowerPoints. Sin pegatinas. Y, sobre todo, sin tragarnos otro cursillo que acaba recomendando reuniones diarias de 15 minutos para no hacer nada nuevo.

Porque sí, los principios de Lean se pueden aplicar, y deben aplicarse, a la administración de bases de datos. Y no hablamos de crear un Value Stream Map con forma de sushi. Hablamos de identificar lo que no aporta valor a nuestros sistemas, a nuestros usuarios o a nuestra paz mental. De dejar de hacer tareas inútiles solo porque “siempre se han hecho así”. De eliminar el desperdicio, y hacerlo con método.

El “desperdicio” en el mundo real de un DBA

En Lean, la palabra clave es waste. Desperdicio. Actividades que consumen tiempo, recursos o esfuerzo y no generan valor. Y en nuestro día a día, eso abunda.

¿Ejemplos? Te doy algunos, pero seguro que te suenan demasiado: backups completos diarios de bases de datos que no han cambiado en una semana, scripts de mantenimiento que indexan sin sentido aunque la fragmentación no supere el 5%, checks automáticos que revisan tablas ya desactivadas o de sistemas obsoletos, informes que se generan cada madrugada y van directos a una carpeta compartida… donde nadie entra desde 2019 o jobs heredados con nombres como job1, job2, no_borrar, PRUEBA, nuevo2_FINAL.sql.

Eso es desperdicio. En todos los sabores posibles. Y lo peor: lo hemos normalizado. Hacemos backups duplicados “por si acaso”. Aceptamos tareas inútiles como “proceso estándar”. Nos aferramos a jobs zombis porque “nadie sabe si siguen siendo importantes”.

Lean propone lo contrario: identificar, reducir y eliminar lo que no aporta valor. Y no, eso no significa automatizarlo todo o borrarlo a lo loco. Significa mirarlo de frente y preguntarse: “¿Esto sirve para algo? ¿Alguien lo necesita? ¿Tiene impacto?”.

Cómo detectar el desperdicio sin parecer el saboteador oficial

Eliminar tareas inútiles es fácil. Hacerlo sin que te acusen de sabotaje o de romper el sistema, no tanto. Porque muchos de estos desperdicios vienen envueltos en la bandera del “mejor prevenir que curar” o del “esto siempre ha estado así”.

La clave está en aplicar los principios de Lean sin ir con la motosierra. Hay que actuar con estrategia.

Primero: identifica lo inútil con datos. No digas “este job es una chorrada”. Di: “Este job tarda 45 minutos, genera 0 filas y no ha dado una alerta útil en 18 meses”. Luego, muestra el coste: CPU, disco, tiempo, mantenimiento. Y plantea la pregunta correcta: “¿Qué pasa si lo quitamos?”. Si la respuesta es “nada”, ya tienes vía libre. Si la respuesta es “ni idea”, entonces hay que hacer una revisión seria.

Segundo: prioriza por impacto. No empieces por el informe de marketing que solo ocupa 5 MB. Empieza por la base de datos duplicada que se respalda a diario con 500 GB inútiles. Eliminar lo pequeño está bien, pero eliminar lo grande se nota.

Tercero: documenta todo lo que limpias. Sí, sabemos que nadie lee los tickets, pero si en dos meses alguien te pregunta “qué pasó con el job que hacía el backup de la base de pruebas de 2017”, necesitas tener una traza clara. Borrarlo sin dejar rastro es receta para el desastre (y para que te culpen de todo lo que falle después, aunque no tenga nada que ver).

Y cuarto: no esperes permiso para mejorar. Pide permiso para probar, no para pensar. En Lean, la mejora continua no se hace en reuniones. Se hace observando el sistema y actuando con criterio.

Lo que Lean puede enseñarnos (sin que nos convirtamos en coaches de LinkedIn)

En esencia, Lean te invita a mirar tus procesos con una pregunta clara: ¿Esto aporta valor? Y si la respuesta es no, entonces no debería existir.

Como DBAs, eso significa:

Analizar el uso real de las tareas programadas. ¿Se consultan? ¿Se consumen?
Medir el retorno del mantenimiento. ¿Indexar cada noche mejora algo? ¿Detectar fragmentación mínima vale la pena?
Revisar scripts heredados. ¿Siguen siendo necesarios? ¿Tienen un propósito actual?
Validar backups. ¿Se pueden restaurar? ¿Se necesitan todos? ¿Con qué frecuencia?

Y sí, a veces eliminar un backup inútil es más útil que implementar otro monitor de backups. A veces evitar una ejecución innecesaria es más valioso que documentarla. Lean no va de “hacer más cosas mejor”. Va de hacer menos cosas inútiles.

¿Lean sin post-its? Sí, gracias

Si algo nos enseña Lean es que mejorar un sistema no siempre requiere grandes cambios. A veces solo hace falta dejar de hacer lo innecesario. Y eso, en el mundo de un DBA, es un superpoder.

No necesitamos mapas de valor ni ceremonias de reflexión semanal. Solo necesitamos aplicar sentido común técnico y tener el coraje de cuestionar lo establecido. Porque mantener jobs inútiles por costumbre no es precaución. Es ruido.

Así que sí, aplica Lean. Pero hazlo como lo haría un DBA: con logs, con datos, con impacto medible. Sin tanto adorno. Y si de paso te quitas unas cuantas tareas absurdas de encima, mejor aún.

May

2025

Nuevo driver oficial de Microsoft para SQL Server en Python

Sí, después de años de conectar Python a SQL Server con herramientas que parecían salidas de un laboratorio de Frankenstein (pyodbc, te estamos mirando), Microsoft se ha decidido a hacer lo que muchos llevábamos años pidiendo: un driver oficial, moderno y diseñado para funcionar sin depender de ODBC ni de contorsiones a lo MacGyver.

Y lo mejor: es open source, cumple el estándar DB API 2.0, y apunta a convertirse en el nuevo camino recomendado para integrar Python con SQL Server, Azure SQL Database y Azure SQL Managed Instance.

Adiós (por fin) al infierno de pyodbc en python

Durante años, la opción más común (porque no había otra) para conectar Python con SQL Server era pyodbc. Un proyecto comunitario que, para qué negarlo, ha hecho lo que ha podido. Pero que lleva años dependiendo de compilaciones difíciles, bindings a ODBC que no encajan bien en todos los sistemas, y documentación escrita con la misma pasión que una hoja de Excel vacía.

Instalar pyodbc en un entorno moderno de Docker o en Alpine Linux es una forma de tortura que debería estar regulada por la ONU. Y si encima necesitas autenticación integrada con Azure AD, entonces directamente entras en territorio de rituales esotéricos.

Por eso este movimiento de Microsoft no es menor. Es un cambio de paradigma: el reconocimiento oficial de que el stack Python merece un driver real, propio y moderno.

¿Dónde está la trampa? Tranquilos, ahora lo vemos.

Un driver para python nuevo y propio, sin ODBC y sin sobresaltos

El nuevo driver se llama mssql-python. No se basa en ODBC, ni depende de componentes externos como msodbcsql o FreeTDS. Utiliza algo que Microsoft ha bautizado como Direct Database Connectivity (DDBC), que en esencia permite hablar directamente con SQL Server a través del protocolo TDS sin intermediarios, drivers del sistema ni DLLs que haya que compilar con cada luna nueva.

Esto es un salto técnico importante. ODBC ha sido históricamente la forma “oficial” de conectar con SQL Server, pero en Python eso ha traído más dolores de cabeza que soluciones. Compilaciones fallidas, incompatibilidades con Alpine, dependencias externas y errores crípticos eran el pan de cada día. Con mssql-python, ese ecosistema de dolor empieza a tener alternativa.

Estado actual del proyecto driver python: alfa, pero con fundamentos

No todo es champagne todavía. Este driver está en fase alfa. Microsoft lo ha publicado para recoger feedback y validar los fundamentos básicos: conexión, ejecución de consultas, gestión de transacciones y autenticación, incluyendo Microsoft Entra ID (el antiguo Azure AD, para los que aún no han pasado por el rebranding de turno).

¿Se puede usar en producción? No. ¿Se puede probar? Sí. ¿Está en PyPI? También:

pip install mssql-python

Y por una vez, no hay que instalar controladores de sistema ni configurar ficheros .ini. Funciona directamente desde Python con una cadena de conexión estilo:

import mssql_python

connection = mssql_python.connect(
   SERVER=localhost;DATABASE=TestDB;UID=sa;PWD=PasswordSuperSegura123!;Encrypt=yes;"
)
cursor = connection.cursor()
cursor.execute("SELECT TOP 10 * FROM customers")
rows = cursor.fetchall()
for row in rows:
    print(row)
connection.close()

Más sencillo imposible. Bueno, sí: cuando añadan soporte para async nativo. Pero ya llegará.

Cumplir con DB API 2.0 desde python, por fin algo estándar

El driver está diseñado para cumplir de forma estricta la especificación DB API 2.0. Para quien no lo sepa (o lo haya borrado de su memoria por razones de salud mental), esto significa que se respetan los contratos mínimos esperables en un driver Python serio:

Conexiones y cursores como objetos nativos.
commit y rollback para transacciones explícitas.
Sustitución de parámetros segura (nada de concatenar strings como si fuera PHP en 2005).
Manejadores de errores consistentes y previsibles.

Y esto, en resumen, significa compatibilidad real con librerías Python estándar, sin tener que escribir adaptadores caseros como hacíamos con pyodbc.

¿Y qué hay de la autenticación, el talón de Aquiles de los drivers para python?

Aquí es donde el driver empieza a mostrar músculo. Desde el inicio, mssql-python da soporte para Microsoft Entra ID, en todas sus variantes modernas: usuario/contraseña (la clásica), identidad administrada (tanto de sistema como de usuario), autenticación interactiva y, por supuesto, autenticación integrada en entornos federados (Windows domain join).

Esto lo convierte en una pieza muy prometedora para entornos cloud híbridos o deployments sobre Azure. No más hacks con msal, ni configuraciones imposibles para autenticar desde un contenedor.

Eso sí: el soporte completo para Linux y macOS está en camino. De momento, solo funciona en Windows. Así que si tu entorno de trabajo está en Docker sobre Alpine, o si eres de los que creen que conda es una religión, tendrás que esperar (o probar en WSL si no tienes miedo).

¿Qué no tiene todavía este driver de python?

Seamos justos: esto acaba de empezar. El driver está en su infancia, y aunque los cimientos son sólidos, todavía faltan cositas. No hay soporte para async (aunque está en el roadmap), tampoco integración directa con pandas o DataFrames (uff eso ya empieza a picar), carga masiva tipo bcp, pooling de conexiones configurable ni soporte multiplataforma completo.

Así que no tires pyodbc a la papelera todavía. Pero sí es momento de empezar a jugar con este nuevo driver y plantearse seriamente mover futuras integraciones hacia él.

¿Y el código? ¿Dónde está?

Todo el proyecto está en GitHub, bajo licencia MIT. Eso sí, las DLLs internas (las que hacen la magia de hablar con SQL Server) están cubiertas por licencia propietaria de Microsoft, aunque incluidas en el paquete.

El resto del driver puede auditarse, modificarse y contribuirse sin problemas. Y de hecho, Microsoft está activamente pidiendo feedback de la comunidad. Si detectas errores, incoherencias o tienes sugerencias, hay mecanismos claros de contribución y un bot de CLA que automatiza el papeleo.

Conclusión

Microsoft ha dado un paso importante (y muy necesario) con mssql-python. Por primera vez en años, tenemos un driver para Python específicamente diseñado para SQL Server, sin ODBC, sin complicaciones y con estándares modernos.

Aún está verde, sí. Pero si esto evoluciona como promete, podríamos estar ante el reemplazo natural de pyodbc en entornos Python. Con mejor experiencia, menos dependencias externas y soporte directo para autenticación empresarial, este driver tiene todos los ingredientes para convertirse en un estándar real.

La pelota está en el tejado de Microsoft. Ahora toca ver si cumplen lo que han empezado.

May

2025

ZSTD en SQL Server 2025: la compresión que por fin tiene sentido

Con SQL Server 2025, Microsoft ha decidido que ya era hora de dejar atrás el vetusto algoritmo MS_XPRESS para la compresión de backups y nos presenta a su nuevo juguete: Zstandard, o ZSTD para los amigos. No se trata de una mejora menor ni de un simple lavado de cara. Estamos ante un cambio real, tangible y, lo más importante, medible. Porque ya está bien de hacer backups comprimidos que no se sabe si salvan espacio o lo rellenan de aire.

En este artículo nos meteremos de lleno en las pruebas reales de rendimiento y compresión usando este nuevo algoritmo en la versión preliminar de SQL Server 2025 (17.x). Y sí, he hecho los deberes: mismo entorno, misma base de datos, mismas condiciones. Porque si vamos a hablar de rendimiento, hay que hacerlo como profesionales, no como vendedores de humo.

Un poco de contexto en esto de la compresión (pero solo el justo)

Hasta ahora, la compresión de backups en SQL Server se basaba principalmente en MS_XPRESS, ese algoritmo que venía con SQL Server y que, siendo honestos, cumplía. Pero cumplía como un coche de hace 20 años: te lleva, pero consume más de lo que debería y no gana ninguna carrera.

SQL Server 2025 introduce ZSTD como nuevo algoritmo de compresión, y según la propia documentación oficial, se trata de un método más rápido y más eficaz. No es marketing barato: ZSTD lleva años siendo la niña bonita del mundo open source, utilizado en proyectos como Facebook, zfs o Kubernetes. Y ahora por fin aterriza en SQL Server.

Escenario de pruebas: sin cuentos

He estado leyendo e intercambiando opiniones con otros compañeros MVPs de Microsoft y algunas pruebas les arrojaban reducciones de tiempo de hasta un 50%. Yo tenía que probarlo, y además he utilizado la base de datos StackOverflow2013 para las pruebas. Una base de datos con más de seis millones de páginas de datos (más de 50Gb) suficiente para ver diferencias significativas. Además con campos de texto grandes y pocos valores nulos o repetidos, cosas que siempre han puesto en aprietos a la compresión de SQL Server. Todo un reto para el nuevo algoritmo.

Todas las pruebas las he ejecutado en la misma instancia de SQL Server 2025 CTP 2.0, con la base de datos restaurada entre cada backup para mantener la consistencia. Ni trucos, ni trampa, ni memoria caché jugando sucio.

Backup tradicional con compresión MS_XPRESS

Para esta primera prueba vamos a realizar un backup con la comprensión tradicional de SQL Server para saber contra qué estamos comparándonos.

BACKUP DATABASE [StackOverflow2013]
TO DISK = N'C:\Program Files\...\StackOverflow2013.bak' 
WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

Resultados:

Tiempo total: 327 segundos
Velocidad media: 147.289 MB/seg
Tamaño comprimido: 14.84 GB

Backup nuevo con compresión ZSTD

Llega el momento de la verdad, ahora que ya tenemos una base sobre la que mejorar vamos a probar con el nuevo algoritmo de compresión de backups ZSTD.

BACKUP DATABASE [StackOverflow2013]
TO DISK = N'C:\Program Files\...\StackOverflow2013_ZSTD.bak'
WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, COMPRESSION (ALGORITHM = ZSTD), STATS = 10;

Resultados:

Tiempo total: 300 segundos
Velocidad media: 160.092 MB/seg
Tamaño comprimido: 14.51 GB

Sí, has leído bien: más rápido y más comprimido. Porque para eso se inventan los algoritmos modernos, no para rellenar documentación técnica.

¿Y el espacio en disco? ¿Realmente hay más compresión?

Aquí no hay opiniones: hay archivos .bak. Si miramos los tamaños de las copias que acabamos de hacer estos son los datos:

MS_XPRESS: 14.498.432 KB
ZSTD: 14.169.192 KB

En torno a 329 MB menos por backup. Insisto: suma eso en entornos de alta frecuencia y multiinstancia, y deja que el almacenamiento te dé las gracias.

Restauraciones

También he restaurado ambas copias para verificar si hay diferencias apreciables en el proceso inverso. Al fin y al cabo, para eso hacemos backups. Y normalmente, cuando restauramos una copia de seguridad lo hacemos con prisa, no me preguntes por qué.

En este sentido, la copia con el algoritmo de compresión tradicional MS_XPRESS ha tardado 377 segundos, restaurando a 127.763 MB/seg. Por su parte, la copia con el nuevo algoritmo ZSTD se ha restaurado en 361 segundos a una media de 133.328 MB/seg.

Una diferencia de rendimiento modesta, pero constante, a favor de ZSTD. No rompe récords, pero definitivamente no es humo.

Relación de compresión

Veamos por último la relación de compresión de nuestras copias. Esto podemos verlo directamente de msdb.dbo.backupset con una sencilla consulta.

SELECT database_name, compression_algorithm, backup_size, compressed_backup_size, backup_size / compressed_backup_size AS CompressRatio
FROM msdb.dbo.backupset
WHERE database_name = 'StackOverflow2013';

Tampoco estamos ante un milagro, pero la mejora es real. Y si alguien piensa que medio punto en ratio de compresión no importa, que multiplique eso por 500 bases de datos diarias y hablamos. Además, recuerda, el ejemplo que he usado es de los menos favorables para una compresión.

Cómo habilitar la compresión ZSTD (cuando funcione bien)

ZSTD se puede usar de dos formas, la forma explícita que acabamos de ver, indicando el algoritmo en el comando BACKUP WITH COMPRESSION (ALGORITHM = ZSTD) o bien configurando el servidor para usarlo como valor predeterminado. Para eso lo definiremos en la configuración con este comando:

EXEC sp_configure 'backup compression algorithm', 3;
RECONFIGURE;

Ahora bien, aquí viene la parte divertida (léase con sarcasmo): actualmente hay un bug conocido en la configuración global. Es decir, puedes especificarlo manualmente sin problema, pero si intentas poner ZSTD como predeterminado a través del sp_configure, el sistema puede ignorar olímpicamente. No lo decimos nosotros, lo dice la propia documentación oficial de Microsoft en letras púrpuras. Nada grave sabiendo que aun es una versión preliminar.

Así que por ahora, mejor dejar ese WITH COMPRESSION (ALGORITHM = ZSTD) bien escrito en los scripts de mantenimiento y olvidarse de configuraciones globales hasta que alguien en Redmond se acuerde de arreglarlo antes de la disponibilidad general del producto.

Conclusión

ZSTD ha llegado a SQL Server y no como un simple añadido, sino como una alternativa seria al clásico MS_XPRESS. Mejora el rendimiento, reduce el tamaño y lo hace sin pedir permiso ni romper nada. ¿Es perfecto? No. ¿Está listo para producción? Aún no, está en preview. ¿Vale la pena probarlo? Sin duda.

En mis pruebas ha demostrado ser más eficiente, más rápido y ligeramente más eficaz en términos de compresión. Y si Microsoft arregla ese problemilla con la configuración global, puede convertirse en el nuevo estándar para backup en SQL Server.

Así que, si estás probando SQL Server 2025, ya estás tardando en incluir ZSTD en tus scripts. Y si aún sigues con backups sin compresión porque “es más seguro así”, quizás también sigas usando cintas magnéticas. En fin.

Yo por mi parte, ya lo tengo apuntado en el check de “cosas que sí merecen la pena en esta versión”. Habrá que ver si termina estando disponible en SQL Server Standard o solo en las versiones Enterprise.

May

2025

SQL Server bajo metodologías Agile: ¿Sprint o esguince?

Desde hace unos años, las palabras scrum, sprint y kanban se pasean por los pasillos del departamento de IT como si fueran las nuevas religiones del desarrollo. Todo es Agile. Todo es iterativo. Todo es colaborativo. Pero cuando uno trabaja con SQL Server, especialmente desde el lado de administración o desarrollo de bases de datos, la pregunta no es si Agile tiene sentido. La pregunta es si sobreviviremos al intento de aplicarlo.

Spoiler: se puede trabajar bien con Agile en entornos de SQL Server. Pero también se puede hacer tan mal que acabas con más deuda técnica que un país en default. Vamos a hablar de cómo aplicar principios Agile sin romper el modelo de datos, sin convertir cada sprint en un festival de migraciones mal versionadas, y sin sacrificar la estabilidad en nombre de una falsa “velocidad”.

¿Qué pinta una base de datos en un sprint Agile?

Uno de los grandes malentendidos cuando se mete a SQL Server dentro de un equipo Agile es asumir que los cambios en base de datos son iguales que tocar código. Spoiler: no lo son. El código es fácil de versionar, reversible y aislado. La base de datos es persistente, compartida y en producción suele ser más vieja que muchos de los devs que la usan.

A pesar de eso, en muchos equipos se nos pide trabajar “por historias”, entregar cambios “al final de cada sprint” y hacer despliegues “continuos”. ¿Y qué podría salir mal cuando cada dos semanas hay que versionar un esquema que afecta a 7 aplicaciones, 3 procesos ETL y un cubo de SSAS?

Por eso, el primer paso para aplicar Agile en SQL Server es entender que no somos iguales. No somos un microservicio. No podemos borrar y volver a compilar la base de datos en cada commit. Tenemos otra naturaleza y, por tanto, otras prácticas.

La trampa de las historias de usuario para bases de datos

Otra joya del enfoque Agile mal entendido: escribir historias de usuario para tareas de base de datos. “Como usuario quiero que el sistema guarde más información sobre los pedidos”. Y con eso se supone que debemos deducir que toca añadir 4 columnas, migrar millones de registros históricos, modificar 5 procedimientos almacenados y rezar para que el index seek sobreviva. Todo eso en 3 días.

En SQL, una historia mal escrita puede implicar semanas de refactor. O peor aún, puede parecer sencilla hasta que en QA revientan los tiempos de respuesta por culpa de una tabla sin estadísticas actualizadas.

¿Queremos usar historias de usuario? Perfecto. Pero que estén escritas por alguien que entienda el impacto en la base de datos. Y si no lo saben, que pregunten. A tiempo.

CI/CD y versionado de bases de datos: entre la teoría y el desastre

Uno de los pilares del Agile moderno es el uso de pipelines de integración y entrega continua. Maravilloso concepto. En teoría, cada cambio va versionado, probado, y desplegado automáticamente. En la práctica, cuando metemos SQL Server en la ecuación, muchos pipelines acaban con más condicionales que un CASE mal diseñado.

La verdad es que versionar correctamente una base de datos requiere herramientas específicas. No vale con subir scripts sueltos a un repositorio. Hablamos de herramientas como Flyway, Redgate SQL Source Control o SSDT bien utilizado. Y no, tirar un CREATE OR ALTER al azar en cada commit no es CI/CD. Es suicidio asistido.

Lo que necesitamos es definir una estrategia clara:

¿Vamos a usar enfoque basado en estado (state-based) o en migraciones (migration-based)? ¿Qué herramientas usamos para validar los cambios? ¿Cómo se testea una migración antes de tocar producción? ¿Quién revisa los PRs de cambios en la base de datos? Si nadie puede responder a eso, entonces lo que tenemos no es Agile. Es una bomba de relojería.

¿Sprint o esguince?: ritmo sostenible vs parche continuo

La obsesión por cerrar historias en cada sprint lleva, muchas veces, a decisiones absurdas sobre el modelo de datos. Esquemas pensados “para salir del paso”, duplicación de columnas por no refactorizar a tiempo, cambios acumulativos que nadie documenta… Y claro, luego llegan los sprints de “deuda técnica”, que suenan muy bien pero rara vez se priorizan. Porque claro, refactorizar un varchar(1000) a varchar(255) no tiene glamour. Pero mantenerlo durante años, eso sí que duele.

Un equipo Agile que no entiende la evolución del modelo de datos acabará creando un monstruo. Cada sprint mete una columna. Nadie borra nada. Y cuando miras el esquema tres meses después, parece un museo de decisiones mal tomadas. Peor aún: decisiones que nadie recuerda por qué se tomaron.

Si queremos trabajar bien, hay que introducir prácticas de diseño evolutivo del esquema. Sí, eso también existe. Y sí, también requiere tests, control de versiones y una cultura de refactor continuo. Pero sobre todo requiere que alguien se haga responsable del estado de la base de datos. Porque si todo es de todos, ya sabemos cómo acaba: en el limbo del SELECT *.

Testing y QA Agile en bases de datos: ese gran olvidado

El testing en SQL Server no es opcional, pero tampoco es trivial. Y en metodologías Agile, donde todo debe estar probado y listo para producción cada dos semanas, esto se convierte en un reto constante.

¿Se hacen pruebas de rendimiento cuando se añaden índices? ¿Hay scripts de rollback para cada migración? ¿Los procedimientos almacenados se testean con entradas límite? ¿Tenemos pruebas automatizadas que validen integridad referencial y resultados esperados?

Si la respuesta es “no”, estamos corriendo cada sprint con los cordones desatados. Un paso en falso y nos vamos de cabeza. Agile no significa mover deprisa, significa moverse bien, con ciclos de mejora continua. Y eso implica pruebas, aunque a veces piquen más que el DBCC CHECKDB.

Comunicación y ownership: el verdadero Agile en SQL

Más allá de herramientas y pipelines, lo que más influye en el éxito de una metodología Agile aplicada a SQL Server es la comunicación. Si los DBA, desarrolladores y analistas no están en el mismo canal, cada cambio será una batalla campal.

El modelo Agile bien llevado implica ownership compartido: el esquema de la base de datos no es territorio sagrado del DBA, pero tampoco puede ser tocado por cualquiera que sepa escribir ALTER TABLE. Hay que definir reglas, establecer responsables y fomentar el trabajo conjunto. Si eso no existe, el resto es teatro.

Ah, y no olvidemos lo esencial: si un cambio en la base de datos requiere más esfuerzo que el resto del sprint, no es que el DBA sea lento. Es que la historia está mal dimensionada. O mal entendida. O ambas.

Conclusión

Agile no es una metodología mágica. No convierte scripts en código limpio, ni convierte un modelo relacional en un playground de experimentos. Lo que sí hace, si se aplica con cabeza, es fomentar ciclos de mejora, colaboración y visibilidad. Pero si se aplica mal, acaba siendo solo una excusa para pedir resultados imposibles en tiempos ridículos.

SQL Server puede trabajar perfectamente bajo Agile. Pero no como el resto del código. Necesita prácticas específicas, herramientas adecuadas, y sobre todo, respeto por su complejidad. Porque esto no es un sprint. Y desde luego, si no lo hacemos bien, acabaremos en esguince.

Y no, no hay daily stand-up que arregle una base de datos destrozada por sprints sin control. Solo rollback.

SQL Server

¿Qué es xp_cmdshell y por qué deberías limitar su uso?

¿Qué es xp_cmdshell?

¿Para qué se usa xp_cmdshell legítimamente?

La seguridad, el verdadero problema de xp_cmdshell

¿Se puede usar xp_cmdshell de forma segura?

Alternativas reales y razonables a xp_cmdshell

Auditar, controlar, eliminar

Conclusión

ZSTD en SQL Server 2025: la compresión que por fin tiene sentido

Un poco de contexto en esto de la compresión (pero solo el justo)

Escenario de pruebas: sin cuentos

Backup tradicional con compresión MS_XPRESS

Backup nuevo con compresión ZSTD

¿Y el espacio en disco? ¿Realmente hay más compresión?

Restauraciones

Relación de compresión

Cómo habilitar la compresión ZSTD (cuando funcione bien)

Conclusión

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes