SQL Server

Optimización avanzada de Backups: BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT

Cuando diseñamos nuestra estrategia de copias de seguridad en SQL Server, es esencial considerar no solo la integridad de los datos, sino también la eficiencia de los procesos. Quiero decir, además de la retención de los backups y factores como RPO y RTO que siempre tenemos en cuenta tenemos que pensar también en el rendimiento. En este sentido, ya hicimos un video sobre cómo afectaba la compresión de los backups a los tiempos de copia y restauración, ¿lo recuerdas? Lo tienes aquí por si quieres revisarlo.

Hoy, sin embargo, vamos a ir un paso más allá con esto del rendimiento de las copias de seguridad y vamos a ver tres opciones avanzadas que pueden marcar la diferencia en los tiempos y la utilización de recursos; estoy hablando de BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT. Vamos a ver cómo funcionan y cómo optimizarlas.

Introducción al funcionamiento de las opciones de backups

Para entender estos complejos conceptos lo más simple posible tenemos que empezar pensando en el proceso de backup en SQL Server como en la transferencia de datos desde la base de datos hacia un destino de almacenamiento. Durante este flujo, como en cualquier transferencia de información informática, el tamaño del bloque, la cantidad de buffers y la cantidad de datos transferidos por operación son factores clave que pueden afectar considerablemente el rendimiento.

Entonces, tenemos por un lado el parámetro BLOCKSIZE que define el tamaño del bloque de datos utilizado en la operación de backup, MAXTRANSFERSIZE que determina el tamaño máximo de los datos que se transfieren en una única operación de I/O y BUFFERCOUNT que especifica cuántos buffers se asignan para la operación.

BLOCKSIZE

Como acabamos de comentar el parámetro BLOCKSIZE define el tamaño, en bytes, de los bloques que se utilizan para escribir datos en el medio de almacenamiento durante el backup. 

De manera predeterminada, y si no modificamos nada tendrá un tamaño de 64 KB. Sin embargo, podemos modificarlo, admitiendo valores que pueden oscilar entre 512 bytes y un máximo de 4 MB.

Un BLOCKSIZE mayor puede resultar en un uso más eficiente del disco, especialmente en sistemas con discos de alta velocidad y controladores optimizados.

Sin embargo, no todos los dispositivos admiten tamaños de bloque personalizados. Es vital verificar la compatibilidad con el hardware subyacente.

Ejemplo de uso:

MAXTRANSFERSIZE

Este parámetro controla la cantidad máxima de datos transferidos entre SQL Server y el medio de almacenamiento en una sola operación de I/O. Tiene un rango de valores posibles desde el mínimo 64 KB hasta un máximo de 4 MB (desde SQL Server 2012).

Un MAXTRANSFERSIZE mayor puede reducir la cantidad de operaciones de I/O, mejorando la velocidad del backup. Aumentar este valor puede ser beneficioso sobre todo en dispositivos con alto rendimiento de escritura secuencial como los actuales discos SSD. Pero cuidado, configurar valores altos puede requerir más memoria en el servidor, lo que podría ser contraproducente en sistemas con recursos limitados.

Ejemplo de uso:

BUFFERCOUNT

Acabamos de hablar de la memoria y para optimizar este recurso y no tener problemas tenemos este último parámetro. BUFFERCOUNT define el número de buffers de memoria que se utilizarán durante la operación de backup. Es importante definirlo correctamente, sobre todo si hemos modificado los parámetros anteriores. 

Una mala configuración de BUFFERCOUNT nos puede dar muchos dolores de cabeza, por ejemplo valores bajos nos pueden provocar cuellos de botella si el flujo de datos excede la capacidad de los buffers disponibles y, sin embargo, unos valores altos aunque aprovechan al máximo la memoria disponible, deben equilibrarse con otros procesos en ejecución o usurparán sus recursos. Por suerte, tenemos una fórmula básica para calcular BUFFERCOUNT:

BUFFERCOUNT = (MAXTRANSFERSIZE / BLOCKSIZE) * número de hilos.

Ejemplo de uso:

Cómo optimizar tu backups

Ahora que ya hemos visto las tres configuraciones por sepradao vamos a ver como aplicarlas juntas. Esta es la clave ya que el rendimiento de los backups depende de cómo se ajustan estas tres opciones en conjunto. 

Lo primero que debemos hacer es analizar nuestro hardware.Si el sistema tiene discos rápidos y suficiente memoria, aumentar BLOCKSIZE y MAXTRANSFERSIZE puede sernos ventajoso. En sistemas con I/O limitado, priorizar un BUFFERCOUNT ajustado puede equilibrar la carga y ayudarnos a no impactar en otras operaciones.

En cualquier caso, es fundamental probar diferentes combinaciones en un entorno de prueba, lo más parecido al real posible, para determinar qué configuración ofrece el mejor rendimiento.

Lo cierto es que aunque SQL Server utiliza valores predeterminados razonables, ajustar estas opciones para nuestro escenario concreto puede ser crucial, sobre todo en bases de datos grandes o sistemas críticos.

Ejemplo completo:

En este ejemplo el BLOCKSIZE de 64 KB se combina con el MAXTRANSFERSIZE de 1 MB. 

El BLOCKSIZE de 64 KB es el adecuado si hacemos nuestros backups en un disco de los formateados según las buenas prácticas de SQL Server. Recordad que en estos discos definimos un tamaño de bloque de 64 KB que es justo lo que ocupa un EXTEND, es decir un bloque de 8 páginas cada una de 8 KB. El  MAXTRANSFERSIZE se ajusta a 1 MB para permitir que cada operación de I/O mueva datos en bloques razonablemente grandes, optimizando las escrituras en disco.

Ahora, si para estas operaciones de backup queremos aplicar 2 hilos, es decir dos núcleos virtuales del procesador, aplicamos la fórmula que hemos visto antes y nos da ese resultado.

32 = ( 1048576 /  65536 ) * 2

Conclusión

Las opciones BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT nos ofrecen un control detallado sobre el rendimiento de las operaciones de backup en SQL Server. Aprovecharlas de manera efectiva requiere un análisis cuidadoso del entorno y pruebas específicas hasta dar con la mejor combinación. Pero merece la pena, en bases de datos críticas y de gran tamaño, estos ajustes pueden marcar una diferencia significativa, reduciendo los tiempos de los backups y optimizando el uso de recursos. 

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!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 3 comentarios

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 NormalColumnstore Archive
Compresión aplicadaCodificación de diccionario, run-length, bit-packingTodo lo anterior + compresión LZ77+Huffman
Impacto en almacenamientoReducción del 50-70%Reducción del 70-90%
Impacto en CPUBajoAlto (más procesamiento en consultas)
Velocidad de lecturaAltaReducida por el proceso de descompresión
Casos de uso idealesDatos transaccionales y de consulta frecuenteDatos 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

  1. 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.
  2. 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

    2. Habilitar Columnstore_Archive en todas las particiones

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

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

    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.

     

    Publicado por Roberto Carrancio en Cloud, Índices, Rendimiento, SQL Server, 0 comentarios

    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. 

    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!

    Publicado por Roberto Carrancio en Cloud, Rendimiento, SQL Server, 0 comentarios

    Compresión en SQL Server

    La compresión de datos en SQL Server es una funcionalidad clave que permite optimizar el almacenamiento y mejorar el rendimiento de entrada/salida (E/S) en bases de datos con grandes volúmenes de información. SQL Server ofrece dos tipos principales de compresión: a nivel de fila y a nivel de página. En este artículo veremos ambos métodos así como sus ventajas y casos de uso, y mostraremos cómo evaluar el impacto de estas técnicas en el almacenamiento mediante herramientas nativas de SQL Server.

    Compresión de fila

    La compresión de fila elimina redundancias en datos almacenados en columnas de tipos de datos de longitud fija, como CHAR e INT. Además, optimiza el almacenamiento de valores NULL y ceros.

    Características principales:

    Como no podía ser de otra manera, la principal característica de este tipo de compresión es la optimización ligera de espacio. Con esto quiero decir que reduce el tamaño al eliminar espacios en blanco innecesarios y valores repetitivos pero sin mucho impacto en el sistema. No es una compresión muy intrusiva, lo que nos lleva a su segunda característica principal, la compatibilidad. La compresión a nivel de fila es transparente para las operaciones de lectura y escritura, ya que no requiere descompresión y tiene un impacto bajo en la CPU (tercera característica). Esto la hace una solución ideal para sistemas con limitaciones de procesamiento.

    Casos de uso:

    Como ya hemos dicho esta solución es la más recomendada en tablas con numerosos valores NULL o ceros o tablas con columnas de tipos de datos de longitud fija donde tengamos limitaciones o estemos cerca del límite de la CPU. Si no tenemos problemas de CPU podremos optar por el siguiente tipo de compresión como vamos a ver ahora mismo.

    Compresión de página

    La compresión de página es la más completa, combina la compresión de fila con técnicas de codificación más avanzadas, como el uso de diccionarios para reducir patrones repetitivos dentro de las páginas de datos. Es decir, además de toda la compresión que ya teníamos a nivel de fila elimina los datos duplicados en disco para reducir así el espacio. Es como una “deduplicación” de los datos de la tabla, así entre comillas pero para entendernos.

    Características principales:

    Lo estarás ya imaginando, la principal característica de la compresión a nivel de página es la reducción significativa del espacio. Es ideal para tablas con datos repetitivos o históricos. Por contra tiene un mayor uso de CPU ya que requiere más procesamiento, especialmente durante la compresión inicial. Hay que poner en una balanza este coste extra de CPU al comprimir con la eficiencia en almacenamiento. En teoría reduce los costes al minimizar el espacio físico necesario pero carga la CPU. 

    Ahora bien, si no tenemos tantas escrituras y nuestro consumo de CPU es mayoritariamente en lecturas podemos llevarnos una sorpresa. Comprimir los datos hace que podamos almacenar más datos en RAM, incluso en la caché del procesador y puede darse el caso que lo que notemos sea justo lo contrario, una reducción del uso de la CPU. Si lo piensas no es tan descabellado, es la manera de trabajar de los índices.

    Casos de uso:

    En este caso, los casos de uso son un poco más específicos que en el anterior tipo. Usaremos la compresión a nivel de página en tablas de archivos históricos y tablas de solo lectura. También nos lo podemos plantear en bases de datos con grandes tablas con volúmenes de datos repetitivos siempre y cuando el consumo de CPU no sea un problema para nosotros. Por último, en servidores donde el principal cuello de botella sea la E/S de disco (ejem, Azure, ejem) el beneficio también será sustancial.

    Evaluación del impacto en el almacenamiento

    Antes de implementar la compresión, es fundamental evaluar el impacto potencial en el almacenamiento para entender los beneficios que puede ofrecer. SQL Server proporciona el procedimiento almacenado de sistema sp_estimate_data_compression_savings, que permite estimar el ahorro de espacio para diferentes tipos de compresión.

    Sintaxis del procedimiento:

    Ejemplo práctico:

    Supongamos que tenemos una tabla Ventas en el esquema dbo y queremos evaluar el impacto de habilitar compresión de página:

    Resultado:

    El procedimiento devuelve una estimación del espacio actual y el espacio proyectado después de aplicar la compresión. Esto incluye:

    • size_with_current_compression_setting: Tamaño actual.
    • size_with_requested_compression_setting: Tamaño estimado con la compresión solicitada.
    • savings_in_bytes: Ahorro en bytes.

    Implementación de la compresión

    Una vez evaluado el impacto, podemos habilitar la compresión mediante las siguientes instrucciones:

    Beneficios adicionales de la compresión

    En líneas generales, sea cual sea el tipo de compresión que utilicemos, hay una serie de ventajas que son comunes. El principal beneficio que podemos destacar es la reducción de espacio físico en disco o en almacenamiento en la nube lo que implica directamente una reducción de costes. Por otro lado, vamos a encontrarnos con mejoras en E/S lo que se traduce en operaciones más rápidas al transferir menos datos. 

    Por último, debemos hablar de la compatibilidad. La compresión no es solo a nivel tabla, también se aplica a índices, optimizando consultas.

    Conclusión

    La compresión en SQL Server es una herramienta poderosa para reducir costes y mejorar el rendimiento de bases de datos. Evaluar previamente el impacto con sp_estimate_data_compression_savings asegura que tomemos decisiones informadas, maximizando los beneficios en almacenamiento y rendimiento. Ya sea con compresión de fila o de página, estas técnicas pueden adaptarse a una amplia gama de necesidades y escenarios empresariales.

    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!

    Publicado por Roberto Carrancio en SQL Server, 0 comentarios

    ¿Por qué usar una red aislada para la comunicación de Always On (heartbeat network)?

    La implementación de una arquitectura de alta disponibilidad en SQL Server Always On es un elemento clave para garantizar la continuidad del negocio y la disponibilidad de los datos. Mucho hemos hablado ya de este tema en el blog pero, si queremos ir un paso más allá, uno de los aspectos fundamentales en esta configuración es la red de comunicación entre los nodos de un grupo de disponibilidad o una instancia de clúster de conmutación por error. En este contexto, el uso de una red aislada para la comunicación de Always On, conocida como heartbeat network, juega un papel esencial en la estabilidad y rendimiento de la solución.

    En este artículo, veremos por qué es recomendable utilizar una red dedicada para la comunicación de Always On, sus beneficios, y las mejores prácticas para su implementación.

    Importancia de la comunicación en Always On

    Always On en SQL Server nos permite la creación de entornos de alta disponibilidad y recuperación ante desastres mediante grupos de disponibilidad o clústeres de conmutación por error. Cuando lo configuramos, los nodos intercambian información de estado para determinar si uno de los servidores está en funcionamiento o si ha fallado y es necesario realizar una conmutación por error (failover).

    Este intercambio de información se realiza a través de un mecanismo denominado heartbeat, que envía señales de estado periódicas entre los nodos del clúster. Si un nodo deja de responder en un tiempo determinado, el sistema automáticamente asume que ha fallado y puede desencadenar una conmutación automática al nodo secundario si así lo hemos configurado.

    Además de la señal de heartbeat, en un Grupo de Disponibilidad Always On, esta misma red puede utilizarse para la sincronización de datos entre réplicas. Esto es especialmente crítico en entornos con replicación síncrona, donde la latencia y la estabilidad de la red influyen directamente en el rendimiento del sistema.

    ¿Por qué usar una red aislada para el heartbeat en Always On?

    Como acabamos de ver, el tráfico de comunicación de Always On es crítico para mantener la estabilidad del clúster. Sin una red dedicada, esta comunicación puede verse afectada por la congestión de la red principal, lo que podría provocar falsos positivos en la detección de fallos y generar conmutaciones innecesarias. Además el rendimiento de SQL podría verse afectado sobre todo en replicaciones síncronas donde todos los nodos tienen que confirmar la escritura del dato antes de aplicarse. A continuación, analizamos las razones principales por las que una red aislada es recomendada.

    1. Optimización del rendimiento en la replicación de datos

    En configuraciones de Grupos de Disponibilidad Always On, los datos pueden replicarse de forma síncrona o asíncrona entre los nodos.En la replicación asíncrona, el rendimiento no se ve tan afectado por la latencia de la red, ya que el nodo primario no espera confirmación antes de continuar procesando transacciones. Sin embargo, en la replicación síncrona, cada transacción debe confirmarse en todas las réplicas antes de considerarse completada. Si la red es lenta o está congestionada, la latencia de confirmación aumentará, ralentizando drásticamente el rendimiento de las aplicaciones que dependen de la base de datos.

    Utilizar una red dedicada para la sincronización de Always On reduce la latencia y garantiza tiempos de respuesta óptimos, evitando que la red de producción interfiera en la replicación de datos.

    2. Evita congestión en la red de producción

    Si la red de Always On comparte infraestructura con la red utilizada por los clientes y aplicaciones, el tráfico de consultas, backups y cargas de datos puede afectar negativamente la comunicación entre los nodos. Una red separada para heartbeat y sincronización de datos garantiza que las señales críticas del clúster no se pierdan ni se retrasen debido a otras cargas de trabajo.

    3. Reduce los falsos positivos en la detección de fallos

    Si los paquetes de heartbeat se retrasan o se pierden por congestión en la red, el clúster podría interpretar que un nodo ha fallado y desencadenar una conmutación innecesaria. Esto no solo interrumpe el servicio, sino que también puede generar pérdida de rendimiento o afectar transacciones en curso. Con una red dedicada, el tráfico de heartbeat permanece estable, minimizando estos riesgos.

    4. Mayor estabilidad en entornos de “misión crítica”

    En sectores críticos como finanzas, salud o comercio electrónico, donde SQL Server gestiona transacciones en tiempo real, cualquier interrupción puede tener un impacto severo. Una red dedicada para la sincronización y el heartbeat de Always On ayuda a mantener la estabilidad operativa, asegurando que la replicación de datos no se vea afectada por otros procesos.

    5. Mejor eficiencia en la recuperación ante desastres

    En escenarios donde Always On se extiende a un sitio de recuperación ante desastres (DR), la replicación de datos entre ubicaciones puede beneficiarse de una red dedicada para evitar problemas de latencia y pérdida de paquetes. Al separar el tráfico de sincronización, se mejora la eficiencia de la conmutación a los servidores de respaldo, reduciendo el tiempo de recuperación en caso de fallos.

    6. Mayor seguridad en la comunicación entre nodos

    Al utilizar una red aislada, los paquetes de comunicación de Always On quedan protegidos de posibles ataques de red o interferencias de otras aplicaciones. Esto es especialmente importante en entornos donde se manejan datos sensibles o regulados. 

    Buenas prácticas para implementar una red de heartbeat en Always On

    Para aprovechar al máximo los beneficios de una red dedicada en Always On, es recomendable seguir algunas buenas prácticas:

    Utilizar interfaces de red dedicadas para la red heartbeat 

    Cada nodo del clúster debe contar con al menos dos interfaces de red, una para la red de producción y otra exclusivamente para la comunicación de Always On (heartbeat + sincronización de datos). Esto permite segmentar el tráfico y garantizar que los paquetes críticos siempre tengan prioridad.

    Configurar métricas de latencia adecuadas

    Ajustar los valores de timeout y umbrales de latencia en el clúster es clave para evitar falsos positivos en la detección de fallos. Dependiendo de la infraestructura, puede ser necesario aumentar los valores predeterminados para optimizar la replicación.

    Implementar calidad de servicio (QoS)

    Si la red dedicada no es una opción viable, se pueden aplicar reglas de Quality of Service (QoS) para priorizar el tráfico de Always On sobre otros tipos de tráfico en la red de producción.

    Monitorizar constantemente la red heartbeat de Always On

    La monitorización activa de la red de comunicación y replicación de Always On es crucial para detectar anomalías antes de que afecten la estabilidad del clúster. Herramientas como SQL Server Management Studio (SSMS) y System Center Operations Manager (SCOM) pueden ayudar en esta tarea.

    Usar VLANs y segmentación de red para heartbeat 

    Si no es posible contar con una red física dedicada, una alternativa viable es configurar una VLAN (Virtual LAN) para separar lógicamente el tráfico de Always On del resto del tráfico de la red.

    Configurar múltiples rutas de comunicación

    Para entornos de alta disponibilidad extrema, es recomendable configurar múltiples rutas de comunicación entre los nodos utilizando distintas interfaces de red y switches redundantes. Esto permite continuar la comunicación en caso de fallos en una de las rutas.

    Conclusión

    El uso de una red aislada para la comunicación de Always On no solo garantiza una mayor estabilidad en la detección de fallos, sino que también optimiza el rendimiento en la replicación de datos, especialmente en configuraciones síncronas. Al reducir la latencia y evitar interferencias con el tráfico de producción, se mejora significativamente la eficiencia del clúster y se minimiza el riesgo de interrupciones.

    Para cualquier organización que dependa de SQL Server Always On, implementar una red dedicada para heartbeat y sincronización es una estrategia clave para mantener un rendimiento óptimo y asegurar la continuidad del servicio en entornos críticos.

    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!

    Publicado por Roberto Carrancio en Alta Disponibilidad, Rendimiento, SQL Server, 0 comentarios

    ¿Hasta qué punto ayuda el conocimiento del negocio a un DBA?

    El papel del administrador de bases de datos (DBA) ha evolucionado considerablemente con el tiempo. Si bien sus responsabilidades fundamentales siguen siendo la administración de sistemas, optimización del rendimiento y mantenimiento de la disponibilidad, el contexto en el que operan los datos ha adquirido una relevancia creciente. El conocimiento del negocio no solo potencia la eficiencia de un DBA, sino que también le permite aportar soluciones alineadas con los objetivos estratégicos de la organización.

    Diseño y modelado de bases de datos con propósito de negocio

    El diseño de bases de datos es una de las áreas donde más se nota la diferencia entre un DBA con conocimientos técnicos y otro que, además, entiende el negocio. Cuando un administrador comprende los procesos empresariales, como la estructura de ventas, el control de inventario o los flujos de producción, el modelado de datos se vuelve más coherente y efectivo. Este conocimiento permite crear esquemas que reflejan la operativa real, optimizando no sólo la integridad de los datos, sino también la capacidad del sistema para dar respuesta a las necesidades de la organización.

    Por ejemplo, en un escenario donde los reportes financieros son fundamentales para la toma de decisiones, un DBA con visión de negocio podrá anticipar qué tablas y consultas son críticas. Esto le permitirá definir índices, particiones y optimizaciones específicas para esas áreas, asegurando que los procesos clave se ejecuten con rapidez. Por el contrario, un diseño basado exclusivamente en criterios técnicos puede generar soluciones rígidas que dificultan la adaptación a los cambios en los requisitos del negocio.

    Todo esto es importante aunque el DBA no sea quien define y modela ya que, aun en estos casos, su supervisión es crítica. Además esta visión global le facilitará anticiparse a problemas causados por un fallo en este sentido.

    Optimización de rendimiento alineada con el negocio

    El conocimiento del negocio también desempeña un papel clave en la optimización del rendimiento. Aunque las métricas técnicas son esenciales para medir la eficiencia de una base de datos, estas carecen de sentido si no están alineadas con las prioridades de la empresa. Cuando los DBA entendemos el impacto real de un proceso podemos enfocarnos en optimizar las consultas o tareas que realmente afectan al negocio.

    Cuando una consulta tarda demasiado en ejecutarse, es fundamental comprender cómo se utilizan esos datos. Si el rendimiento afecta directamente a la generación de reportes de ventas o análisis de inventario, nuestras acciones como DBA deberán enfocarse en resolver ese problema con la mayor prioridad. Al conocer la operativa, podemos tomar decisiones más acertadas, como proponer estrategias de ColumnStore, particionado o ajustes de índices específicos, sabiendo que estas optimizaciones repercutirán directamente en la eficiencia operativa de la organización.

    Por último también podremos anticiparnos y preparar el servidor para momentos de especial carga de trabajo como periodos de ofertas en tiendas, cierres fiscales en sistemas contables o cualquier eventualidad propia de nuestra empresa.

    Resolución de incidencias y priorización de tareas acorde a las necesidades de negocio

    La resolución de incidencias es otra área donde el conocimiento del negocio puede marcar una gran diferencia. Un DBA experimentado sabe que no todas las consultas o procesos tienen el mismo impacto. La comprensión de los procesos críticos, como el cierre contable mensual o los análisis de producción, nos permite a los administradores priorizar las tareas según su urgencia y relevancia para el negocio.

    Por ejemplo, durante un cierre financiero, un problema en las consultas que alimentan los reportes puede paralizar decisiones clave de la alta dirección. Un DBA que entiende la importancia de estos procesos actuará con celeridad, enfocando sus esfuerzos en identificar y resolver la causa raíz del problema. Esta capacidad para priorizar no solo mejora la eficiencia del administrador, sino que también garantiza que el negocio continúe funcionando sin interrupciones.

    Migraciones y rediseños orientados a las necesidades de negocio

    En proyectos de migración o rediseño de bases de datos, el conocimiento del negocio es aún más relevante. Estos procesos suelen implicar cambios estructurales y la adopción de nuevas tecnologías, lo que requiere una planificación detallada y un entendimiento claro de las necesidades empresariales. Un DBA que domina el contexto del negocio será capaz de proponer soluciones que no solo mejoren el rendimiento técnico, sino que también aporten valor a la organización. Por no hablar de que sin conocimiento de lo que pasa en el negocio solo vamos a poder cubrir las necesidades actuales que vemos sin ser capaces de prever lo que pasará en un futuro cercano. ¿Cómo vamos a poder dimensionar así correctamente un servidor nuevo?

    Durante una migración de SQL Server 2019 a 2022, por ejemplo, los administradores con esta perspectiva no nos limitaremos a realizar una actualización técnica. Evaluaremos el modelo de datos, identificaremos oportunidades de optimización y propondremos mejoras que beneficien a los procesos críticos del negocio. Esto puede incluir desde la implementación de nuevas funcionalidades del motor a ajustes en el almacenamiento de datos o la adopción de estrategias más eficientes para la gestión de consultas complejas.

    Colaboración entre equipos y comunicación efectiva

    Como DBA el conocimiento del negocio también nos facilita la colaboración con otros equipos, como desarrolladores, analistas de negocio y administradores de sistemas. Al actuar como un puente entre el lenguaje técnico y las necesidades empresariales, el administrador de bases de datos puede contribuir a la creación de soluciones más efectivas y alineadas con los objetivos de la organización. Esta comunicación fluida permite anticipar problemas, evitar malentendidos y asegurar que los esfuerzos propios del DBA tengan un impacto positivo en el funcionamiento global del negocio.

    Conclusión

    El conocimiento del negocio es una herramienta imprescindible para un administrador de bases de datos que aspire a aportar valor más allá de sus competencias técnicas. Esta comprensión le permite diseñar bases de datos eficientes, optimizar procesos clave y resolver problemas con mayor rapidez y eficacia. Además, facilita la colaboración con otros equipos y asegura que las decisiones del DBA estén siempre alineadas con los objetivos estratégicos de la organización. Al entender el contexto empresarial, el administrador no solo gestiona datos, sino que se convierte en un aliado fundamental para el éxito y la competitividad del negocio.

    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!

     

    Publicado por Roberto Carrancio en Otros, 0 comentarios

    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:

    -“¡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

    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:

    -“¡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:

    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:

    -“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:

    ¡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.

    Publicado por Roberto Carrancio en Otros, 1 comentario