cloud

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!

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

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.

Ene

2025

Compresión en Azure SQL Managed Instance

Azure SQL Managed Instance (MI) es una plataforma para la gestión de bases de datos en la nube con un equilibrio perfecto entre la administración manual y delegada en el proveedor, pero es esencial comprender sus características y limitaciones para optimizar su rendimiento. Hoy vamos a hablar de la compresión de datos, de la que ya hablamos detenidamente en otro artículo, como estrategia para mitigar limitaciones relacionadas con los recursos de IO, RAM y CPU. En este artículo, exploraremos cómo la compresión de datos puede ayudar a superar estas limitaciones, proporcionando datos objetivos sobre las especificaciones de Azure MI y los precios (en la región de España Central a modo de ejemplo).

Características y limitaciones de Azure SQL Managed Instance

Lo primero que tenemos que tener claro es el terreno de juego en el que estamos, la nube es teóricamente escalable sin límite, sin embargo, tanto los proveedores como, sobre todo, nuestro bolsillo va a ser el principal limitante. Veamos qué es lo que nos ofrece Azure para el caso de las Managed Instance.

Niveles de servicio y recursos asignados:

Azure MI ofrece principalmente dos niveles de servicio el de uso general y el crítico. Además, dentro de estos niveles de servicio vamos a poder elegir tres tipos de hardware diferente. Parece un poco lioso, y realmente lo es, así que vamos a tratar de hacerlo fácil.

Lo primero que tenemos que conocer son los niveles de servicio que son:

De uso general (General Purpose): Diseñado para cargas de trabajo empresariales comunes con requisitos de rendimiento moderados y alta disponibilidad.
Crítico para la empresa (Business Critical): Orientado a aplicaciones de misión crítica que requieren alta velocidad de transacciones y baja latencia.

Estos niveles de servicio van a marcar los límites de recursos que podemos asignar a nuestra instancia, pero además de estos tenemos que tener en cuenta el tipo de hardware. Por ejemplo en el nivel de uso general el límite de CPUs que podemos asignar es de 80 cores para el hardware estándar y el serie premium pero solo hasta 64 cores en el hardware optimizado para memoria. Es el nivel crítico para la empresa el hardware estándar tendrá un máximo de 80 cores mientras que el hardware premium y el optimizado para memoria podrá tener hasta 128.

Compresión para salvar los límites de RAM para Azure MI

Una de las cosas curiosas de Azure SQL MI es que la asignación de recursos de memoria RAM no es seleccionable y depende directamente de la cantidad de núcleos virtuales que tengamos.

Hardware de la serie estándar: 5,1 GB de RAM por vCore con un máximo de 480 Gb. Por ejemplo, 16 vCore = 81,6 GB de RAM.
Hardware de la serie Premium: 7 GB de RAM por vCore con un máximo de 560 Gb. Por ejemplo, 16 vCore = 112 GB de RAM.
Hardware optimizado para memoria: 13,6 GB de RAM por vCore con un máximo de 870,4 Gb. Por ejemplo, 16 vCore=217 GB de RAM.

Como podéis ver, la cantidad máxima de RAM es muy limitada y más cuando no nos dejamos el presupuesto de toda la empresa en núcleos de Azure MI. Por esta razón es fundamental habilitar la compresión en todas las tablas e índices de nuestras bases de datos. Cuantos más datos podamos cachear mejor, recordad que para que SQL tenga un rendimiento decente tiene que ser capaz de tener en memoria la información a la que se accede frecuentemente además de espacio suficiente para cachear planes de ejecución y demás operaciones que se hacen en memoria.

Almacenamiento en Azure MI

Ahora vamos con una de las cosas que menos me gustan de este modelo de dimensionamiento que tiene Azure MI y es que la capacidad de almacenamiento está limitada por la cantidad de núcleos adquirida. De esta manera, en el nivel de uso general con menos de 8 núcleos no puedes tener más de 2 Tb de datos, con menos de 16 núcleos no puedes tener más de 8 Tb de datos y para llegar hasta el máximo de 16 Tb de datos vas a necesitar 16 núcleos o más. Veamos esto en precios con el hardware estándar para que nos duela menos al ver los costes.

Propósito general:

¿Necesitas menos de 2 TB? Puedes dimensionar 4 núcleos, 1.013,99 € mensuales.
¿Necesitas más de 2 TB? Necesitas mínimo de 8 núcleos, 2.569,88 € mensuales.
¿Necesitas más de 8 TB? Necesitas mínimo de 16 núcleos, 5.143,85 € mensuales.
¿Necesitas más de 16 TB? Lo siento, no puedes tener esa cantidad. (Puedes tener más núcleos pagando más, pero esta lista se basa en los tamaños de disco).

Veamos también cómo va el almacenamiento en el nivel crítico para la empresa (esta vez en hardware premium que es más flexible):

¿Necesitas menos de 1 TB? Puedes dimensionar 4 núcleos virtuales, 2.614,23 € mensuales.
¿Necesitas más de 1 TB? Mínimo de 8 núcleos, 5.237,48 € mensuales.
¿Necesitas más de 2 TB? Mínimo de 16 núcleos, 10.483,97 € mensuales.
¿Necesitas más de 4 TB? Mínimo de 24 núcleos, 15.584,32 € mensuales.
¿Necesitas más de 5,5 TB? En España no se puede.

Os dejo ahora una imagen extraída de la documentación oficial sobre las limitaciones de espacio. Para el cálculo de precios podéis usar la calculadora oficial.

Velocidad de los discos

Si todo esto que hemos visto no es un problema para vosotros esperad porque ahora viene lo realmente “problemático” en Azure MI. La velocidad de estos discos, medida en IOPS (E/S por segundo), es realmente baja y, aunque va aumentando con el tamaño de los archivos, no llega a ser comparable a sistemas tradicionales On-Prem. Además de que escalar los ficheros nos va a implicar necesidades extra de tamaño y por tanto de cores y, si lo habéis adivinado, de más dinero todos los meses. Veamos esta otra imagen de la misma documentación que comentábamos antes:

Ahora os voy a dejar otra imagen de Kingston sobre las velocidades de sus discos actuales

Como veis, en el mejor de los casos, un archivo de Azure MI de más de 4 Tb tendría una velocidad de 250 Mib/s (Mebibits por segundo) o lo que es lo mismo 32,7 MB/s (Megabytes por segundo). Un SSD M2 NVME actual de cuatro canales nos está dando 8000.

Recuerda que para tener 4Tb (32,7 MB/s) en una instancia de nivel crítico para la empresa estamos hablando de más de 15.000 € al mes, eso sin contar con dimensionar también el fichero de log que, en este nivel de servicio y en España, ni podríamos llevarlo a este tamaño. En el nivel propósito general si podemos pero, estamos hablando de 5.100 € al mes para tener 8 Tb (4 para datos y 4 para log).

Nada más que decir.

Conclusión: Compresión para reducir las lecturas

Lo que os quería hacer ver con todo este texto que os he puesto hasta ahora es que en Azure MI las reglas del juego cambian y reducir las lecturas en disco y maximizar el tiempo que los datos permanecen en caché es clave para el rendimiento. Por este motivo necesitarás una buena política de indexación, comprimir los datos y, si es posible, eliminar todos los datos que ya no sean necesarios.

Ene

2025

Un día en la vida de un DBA: Consultas, Caos y Dudosa Capacidad Técnica (Artículo de HUMOR)

Como DBA de SQL Server, mi día es una mezcla de comedia, drama y suspense, con algunos toques de terror. Aquí os presento cómo transcurrió un día cualquiera en mi vida, repleto de personajes inolvidables, cada uno con su consulta particular y su manera única de contribuir al colapso del servidor. Abrid vuestra mente… y vuestro SQL Server Management Studio.

8:00 AM: Paco “El SELECTor” y la Consulta Infinita

Nada más abrir mi sesión, mi querido compañero Paco, el SELECTor (porque selecciona todo sin filtro), aparece con su ya clásica sonrisa de inocencia. Paco es de los que todavía piensan que SQL Server es algo mágico y que “si no devuelves todas las columnas, seguro te dejas algo importante”.

Me encuentro con su obra maestra, digna de un Anti Premio a la peor consulta del año:

SELECT *
FROM Sales.SalesOrderDetail SOD
JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE YEAR(SOD.ModifiedDate) = 2024;

-“¡No entiendo por qué tarda tanto! ¡Si son solo los pedidos del año!”, exclama Paco, mientras agita su taza de café de “No es magia, soy desarrollador”.

Le explico con calma (una vez más) que cada vez que usa SELECT * en producción muere un gatito y que filtrar con funciones como YEAR() no permite que SQL Server use los índices. Con cara de «eso me lo enseñaron en un curso de YouTube», Paco se compromete a mejorar. Mientras tanto, optimizo la consulta:

Optimización: índice + eliminación de funciones

CREATE INDEX IX_SalesOrderDetail_ModifiedDate 
ON Sales.SalesOrderDetail(ModifiedDate)
WITH (ONLINE=ON, FILLFACTOR=100);

SELECT SOD.SalesOrderID, P.Name, SOD.OrderQty
FROM Sales.SalesOrderDetail SOD
JOIN Production.Product P ON SOD.ProductID = P.ProductID
WHERE SOD.ModifiedDate >= '2024-01-01' AND SOD.ModifiedDate < '2025-01-01';

Resultado: Consulta en segundos. Paco asiente con admiración y anota algo en su libreta, probablemente «Pedir más memoria al DBA».

10:00 AM: Toñi “SinWHERE” y el Script Nuclear

Toñi es de esas desarrolladoras que tienen una relación tóxica con el entorno de producción. Tiene un lema: «Si funciona en mi local, funciona en producción». Y hoy, decidió demostrarlo.

Recibo una alerta: «La tabla Employee está vacía». Con el corazón encogido, abro los logs y ahí está el script más temido:

DELETE FROM HumanResources.Employee;

-“¡Uy! Me olvidé el WHERE. Pero no pasa nada, para eso están los backups, ¿no?”, dice Toñi con una sonrisa que desearía no ver nunca más.

Intento explicarle que “no pasa nada” es lo que dice un soldado cuando pisa una mina. Mientras recupero los datos, aplico medidas preventivas:

ALTER ROLE db_datawiter DROP MEMBER [Toñi.SinWHERE]

ATPC. No me fío ni un pelo.

1:00 PM: Manolo “El Shuffle” y el Caos Aleatorio

Manolo, alias “El Shuffle”, es el encargado de los informes y estadísticas. Es fan del “orden aleatorio” porque, según él, “las listas aburren a la gente”. Y claro, cuando quiere algo “aleatorio”, lanza lo siguiente:

SELECT TOP 10 PERCENT *
FROM Sales.Customer
ORDER BY NEWID();

-“Es que así queda guay, aleatorio, como mi lista de Spotify”, argumenta Manolo mientras hace girar su silla de oficina cual plato de mesa de mezclas de DJ.

Le explico (otra vez) que NEWID() obliga a SQL Server a generar GUIDs para todas las filas de la tabla y luego ordenarlos. Todas estas operaciones se hacen en memoria y con su maravillosa tabla de 200 millones de registros eso no es una buena idea. Así que le doy una alternativa más eficiente para obtener una muestra aleatoria:

SELECT *
FROM Sales.Customer
TABLESAMPLE (10 PERCENT);

¡Magia! “¿Ves? Es que tú lo complicas todo”, dice con su típica confianza de «yo lo leí en Stack Overflow».

4:00 PM: Javi “El SinÍndices” y la Carga Masiva

Cuando el servidor ya está medio recuperado, aparece Javi, “El SinÍndices”. Su teoría es que los índices ralentizan la carga de datos (y no le falta razón… a medias). Así que en su infinita sabiduría, ha borrado todos los índices de la tabla Invoices para cargar más rápido.

– “¡La carga ha ido como un rayo!”, dice orgulloso.

– “¿Y las consultas que dependen de esa tabla? ¿Les has preguntado cómo van?”, respondo yo con una mirada de fuego.

Para evitar futuros desastres, le tatuo en el antebrazo que si vuelve a borrar índices no respetaré los derechos humanos y recurriré a la tortura en nuestra próxima interacción.

6:00 PM: El Jefe “Sin Backup no Hay Paraíso”

Justo cuando creo que puedo irme, mi jefe aparece con cara de preocupación:

– “¿Tenemos backup de todo esto, verdad?”.

Le muestro mi carpeta de backups, replicados hasta en la luna si es necesario. Porque si algo tengo claro después de años de sufrimiento es que sin backup, no hay DBA que sobreviva.

Conclusión: La vida del DBA es un Reality Show

Un día más salvando a Paco, Toñi, Manolo y Javi de ellos mismos. Un día más optimizando consultas, corrigiendo scripts desastrosos y asegurando que el servidor no arda en llamas. La próxima vez que escuches «¿pero qué hace un DBA?», recuérdales que sin nosotros, el caos reinaría en el mundo de los datos.

Y si alguno de estos personajes te suena… ¡ánimo! Seguro que en tu día a día también te encuentras con alguno de ellos.

Espero que este artículo te haya resultado divertido y ameno. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Dic

2024

Cómo ser DBA y no morir en el intento (Artículo de HUMOR)

Trabajar de DBA de SQL Server es un oficio lleno de misterio, expectativas y, por qué no decirlo, frustraciones. Para empezar, nadie fuera del departamento técnico sabe realmente qué hacemos. La frase «oye, ¿y eso no lo hace Excel?» ya la hemos oído más veces que el «hola» de nuestra madre. Y es que la vida del DBA no es fácil. Somos los héroes olvidados del backend, los guardianes de las consultas bien escritas, los que nos mantenemos despiertos mientras el servidor dice «timeout expired».

El Ritual del SELECT TOP 1

El primer mandamiento del DBA es: «No harás un SELECT * sobre producción». ¿Lo hemos hecho? Más veces de las que admitiremos públicamente. Nos han pillado… Una vez. Desde entonces, siempre usamos el sagrado TOP 1 como si fuera un amuleto de buena suerte.

Y claro, cuando el jefe nos pregunta si la consulta es rápida, respondemos con la calma del que sabe que su CTE tiene 15 niveles de recursión: «Depende de cuántas JOINS a tablas tenga».

Mi job de mantenimiento es tu pesadilla

Hay dos tipos de personas en el mundo: las que confían ciegamente en sus backups y las que aún no han sufrido una catástrofe. Un DBA vive cada día en ese delgado filo entre la tranquilidad y el infarto. Si CHECKDB devuelve errores, la presión sanguínea sube más rápido que un autoincremental en una tabla de log. Y, por supuesto, siempre está el compañero de «¿para qué necesitamos índices? El SQL Server ya lo resuelve solo».

Amigo, si piensas eso, espero que te guste el café frío y las noches de insomnio porque tú y los deadlocks vais a ser mejores amigos.

El cliente que cambia las reglas del juego

Todos hemos tenido ese momento glorioso cuando un desarrollador dice: «es que necesitaba agregar una columna con un VARCHAR(MAX) para meter más datos«. Claro, porque meter más datos no tiene ningún impacto en el rendimiento… spoiler alert: sí lo tiene. El resultado suele ser que la tabla pasa de «normalita» a «más ancha que la autopista de circunvalación».

Y ahí estamos nosotros, intentando convencerles de que VARCHAR(100) ya era suficiente. Pero no, necesitamos ser «future-proof». Lo único proof aquí es el dolor de cabeza que nos deja el nuevo plan de ejecución.

El Optimizer: Nuestro juez implacable

La vida de un DBA también gira en torno a una relación tóxica: nosotros y el Optimizer. Esa entidad invisible que, por algún motivo, decide que el seek es aburrido y prefiere hacer un table scan como si estuviera buscando las llaves del coche en un descampado. ¿La causa? Quizás fue el parameter sniffing, la luna llena o simplemente un lunes.

Cuando el Execution Plan se vuelve contra nosotros, tenemos dos opciones: optimizar o sacar la carta prohibida del HINT. Porque, seamos sinceros, a veces un OPTION (RECOMPILE) nos salva más que un paracetamol.

El usuario de «Es solo una consulta»

Si trabajas de DBA, habrás oído la temida frase: «es solo una consulta rápida, ¿puedo lanzarla en producción?«. «Solo una consulta rápida» significa que va a tardar 45 minutos, tirar el servidor y llevarse puestos otros procesos en el camino. No falla.

Es más, cuando el usuario aparece en nuestra bandeja de entrada con el ASAP, ya sabemos que no será ni rápido ni sencillo. El «as soon as possible» no aplica en SQL Server si hay un WHERE mal puesto y un índice invisible que clama venganza.

Conclusión: Ser DBA es un oficio heroico

Al final del día, seguimos aquí. Porque aunque SQL Server sea un pequeño tirano, nos encanta domarlo. Amamos ver cómo un plan de ejecución mejora, cómo los backups funcionan cuando los necesitamos y cómo ese usuario que decía que «la base de datos está lenta» acaba reconociendo que el problema estaba en su código.

La próxima vez que un compañero te pregunte si el problema es del servidor, responde con un guiño: «¿Y has revisado tu código?«. Porque, amigos, el DBA no culpa… solo observa.

¡Larga vida a la optimización de consultas y que los CHECKDB estén siempre de vuestro lado!

cloud

La SQLCon llega a España

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes