Cloud

Feb

2025

Niveles de compatibilidad de las bases de datos

Hoy me he encontrado con un caso que es más habitual del que me gustaría y quería compartirlo con vosotros y ver qué podemos aprender de él. Estaba revisando el servidor de un cliente que nunca ha tenido un DBA, era un SQL Server 2022 Standard que había montado su equipo de IT. El caso es que, aun siendo un SQL Server 2022, todas las bases de datos estaban en nivel de compatibilidad 100, es decir en el modo de funcionamiento propio de SQL Server 2008. Al preguntar, me han contado que desde su primer SQL Server 2008 su informático siempre había ido aplicando las actualizaciones y subidas de versiones cuando era necesario pero claro, no sabían que había que cambiar nada en las bases de datos.

Este caso que os cuento no es excepcional, y muchos administradores de bases de datos han pasado por situaciones similares. Tener bases de datos en un SQL Server moderno pero con un nivel de compatibilidad antiguo es más común de lo que parece. Pero, ¿qué implica esto realmente? ¿Por qué es importante gestionar correctamente los niveles de compatibilidad? Vamos a profundizar en este tema y en las consideraciones clave antes de realizar cualquier cambio.

¿Qué es el Nivel de Compatibilidad en SQL Server?

El nivel de compatibilidad de una base de datos en SQL Server define qué conjunto de características y comportamientos del motor de base de datos están habilitados para esa base de datos en particular. Microsoft SQL Server introduce constantemente nuevas funcionalidades y mejoras en el motor de consulta con cada versión. Sin embargo, para evitar problemas de compatibilidad con aplicaciones antiguas, permite mantener una base de datos funcionando con un conjunto de reglas de versiones anteriores.

Por ejemplo, una base de datos con nivel de compatibilidad 100 (SQL Server 2008) ejecutada en un SQL Server 2022 seguirá comportándose en muchos aspectos como si estuviera en SQL Server 2008. Esto puede parecer una buena idea para garantizar que las consultas y procedimientos almacenados antiguos sigan funcionando sin problemas, pero también significa renunciar a muchas mejoras de rendimiento y nuevas funcionalidades del motor de base de datos.

¿Por qué es importante el Nivel de Compatibilidad?

El nivel de compatibilidad afecta aspectos fundamentales del comportamiento de SQL Server, incluyendo el optimizador de consultas, nuevas funciones y sintaxis de T-SQL y mejoras en la seguridad y el rendimiento general.

Como sabéis, SQL Server introduce mejoras constantes en el optimizador de consultas en cada nueva versión del producto. Mantener un nivel de compatibilidad antiguo significa que las consultas podrían no beneficiarse de los nuevos algoritmos y estrategias de ejecución de consultas. Además, algunas funciones y tipos de datos más modernos pueden no estar disponibles en niveles de compatibilidad antiguos.

En cuanto a seguridad, Microsoft mejora continuamente la seguridad en SQL Server, y algunas de estas mejoras solo están disponibles en niveles de compatibilidad más recientes. Lo mismo pasa con el rendimiento, características como Batch Mode on Rowstore, Adaptive Query Processing, Memory Grant Feedback, entre muchas otras, solo están habilitadas en niveles de compatibilidad más recientes.

El cambio clave con el Nivel de Compatibilidad 120 (SQL Server 2014)

Uno de los cambios más significativos en la historia de los niveles de compatibilidad de SQL Server ocurrió con SQL Server 2014 (Nivel 120). Microsoft rediseñó por completo el comportamiento del optimizador de consultas con la introducción del nuevo estimador de cardinalidad.

¿Qué es el estimador de cardinalidad y por qué es importante?

El estimador de cardinalidad es el componente del optimizador de consultas que predice cuántas filas se van a procesar en cada paso de una consulta. Estas predicciones, basadas entre otras cosas en las estadísticas, influyen directamente en la selección de planes de ejecución eficientes.

Con SQL Server 2014, Microsoft cambió la forma en que se estiman las filas, lo que en muchos casos mejoró el rendimiento, pero en otros, los menos, generó degradaciones inesperadas. Por eso, al cambiar el nivel de compatibilidad de 110 (SQL Server 2012) a 120 (SQL Server 2014), algunos planes de ejecución cambiaron drásticamente. Si tu base de datos aún se encuentra en un nivel de compatibilidad antiguo (110 o inferior), al actualizar a 120 o superior, es crucial revisar los planes de ejecución antes de aplicar el cambio en producción.

Impacto del Nivel de Compatibilidad 120 en los planes de mantenimiento

Otro cambio relevante con SQL Server 2014 y su nivel de compatibilidad 120 fue cómo se comportaban los planes de mantenimiento. Antes de SQL Server 2014, muchas bases de datos dependían de planes de mantenimiento que ejecutaban reconstrucción y reorganización de índices, estadísticas de actualización y otras tareas rutinarias de mantenimiento. Sin embargo, al actualizar a SQL Server 2014 con nivel de compatibilidad 120, muchos de estos procesos cambiaron significativamente debido a un nuevo comportamiento en la actualización de estadísticas

En versiones anteriores, las estadísticas se actualizaban con una heurística más básica basada en el número de cambios en los índices. A partir de SQL Server 2014, Microsoft introdujo un algoritmo mejorado que ajusta automáticamente la frecuencia de actualización de estadísticas en función de la variabilidad de los datos. Esto significa que algunos planes de mantenimiento antiguos pueden volverse ineficientes, ya que las estadísticas pueden actualizarse con menor frecuencia de lo esperado.

Cambios en la fragmentación de índices

También, antes de SQL Server 2014, los DBA solíamos programar reconstrucción y reorganización de índices en intervalos fijos. Sin embargo, con el nuevo estimador de cardinalidad, algunas consultas que antes se beneficiaban de la reconstrucción de índices ya no requieren mantenimiento tan frecuente, mientras que otras pueden necesitar ajustes más específicos.

Nuevo comportamiento en las esperas de consultas y la concesión de memoria

SQL Server 2014 introdujo Memory Grant Feedback, que ajusta dinámicamente la memoria asignada a las consultas. Este cambio afectó la manera en que los planes de mantenimiento deben ejecutarse en bases de datos de gran tamaño, ya que ahora SQL Server aprende con el tiempo y puede mejorar la asignación de memoria en ejecuciones repetitivas. Sin embargo, si por una actualización de estadísticas o mantenimiento de índices el plan se recompila todos esos cálculos ya no valen.

¿Cómo adaptar los planes de mantenimiento?

Si decides actualizar el nivel de compatibilidad a 120 o superior, es recomendable revisar y adaptar los planes de mantenimiento de la base de datos para evitar ineficiencias. Lo primero que tienes que hacer es revisar la estrategia de actualización de estadísticas.

En lugar de una actualización forzada en cada ciclo, es mejor (generalmente) dejar que SQL Server maneje esto dinámicamente. Por supuesto, siempre evalúa el impacto real en las consultas antes de aplicar actualizaciones manuales con UPDATE STATISTICS.

En cuanto a la reconstrucción de índices podemos utilizar la DMV sys.dm_db_index_physical_stats para analizar si realmente es necesario reconstruir índices. Y, como hemos dicho siempre que hablamos de mantenimiento de índices, ciertas tablas pueden beneficiarse más de una reorganización en lugar de una reconstrucción completa. Tendremos que valorar el nivel de mantenimiento en función de la fragmentación del índice.

En cualquier caso, Query Store puede ayudarnos a detectar cambios drásticos en planes de ejecución antes y después de cambiar el nivel de compatibilidad. Podemos incluso usar la opción de force plan si una consulta se ve afectada negativamente tras el cambio.

Consideraciones antes de cambiar el Nivel de Compatibilidad

A modo resumen de lo que llevamos hasta aquí, antes de modificar el nivel de compatibilidad de una base de datos, debemos hacer una serie de verificaciones y pruebas para asegurarnos de que el cambio no afectará negativamente a la operativa.

Analizar dependencias y compatibilidad con las aplicaciones
Revisar consultas y procedimientos almacenados
Ejecutar pruebas de rendimiento en un entorno de pruebas
Usar Query Store para comparar planes de ejecución
Ajustar planes de mantenimiento según el nuevo comportamiento de SQL Server

Cómo cambiar el Nivel de Compatibilidad

Para cambiar el nivel de compatibilidad de una base de datos en SQL Server, podemos hacerlo desde las propiedades de la base de datos en SSMS en la pestaña “Opciones”. También lo puedes hacer utilizando la siguiente instrucción T-SQL:

ALTER DATABASE NombreBaseDatos SET COMPATIBILITY_LEVEL = 150;

En este ejemplo 150 es para SQL Server 2019, los niveles de compatibilidad son los siguientes:

También podemos verificar el nivel de compatibilidad actual para todas las bases de datos con esta consulta:

SELECT name, compatibility_level FROM sys.databases

Conclusión

El nivel de compatibilidad en SQL Server no es solo una configuración más; afecta directamente al rendimiento, comportamiento del optimizador de consultas y eficiencia de los planes de mantenimiento. Con el cambio introducido en SQL Server 2014, muchas bases de datos experimentaron transformaciones en sus planes de ejecución y rutinas de mantenimiento. Antes de hacer cualquier modificación, es clave realizar pruebas exhaustivas y ajustar estrategias de optimización. Si vamos a actualizar, hagámoslo bien y con un plan claro para minimizar riesgos y aprovechar al máximo las mejoras de SQL Server.

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!

Feb

2025

¿Por qué necesitas usar AUTO_DROP en tus estadísticas?

Hoy vamos a hablar de una de las novedades que nos llegaron con SQL Server 2022 pero, de la que se ha hablado poco y no mucha gente conoce. Estoy hablando de la opción AUTO_DROP de las estadísticas. El objetivo de este artículo es explorar esta característica y entender cómo funciona y por qué es beneficioso para ti.

El reto de las estadísticas manuales

Hubo un tiempo, no tan lejano, donde crear estadísticas manuales era un dolor de cabeza para cualquiera que trabajase con bases de datos SQL Server. Y principalmente era porque las estadísticas manuales eran vinculantes con el esquema. Es decir, si tu o un usuario o aplicación creabais una estadística manual en una tabla, esta estadística iba a bloquear la modificación de la estructura de la tabla. Esto era un problema a la hora de modificar o borrar columnas ya que la sola existencia de la estadística provocaba un error y requería pasos adicionales. Tenías que borrar la o las estadísticas, modificar la tabla y, después, recrear las estadísticas. Por este motivo, con estadísticas manuales, las modificaciones de tabla se convertían en un proceso manual la mayoría de las veces.

Introducción a la opción AUTO_DROP de las estadísticas

Con SQL Server 2022 llegó la opción AUTO_DROP de las estadísticas dispuesta a facilitarnos la vida un poco solucionando, en parte, el problema que mencionaba antes. En resumidas cuentas, cuando habilitamos esta opción para una estadística, esta se crea en un modo que permite que se borre automáticamente cuando se produzca una modificación de la estructura de la tabla.

Características clave de AUTO_DROP

La principal característica de esta funcionalidad es, como hemos visto, que no bloquea la estructura de la tabla. En lugar de eso, la estadística se borra automáticamente cuando es necesario. De esta manera, el comportamiento de las estadísticas manuales se equipara con el de las estadísticas creadas de manera automática por el motor de SQL Server, que también se borran cuando es necesario.

Además, es importante destacar, que esta es una de esas pocas novedades que SQL Server activa por defecto para todas las bases de datos por lo que si quieres mantener el comportamiento como hasta ahora deberás desactivarlo manualmente.

Buenas prácticas y consideraciones

Ten en cuenta que las estadísticas creadas automáticamente por el motor de base de datos siempre usan la opción AUTO_DROP y no se les puede deshabilitar, si intentas cambiarlo te va a dar error. Esta opción solo está disponible para las estadísticas creadas manualmente y, en bases de datos con nivel de compatibilidad 160, estará activada de manera predeterminada, esto aplica para todas las bases de datos creadas en este nivel de compatibilidad pero también para las que hayas migrado de versiones anteriores. Ten en cuenta este comportamiento y desactívalo si lo deseas.

¿Cómo usar la opción AUTO_DROP?

A la hora de crear una estadística manual podemos definir si queremos o no habilitar la opción AUTO DROP. Por ejemplo, este comando crea una estadística con AUTO_DROP:

CREATE STATISTICS [NombreEstadística] ON [Esquema].[Tabla]([Columna1], [Columna2]) WITH AUTO_DROP = ON;

Para crear una estadística SIN AUTO_DROP usaremos este:

CREATE STATISTICS [NombreEstadística] ON [Esquema].[Tabla]([Columna1], [Columna2]) WITH AUTO_DROP = OFF;

Si lo que quieres es cambiar la opción AUTO_DROP en una estadística existente puedes hacerlo también. Esta vez con UPDATE STATISTICS. Por ejemplo este sería el script para activar AUTO_DROP en una estadística que no lo tenga.

UPDATE STATISTICS [Esquema].[Tabla] [NombreEstadística] WITH AUTO_DROP = ON;

Para desactivarlo solo cambia el ON del final por un OFF

Para consultar la configuración AUTO_DROP de nuestras estadísticas podemos hacerlo con la vista sys.stats.

SELECT object_id, [name], auto_drop FROM sys.stats WHERE user_created = 1;

Os comparto también un último script para generar automáticamente estos últimos de cambiar la opción AUTO_DROP para todas las estadísticas de usuario.

SELECT 
  SCHEMA_NAME(t.[schema_id]) AS Esquema,
  t.[name] AS Tabla,
  s.[name] AS NombreEstadistica, 
  CASE WHEN s.auto_drop = 1 THEN 'Activado' ELSE 'DESACTIVADO' END AS [AUTO_DROP],
  'UPDATE STATISTICS '+QUOTENAME(SCHEMA_NAME(t.[schema_id]))+'.'+QUOTENAME(t.[name])+' '+QUOTENAME(s.[name])+' WITH AUTO_DROP = ON;' AS HabilitarAuto_Drop,
  'UPDATE STATISTICS '+QUOTENAME(SCHEMA_NAME(t.[schema_id]))+'.'+QUOTENAME(t.[name])+' '+QUOTENAME(s.[name])+' WITH AUTO_DROP = OFF;' AS DeshabilitarAuto_Drop
FROM sys.stats s
INNER JOIN sys.tables t 
 ON s.object_id = t.object_id
WHERE user_created = 1;

Conclusión

En conclusión, la opción AUTO_DROP de las estadísticas en SQL Server 2022 representa un avance significativo en la gestión de estadísticas manuales. Su implementación permite reducir la fricción en la modificación del esquema de las tablas, eliminando automáticamente las estadísticas cuando ya no son relevantes. Esto no solo simplifica la administración de la base de datos, sino que también evita errores comunes y la necesidad de procesos manuales adicionales.

Si bien esta funcionalidad está activada por defecto en bases de datos con nivel de compatibilidad 160, es importante conocer su impacto y decidir si se desea mantener o desactivar en cada caso. Al final, la correcta gestión de las estadísticas sigue siendo clave para optimizar el rendimiento de las consultas y garantizar un mantenimiento eficiente de nuestras bases de datos en SQL Server.

Feb

2025

Azure Data Studio ha muerto. Larga vida a VS Code.

El pasado 6 de febrero de 2025, Azure Data Studio (ADS) dejaba de recibir soporte y actualizaciones. Aunque se mantendrá operativo hasta el 28 de febrero de 2026, Microsoft ha dejado claro que el futuro del desarrollo SQL pasa por Visual Studio Code (VS Code) con la extensión MSSQL.

Este anuncio marca el fin de una era para quienes han utilizado ADS como su herramienta principal de administración y desarrollo SQL. Sin embargo, lejos de ser una mala noticia, este cambio representa una evolución lógica hacia un entorno más moderno, flexible y potente.

Hoy voy a desgranar qué significa el fin de Azure Data Studio, cómo afecta a los desarrolladores y DBAs, y por qué VS Code es el camino a seguir.

¿Por qué Microsoft ha decidido matar Azure Data Studio?

Azure Data Studio nació como una alternativa ligera y multiplataforma a SQL Server Management Studio (SSMS), con una interfaz moderna, soporte para notebooks y conectividad con Azure. Durante años, fue una herramienta fundamental para administradores de bases de datos y desarrolladores SQL, más bien para estos segundos, que buscaban una solución ágil.

Sin embargo, VS Code ha evolucionado hasta el punto de haber alcanzado en funcionalidad a ADS. Consolidar todo en un único entorno de desarrollo reduce la fragmentación y permite concentrar esfuerzos en una sola plataforma.

Motivos clave detrás de la migración a VS Code

Principalmente, como ya he comentado, VS Code ha mejorado tanto que ya hace todo lo que hacía ADS y más.

Con la extensión MSSQL, VS Code soporta conexiones a SQL Server, Azure SQL Database y Fabric. Pero no solo conectar, obviamente permite ejecutar consultas, visualizar esquemas, exportar resultados y administrar bases de datos con una experiencia optimizada.

Además, en VS Code tenemos a nuestra disposición herramientas avanzadas como Table Designer, Query Execution Plans y scripting.

Menos fragmentación, más velocidad de innovación

Por supuesto, mantener dos herramientas similares implica duplicar esfuerzos. Esto es otro de los principales motivos para consolidar todo en VS Code. De esta manera, Microsoft acelera el desarrollo de nuevas funcionalidades y se eliminan inconsistencias entre ADS y VS Code, asegurando que todos los usuarios tengan acceso a las últimas mejoras.

Integración total con el ecosistema DevOps y CI/CD

A día de hoy VS Code es la herramienta más utilizada por desarrolladores de software. Su ecosistema de extensiones permite integrar bases de datos con herramientas de DevOps, CI/CD y control de versiones. Microsoft está apostando por una experiencia SQL que encaje dentro del mundo cloud-native y automatizado.

¿Qué ofrece VS Code con la extensión MSSQL?

Si aún no has probado VS Code como entorno SQL, te sorprenderá lo completa que es su experiencia con la extensión MSSQL.

Como funciones destacadas de VS Code para SQL Server podemos encontrar el soporte para filtrado, ordenación y exportación a JSON, CSV y Excel. También la administración visual de bases de datos gracias a las herramientas Object Explorer y Table Designer que nos permiten gestionar esquemas sin escribir código. En cuanto a las herramientas de optimización del rendimiento SQL tenemos un visualizador de planes de ejecución de consultas.

Por último, pero importante tenemos el soporte para DevOps y CI/CD especialmente pensado para proyectos de bases de datos SQL para integración con pipelines de despliegue. Esto es totalmente compatible con herramientas de control de versiones y automatización como Git o Azure DevOps.

Y no olvidemos que es extensible y personalizable, ya fuera de lo que es SQL tiene miles de extensiones disponibles en el marketplace de VS Code con soporte para Python, PowerShell, Bash, Kubernetes y más, todo en el mismo entorno.

Cómo migrar de Azure Data Studio a VS Code

Microsoft ha asegurado que la transición de Azure Data Studio a VS Code será sencilla, ya que casi todas las funcionalidades de ADS ya están disponibles en VS Code con la extensión MSSQL.

Para la migración lo primero que debemos hacer, obviamente, es descargar e instalar VS Code. Una vez hecho esto deberemos instalar la extensión MSSQL ya sea desde el Marketplace de Extensiones (buscando «SQL Server (mssql)») o con este comando en la barra de búsqueda de comandos de VS Code:

ext install ms-mssql.mssql

Con todo instalado es el momento de configurar las conexiones a bases de datos Usa la opción «Agregar conexión» para configurar tus servidores SQL Server o Azure SQL.

Puedes trasladar manualmente tus conexiones de ADS sin necesidad de migración de datos.

Por último, si usabas notebooks Jupyter, puedes instalar la extensión de Jupyter en VS Code.

Y si eres administrador de bases de datos o necesitas funcionalidades avanzadas para SQL Server Agent y Schema Compare, existen alternativas dentro de SQL Projects y herramientas de terceros. Esto no es lo ideal pero, es lo mismo que nos pasaba en ADS y el motivo por el que, al menos de momento, yo sigo prefiriendo SSMS para trabajar.

Preguntas frecuentes sobre la transición

A continuación os respondo algunas de las preguntas que he visto sobre el tema de la desaparición de Azure Data Studio

¿Pierdo funcionalidades si dejo de usar Azure Data Studio?

No realmente. VS Code con MSSQL Extension cubre casi todas las funcionalidades de ADS, y en muchos casos, las mejora. Es cierto que no tiene todas las opciones que nos da SSMS pero es que ADS tampoco las tenía.

¿Mis scripts y consultas seguirán funcionando en VS Code?

Sí. No necesitas modificar nada. Lo que cambia es la herramienta de conexión pero los scripts SQL que ejecutabas en ADS funcionan sin problemas en VS Code porque vas a usar los mismos servidores.

¿Qué pasa si no quiero cambiarme de ADS?

¿Eres un rebelde y te gusta ir contracorriente? No pasa nada, puedes seguir usándo ADS hasta febrero de 2026, pero ya no recibirás actualizaciones ni soporte. El cambio es inevitable amigo.

Conclusión

Azure Data Studio nos ha servido bien, pero VS Code representa el futuro del desarrollo SQL. Con una comunidad activa, actualizaciones constantes y una integración más fluida con herramientas modernas, VS Code con MSSQL Extension es la mejor alternativa para administrar bases de datos SQL. Si aún no has probado VS Code, este es el momento perfecto para hacer la transición y aprovechar todas sus ventajas. Yo prometo hacer pronto un video en mi canal de youtube explicando la interfaz.

Para más información, consulta la documentación oficial.

Feb

2025

Azure SQL ahora regala 10 bases de datos. ¡Aprovecha la oferta!

Si llevas tiempo pensando en probar Azure SQL Database, pero crees que el precio es un problema, Microsoft acaba de ponértelo más fácil que nunca. Ahora, cada suscripción de Azure incluye 10 bases de datos serverless gratuitas, con 100,000 vCore-seconds de cómputo, 32 GB de almacenamiento y otros 32 GB para backups cada mes. Y lo mejor: ¡esta oferta no es una prueba temporal, sino para toda la vida de la suscripción!

Vamos, que si querías un entorno de pruebas sin soltar un euro (o dólar), este es tu momento. Ya seas desarrollador, estudiante o simplemente un curioso de las bases de datos, esta oferta tiene algo para ti.

¿Qué significa realmente esta oferta gratuita?

No estamos hablando de un entorno de pruebas capado ni de una demo con limitaciones raras. Estas bases de datos son completas y funcionan como cualquier otra de la capa General Purpose de Azure SQL, con todas sus características y sin trucos ocultos. Puedes configurarlas entre 0.5 y 4 vCores, aprovechar la opción serverless para que se pausen cuando no las uses y, si un día te pasas del límite gratuito, simplemente podrás elegir si pararlas hasta el mes siguiente o pagar por el extra (sin sustos ni bloqueos repentinos).

Microsoft lo ha hecho así para que puedas empezar sin coste alguno y, si en el futuro necesitas más potencia, no tengas que hacer ninguna migración ni cambiar de servicio. Solo escalas y sigues trabajando.

¿Y si me paso del límite de la oferta? ¿Me mandarán una factura sorpresa?

Ya lo he dicho pero vamos a remarcarlo ¡Traaaaaaaanquiiiiiilo! No hay que pagar nada si no quieres.

Si tus bases de datos consumen más de lo que da la oferta gratuita, tienes dos opciones a elegir. Por un lado y por defecto tienes el modo Auto-Pause de manera que, cuando llegas al tope, la base de datos se «congela» hasta que empieza el siguiente ciclo mensual y se reinicia el contador.

Si no puedes permitirte esa parada o necesitas más disponibilidad puedes elegir el modo Pago por Uso. Este modo es el ideal cuando necesitas más potencia. De esta manera, si llegas al límite podrás seguir usando la base de datos sin interrupciones y solo pagarás por el extra que consumas.

Lo interesante es que, si decides seguir adelante pagando, puedes escalar hasta 80 vCores y 4 TB de almacenamiento, lo que te permite pasar de un proyecto pequeño a algo bastante serio sin cambiar de entorno.

¿A quién va dirigida esta oferta?

Realmente esta oferta tiene algo para casi todo el mundo. En mi opinión, Microsoft quiere que Azure SQL llegue a más usuarios, ¿qué empresa no querría más clientes?

Me explico, desarrolladores y startups que necesitan una base de datos para un proyecto o prueba de concepto, ya no tienen que gastar en licencias desde el primer día. Simplemente activan la oferta, empiezan a desarrollar el proyecto y cuando coja envergadura ya escalan a un plan superior.

Pero es que para estudiantes ya sean de alguna escuela o autodidactas también es ideal. Con esta oferta la gente puede aprender SQL en un entorno cloud real, sin depender de versiones locales o configuraciones complicadas. Más aún cuando mucho hardware económico actual no es compatible con la instalación de SQL Server, incluso dentro de la propia Microsoft como los Surface y copilot PC sobre ARM.

En empresas ya consolidadas o en sus equipos IT también tiene cabida. Este plan gratuito es perfecto para crear bases de datos temporales, entornos de pruebas o pequeñas cargas de trabajo sin preocuparse por la factura.

Y en general para cualquier curioso y entusiasta de la tecnología que siempre ha querido trastear con Azure SQL pero no quería pagar ni los menos de 5€ al mes de la Azure SQL DB más básica. Ahora ya no hay excusa.

Cómo empezar (spoiler: es fácil)

Si ya tienes una suscripción en Azure, solo tienes que ir al portal, buscar Azure SQL Database y darle al botón de crear. En el formulario de creación de la base de datos verás un botón que pone «Aplicar oferta gratuita» en la parte superior y con eso ya está. El precio bajará a 0€/mes como por arte de magia. Si no tienes cuenta, puedes crear una nueva en un par de minutos y empezar a usarlo, es realmente sencillo.

Además, lo mejor es que está disponible en todas las regiones de Azure, así que da igual dónde te encuentres, puedes empezar hoy mismo. Cuando termines de leer este artículo, claro.

Conclusión

No todos los días una empresa como Microsoft decide regalar bases de datos en la nube sin limitaciones raras ni letra pequeña. Esto no es una prueba por tres meses ni una oferta exclusiva para startups, sino una forma real de usar Azure SQL sin coste y, si en algún momento lo necesitas, escalar sin migraciones ni dolores de cabeza.

Si alguna vez quisiste probar Azure SQL, este es el mejor momento. ¡Así que deja de pensarlo y ponte manos a la obra!

Feb

2025

El extraño error de conversión y su solución

Hoy vamos con un artículo distinto, nos vamos a centrar en un caso práctico que me ha pasado hoy en el trabajo y que me ha parecido lo suficientemente curioso como para traerlo aquí y compartirlo con todos vosotros. La idea es que si alguna vez encontráis este error o alguno parecido sepáis como actuar rápido y sin volveros locos.

Disclaimer 1: Todos los datos que veis son una reproducción de lo que ha pasado, no voy a mostrar ni estructuras ni datos reales.

Disclaimer 2: Vaya por delante que estamos hablando, no solo de un sistema totalmente Legacy, sino de un patio de recreo para todas las malas prácticas habidas y por haber en el mundo de los datos, documentadas y por descubrir. Vosotros me entendéis, ¿verdad? No sé como más decir que esto hay que borrarlo, os prometo que he recurrido a todos los métodos posibles antes de incurrir en ilícito penal. Porque hay veces que la tortura tendría que estar aceptada, ya veréis cuando os cuente…

El misterioso error

Como os digo estaba yo en un día tranquilo, de esos que aprovechas para poner la documentación al día, cuando los lloros de un usuario han perturbado mi paz. Un error salvaje había aparecido:

Hasta aquí todo normal, un error de conversión normal y corriente. “Deja de hacer esa conversión. ¡ Qué estás tratando de convertir a fecha y hora un texto que no es una fecha, ANIMAL !”

Pero no, iba a ser más complicado, no había ninguna conversión aparente. Era un select * de la tabla sin más.

El valor de la experiencia

Uno que ya es perro viejo ha ido directamente a mirar la definición de la tabla, ya sabes, más sabe el diablo por viejo que por diablo y, aquí, la experiencia es un grado. No es la primera vez que veo una cosa de estas. Y lo que he visto os sorprenderá.

Bingo. Tenemos una columna calculada que saca el dato de un fichero de texto. Seguro que uno de los campos del JSON tiene un valor en la fecha que realmente no es una fecha o, si lo es, no es de un rango válido. Pero, tenemos en la tabla más de 50 millones de registros, no es plan de ponerse a mirar todos los JSON.

Investigación y solución del error

No hay problema que frene al DBA. Localizar el error es sencillo si sabes como. Basta con usar la misma expresión de CONVERT que tenía la columna calculada pero con TRY_CONVERT que, como expliqué en este vídeo, hace lo mismo que CONVERT pero en caso de error devuelve nulo. Esto en un filtro del where y filtrando por resultados nulos nos va a señalar directamente al culpable, como cuando pillan al malo con restos de pólvora en las manos en nuestra serie favorita de policías americanos.

Como veis un 0 en la fecha era el causante de este expediente X, en mi caso real (no la demo que veis en las imágenes) no era uno sino 258 registros pero vamos, la solución es la misma. UPDATE de esas fechas y a funcionar.

Prevención de errores

Una vez arreglado el problema es momento de analizar las causas raíz y ver cómo evitar esto en un futuro. En este caso podríamos resumirlo en hacer las cosas bien pero oye, cuando a uno le están pagando por ello, hay que currarse las respuestas un poco más.

Veamos pues qué pasa:

Usar datos semiestructurados en la base de datos no es una buena idea por rendimiento. Pero es que tampoco tiene validaciones, como hemos podido comprobar. Con una columna de fecha para introducir el dato este error no habría pasado. Directamente este registro incorrecto no se habría escrito en la base de datos.
SQL Server no está preparado para trabajar con JSON, por eso lo del tipo de datos nvarchar(max) en la columna. Mientras que para XML si tenemos un tipo de datos específico para JSON no será hasta SQL Server 2025 que lo veamos (podemos probarlo en preview en Azure SQL Databases y Azure Managed Instance). Este futuro tipo de datos JSON nos permitirá añadir estos controles de los que hablábamos en el punto anterior.
Usar una función CONVERT en una columna calculada es una mala práctica pues, en caso de fallo de los datos, nos devuelve error. Para estos casos, siempre que sea posible es mejor usar TRY_CONVERT. Realmente aquí hay discrepancias de opiniones, y dependerá de vuestro caso. Depende a que deis prioridad, si a tener el resto de datos sin error y el registro incorrecto como nulo o si por el contrario preferís que salte el error para detectarlo y corregirlo.

Conclusión

Los errores de conversión como este pueden ser una pesadilla, pero la realidad es que suelen ser más culpa de un diseño regulero que de un usuario despistado. Aquí la clave es sencilla: si metemos datos como si fueran churros, que no nos sorprenda si luego nos encontramos un «churro» en los resultados. Por otro lado, usar TRY_CONVERT en lugar de CONVERT nos habría ahorrado el susto, pero el problema de fondo sigue siendo el mismo: SQL Server y JSON no son precisamente mejores amigos.

Aquí estamos, esperando que el tipo de datos JSON nativo llegue en SQL Server 2025. Hasta entonces, toca ser cuidadosos, validar lo que metemos en la base de datos y asumir que, si confiamos ciegamente en los datos, tarde o temprano nos van a dar un disgusto.

Así que ya sabéis: menos improvisación, más validación y, sobre todo, menos sustos en producción.

Feb

2025

Azure SQL Database: Comprendiendo las opciones de compra DTU y vCore

Azure SQL Database es la solución de acceso a SQL en Azure. Y, sin embargo, es una plataforma versátil y escalable que se adapta a distintas necesidades empresariales gracias a sus modelos de compra flexibles. Elegir entre DTU (Database Transaction Unit) y vCore (Virtual Core) puede parecer complicado, sobre todo al principio. Hay que entender que cada modelo está diseñado para escenarios específicos, lo que permite optimizar el rendimiento y los costes según los requerimientos de nuestro negocio.

En este artículo introduciremos ambos modelos, sus niveles de servicio, ventajas y desventajas, precios en España y los casos en los que es más recomendable optar por cada opción.

Introducción a los modelos de compra en Azure SQL Database

Como decía en la introducción, Microsoft ofrece dos principales modelos de compra para Azure SQL Database DTU y vCore.

El modelo de compra por DTU está diseñado para simplificar la elección de recursos al proporcionar paquetes preconfigurados que incluyen CPU, memoria y E/S.

El modelo basado en vCore (Virtual Core), por contra, nos da mayor flexibilidad al permitir configurar de forma independiente los recursos de proceso y almacenamiento, adaptándose mejor a las necesidades específicas de cada carga de trabajo. Sin embargo, por esto mismo, puede ser más complejo de configurar

Además, para hacer las cosas más flexibles (ejem complejas), ambos modelos están disponibles con distintos niveles de servicio que determinan las capacidades de rendimiento, alta disponibilidad y escalabilidad.

Azure SQL Database basado en DTU

El modelo de compra por DTU combina los recursos computacionales, la memoria y las operaciones de entrada/salida en un único paquete. Esto lo convierte en una opción intuitiva y fácil de implementar para quienes buscan simplicidad en la gestión de sus bases de datos.

Niveles de servicio en DTU

Este modelo de compra tiene varios niveles que vamos a poder seleccionar.

Un primer nivel básico, ideal para cargas de trabajo pequeñas con baja concurrencia. Nos ofrece hasta 2 GB de almacenamiento por lo que está diseñado, en principio, para aplicaciones de prueba o proyectos muy pequeños.

A continuación encontraremos un nivel estándar pensado para aplicaciones empresariales con requisitos de rendimiento moderado. Este nivel ya nos permite hasta 1 TB de almacenamiento por lo que es ideal para bases de datos transaccionales estándar.

Por último, encontramos un nivel premium más diseñado para cargas críticas con alta concurrencia y baja latencia. Este nivel nos ofrece además almacenamiento local SSD para un rendimiento superior y es escalable hasta 4 TB de almacenamiento.

Ventajas del modelo DTU

Si hay una ventaja a destacar de este modelo de compra por DTU es su simplicidad. Al agrupar los recursos en paquetes, elimina la necesidad de calcular CPU o memoria de manera independiente. Todo esto sin renunciar a la escalabilidad vertical, podremos aumentar o reducir el nivel de servicio según las necesidades prácticamente en tiempo real.

Desventajas del modelo DTU

Toda ventaja tiene una contraparte, y en este caso, la simplicidad del modelo DTU implica una excesiva rigidez en la configuración. Este modelo con una configuración tan simple no nos permite ajustar individualmente los recursos de CPU o memoria. Además, es muy susceptible a costes potencialmente elevados. Si nuestras necesidades de recursos no coinciden perfectamente con un paquete, deberemos ir a un nivel superior y pagar por recursos no utilizados. Porque no vamos a contratar algo infradimensionado, ¿verdad?

Azure SQL Database basado en vCore

El modelo vCore (Virtual Core), al contrario que el DTU, nos proporciona un control más granular sobre los recursos, lo que resulta ideal cuando trabajamos con aplicaciones con requisitos específicos o cargas de trabajo variables. Es una opción que se asemeja más al enfoque tradicional de bases de datos locales, facilitando la migración de estas a la nube.

Tipos de implementación en vCore

A la hora de contratar una Azure SQL Database basada en vCore debemos elegir uno de los dos tipos de implementación que tenemos disponibles, el aprovisionado y el sin servidor.

En el tipo aprovisionado los recursos se asignan permanentemente y están disponibles en todo momento.Esto es adecuado para cargas de trabajo constantes o predecibles. Esto no quiere decir que no se pueda escalar, pero no es un proceso dinámico.

Por otro lado, tenemos el tipo de implementación sin servidor (Serverless). En este nivel, los recursos se escalan automáticamente según la demanda, reduciendo costes durante los períodos de inactividad. Este tipo es ideal para cargas de trabajo esporádicas o impredecibles pero cuidado, una consulta mal optimizada puede arruinarnos.

Niveles de servicio en vCore

Igual que en modelo basado en DTU, en este modelo también tenemos niveles de servicio que marcarán el rendimiento y las limitaciones de escalado de nuestra base de datos

El primer nivel de acceso a este modelo es el de uso general (General Purpose). Este nivel, basado en almacenamiento remoto, proporciona un equilibrio entre coste y rendimiento ideal. Es el más recomendado para la mayoría de las aplicaciones empresariales.

Si tenemos unas necesidades mayores podemos optar por el nivel crítico (Business Critical). Este segundo nivel utiliza almacenamiento SSD local, lo que nos ofrece una menor latencia y alta velocidad. Está especialmente diseñado para aplicaciones críticas que requieren alta disponibilidad.

Por último, el nivel hiperescala (Hyperscale) nos permite almacenar y gestionar grandes volúmenes de datos de más de 100 TB. Además es escalable dinámicamente, lo que lo hace ideal para aplicaciones con crecimiento masivo de datos.

Ventajas del modelo vCore

Como este modelo de contratación es más configurable lo primero que debemos destacar como ventaja es su mayor flexibilidad. Ya hemos visto que nos permite personalizar los recursos de CPU, memoria y almacenamiento según nuestras necesidades. Por otro lado, la transparencia en costes también es fundamental, al final pagamos solo por lo que utilizamos.Por último, gracias a su similitud con configuraciones tradicionales tiene una mayor compatibilidad y nos facilita la migración de cargas de trabajo locales.

Desventajas del modelo vCore

Como nada es perfecto, también nos vamos a encontrar con una desventaja y no es otra que la mayor complejidad que ya hemos comentado antes. Este modelo requiere más conocimiento técnico para optimizar la configuración.

Además debemos tener mucho cuidado con los costes en Serverless. Aunque sea el tipo de implementación más eficiente para cargas variables, puede ser más costoso si las pausas no se configuran adecuadamente o si no controlamos las consultas pesadas y costosas.Requiere de mucho trabajo de optimización de desarrollo para no llevarnos sustos en las facturas.

Comparativa de costes (Precios en España)

Como todo en Azure, y en casi todo en esta vida, los precios dependen de la región. En este caso además entran en juego variables como el modelo de compra y el nivel de servicio elegido. A continuación, os pongo unas estimaciones aproximadas con los precios en España al momento de escribir este artículo:

DTU Basic (5 DTU): Desde 4,70 € al mes.
DTU Standard (10 DTU): Desde 14,12 € al mes.
DTU Premium (125 DTU): Desde 437,75 € al mes.
vCore General Purpose (2 vCore): Desde 234,55 € al mes*.
vCore Business Critical (2 vCore): Desde 469,10 € al mes*.
vCore Business Critical (2 vCore): Desde 281,46 € al mes*.
vCore Serverless: Desde 0,055 €/hora*.

* A los modelos de compra vCore hay que sumarle los costes de almacenamiento que son de 0,131 € por GB al mes.

Ten en cuenta que existen descuentos por reservas de uno o tres años y, en algunos casos, te puedes acoger a la Ventaja híbrida de Azure o a los Derechos de conmutación por error. Por último, como sobrecostes, tienes que contar con replicaciones y opciones de redundancia o retención a largo plazo de los backups.

Si necesitas precios más específicos, te recomiendo usar la calculadora de precios de Azure.

¿Cuándo usar Azure SQL Database DTU o vCore?

Ahora que ya hemos visto toda la parte más de descripción del “comercial” llega el momento de mojarme, si habéis venido a leer esto es porque queréis saber mi opinión. En este caso, y como estarás imaginando, no hay una respuesta universal.

Yo personalmente recomiendo elegir DTU si la simplicidad es prioritaria para ti y no requieres un control granular de los recursos. También es aconsejable para las aplicaciones tienen cargas de trabajo predecibles y de baja a mediana intensidad o si prefieres pagos fijos y predecibles.

Por el contrario, te recomendaría elegir vCore si necesitas esa flexibilidad extra para configurar CPU, memoria y almacenamiento de forma independiente siempre y cuando seas o tengas a alguien especialista para esta administración más especializada. Sobre todo, si gestionas aplicaciones críticas con requisitos específicos de rendimiento y alta disponibilidad o tu carga de trabajo es variable y prefieres la opción sin servidor para ahorrar costes en periodos de inactividad.

Conclusión

Tanto DTU como vCore son modelos viables para Azure SQL Database, cada uno con sus ventajas y limitaciones. La elección depende de las necesidades específicas de tu aplicación, el nivel de control requerido y el presupuesto disponible. Mientras DTU destaca por su simplicidad, vCore se adapta mejor a configuraciones avanzadas y escenarios críticos.

Os recomiendo evaluar las características de cada modelo y utilizar herramientas como la calculadora de precios de Azure para tomar decisiones informadas. Azure SQL Database ofrece una plataforma potente y flexible que, bien configurada, puede convertirse en un aliado clave para el crecimiento de cualquier negocio.

Ene

2025

Compresión en índices columnares: COLUMNSTORE_ARCHIVE

Llevamos un par de artículos ya hablando sobre compresión de datos y ya hemos visto cómo esta afecta tanto a las tablas como a los índices tanto en SQL Server como en Azure SQL. Sin embargo, hay un tipo de índice que no se ve afectado por la compresión y son los índices columnares. Lo cierto es que este tipo de índices ya tienen un nivel altísimo de compresión de datos al ser columnares pero, aún podemos comprimirlos más si es lo que queremos. Estoy hablando de una opción no tan conocida y usada que es el COLUMNSTORE_ARCHIVE.

Índices Columnares y su naturaleza comprimida

Como he comentado ya en la introducción, la propia naturaleza columnar de los índices columnstore ya de por si facilita la compresión. En concreto, por defecto y por definición se aplican técnicas de compresión avanzadas. A diferencia de los índices tradicionales basados en filas, los índices Columnstore almacenan los datos en formato columnar, lo que permite aplicar técnicas de compresión más avanzadas.

Cuando creamos un índice Columnstore, SQL Server automáticamente aplica compresión de diccionario, codificación por lotes y compresión de bits, lo que reduce significativamente el tamaño del almacenamiento y mejora la eficiencia en la lectura de datos.

La compresión de diccionario reduce el tamaño del almacenamiento eliminando valores repetitivos dentro de cada segmento de datos. Por su parte, la codificación por lotes (Run-Length Encoding) optimiza la compresión al almacenar secuencias de valores repetidos como una sola entrada. Por último, la compresión de bits (Bit-Packing) reduce el tamaño del almacenamiento al optimizar el número de bits utilizados para representar los valores almacenados.

¿Qué es Columnstore_Archive?

El índice Columnstore_Archive es una extensión del índice Columnstore comprimido estándar, diseñado para proporcionar una comprensión aún mayor aplicando algoritmos de compresión adicionales. Mientras que un índice Columnstore ya aplica técnicas avanzadas de reducción de datos como codificación de diccionario, codificación por lotes y compresión de bits, Columnstore_Archive utiliza una compresión más agresiva basada en el algoritmo Xpress Compression Algorithm (XCA).

Diferencias clave entre Columnstore y Columnstore_Archive

Característica	Índice Columnstore Normal	Columnstore Archive
Compresión aplicada	Codificación de diccionario, run-length, bit-packing	Todo lo anterior + compresión LZ77+Huffman
Impacto en almacenamiento	Reducción del 50-70%	Reducción del 70-90%
Impacto en CPU	Bajo	Alto (más procesamiento en consultas)
Velocidad de lectura	Alta	Reducida por el proceso de descompresión
Casos de uso ideales	Datos transaccionales y de consulta frecuente	Datos históricos, auditoría y repositorios de solo lectura

Cómo funciona la compresión en Columnstore_Archive

Como he comentado, el modo Columnstore_Archive añade una capa extra de compresión sobre los segmentos Columnstore existentes. Esto se logra mediante una combinación de técnicas de compresión basadas en LZ77 y Huffman, utilizadas en el algoritmo Xpress Compression Algorithm (XCA).

Fases del proceso de compresión de Columstore_Archive

Compresión LZ77: Reemplaza secuencias repetidas de bytes con referencias a posiciones anteriores en el flujo de datos. Esto reduce el tamaño al eliminar redundancias en los segmentos Columnstore.
Codificación Huffman: Utiliza un esquema de codificación basado en la frecuencia de los datos para minimizar aún más el tamaño. Los valores más comunes se almacenan con menos bits, mejorando la eficiencia de almacenamiento.

Cómo maneja SQL Server los datos comprimidos en Columstore_Archive

Cuando se escribe un índice Columnstore_Archive, SQL Server aplica la compresión LZ77 + Huffman a los segmentos Columnstore ya existentes. Al leer datos de un índice Columnstore Archive, SQL Server debe descomprimir estos segmentos antes de ejecutar la consulta, lo que implica un uso de CPU significativamente mayor.

Implementar Columstore_Archive

Si queremos habilitar Columnstore_Archive en una tabla o índice usaremos el comando ALTER TABLE o ALTER INDEX de la siguiente manera:

1. Habilitar Columnstore_Archive en una partición

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = 1 WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);

2. Habilitar Columnstore_Archive en todas las particiones

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);

3. Habilitar Columnstore en todas las particiones y Columnstore_Archive en alguna

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE ON PARTITIONS (4, 5));

3b. Otra forma de habilitar Columnstore en todas las particiones y Columnstore_Archive en alguna:

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE ON PARTITIONS (4, 5),
    DATA COMPRESSION = COLUMNSTORE_ARCHIVE ON PARTITIONS (1, 2, 3));

Impacto en el rendimiento de Columnstore_Archive

Columnstore_Archive permite una reducción extrema del tamaño de almacenamiento, lo que lo hace ideal para entornos donde el espacio en disco o las copias de seguridad representan un coste significativo. Al disminuir el tamaño de los datos almacenados, se reducen los costes operativos y se optimiza el uso del almacenamiento, especialmente en bases de datos alojadas en la nube.

Sin embargo, esta ventaja viene acompañada de un mayor consumo de CPU en las consultas, ya que los datos deben ser descomprimidos en tiempo de ejecución. En escenarios donde las consultas analíticas son frecuentes y de gran volumen, este aumento en el uso de CPU puede impactar el rendimiento general del sistema, por lo que es fundamental evaluar su aplicación caso por caso.

Casos de uso ideales para Columnstore_Archive

El uso de Columnstore_Archive está especialmente indicado en escenarios donde los datos almacenados son mayormente de solo lectura o tienen un acceso esporádico. Tablas con registros históricos, auditorías o grandes volúmenes de datos que rara vez se consultan pueden beneficiarse enormemente de la reducción de almacenamiento sin que el impacto en la CPU sea un problema. En entornos de Data Warehouse donde la retención de datos es fundamental, Columnstore_Archive puede ser clave para reducir los costes de almacenamiento sin comprometer la integridad de los datos.

También es una opción interesante en Azure SQL Managed Instance y otras bases de datos en la nube, donde los costes de almacenamiento suelen ser elevados. Reducir el tamaño de la base de datos mediante Columnstore_Archive puede generar ahorros significativos, especialmente en cargas de trabajo que dependen de replicaciones geográficas y copias de seguridad, donde el tamaño de los datos afecta directamente los costes de operación.

Buenas prácticas con Columnstore_Archive

Para aprovechar al máximo Columnstore_Archive, es fundamental evaluar cuidadosamente qué tablas o índices pueden beneficiarse de esta compresión. No es recomendable aplicarlo en datos de acceso frecuente, ya que el proceso de descompresión puede generar una sobrecarga en la CPU que afecte el rendimiento de las consultas. Monitorizar el impacto en el rendimiento con herramientas como Query Store y ejecutar pruebas antes de aplicar la compresión en entornos de producción son pasos esenciales para garantizar que los beneficios en almacenamiento no se vean opacados por problemas de latencia.

Conclusión

Columnstore_Archive es una solución avanzada para la compresión extrema de datos en SQL Server, útil en escenarios donde el almacenamiento es la principal preocupación. Sin embargo, su mayor consumo de CPU puede ser un factor limitante en bases de datos con consultas frecuentes. Si el objetivo es maximizar la eficiencia del almacenamiento sin comprometer demasiado el rendimiento, Columnstore Archive es una opción poderosa que debe aplicarse estratégicamente en los casos adecuados. Una planificación cuidadosa y una evaluación continua del impacto en rendimiento permitirán sacar el máximo provecho de esta tecnología sin afectar la operativa de la base de datos.

Cloud

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes