Infra

Abr

2025

Cumplir con la ISO 27001 en SQL Server

Adaptar una instancia de SQL Server para cumplir con ISO 27001 no es simplemente activar Transparent Data Encryption y dormir tranquilo. Si alguien te lo ha vendido así, que no te extrañe si el día de la auditoría tienes que improvisar explicaciones más rápido que un becario ante un DROP DATABASE en producción. En este artículo vamos a abordar cómo orientar la configuración y operación de SQL Server para alinearse de verdad con los requisitos de esta norma. Sin humo. Sin soluciones mágicas. Con criterio técnico.

Seguridad en serio: ISO 27001 aplicada a SQL Server

La ISO/IEC 27001 no es una checklist de parches ni una receta genérica para “estar seguros”. Es una norma internacional que define cómo establecer, implementar y mantener un Sistema de Gestión de Seguridad de la Información (SGSI). Y sí, eso implica tanto políticas como controles técnicos. Justo ahí es donde entra SQL Server: no vamos a “certificar” el motor como tal, sino a demostrar que su configuración forma parte de un sistema de seguridad coherente, mantenido y documentado.

Esto significa que no basta con que algo sea seguro. Tiene que serlo, parecerlo, estar documentado y poder demostrarse con evidencias. ¿Te suena familiar? Como cuando configuras xp_cmdshell bien restringido y luego alguien te pregunta por qué no está deshabilitado del todo.

Control de accesos: la piedra angular de la 27001

Si hay una sección que una auditoría va a mirar con lupa, es esta. Y con razón. La gestión de identidades y accesos (IAM) es una de las piedras angulares del SGSI. Aquí es donde SQL Server suele enseñar sus vergüenzas.

Hay que empezar por lo básico: el control estricto de quién accede, a qué y cómo. Eso implica eliminar cuentas de servicio genéricas y acabar con el uso de sa (y si alguien lo necesita “por si acaso”, que se compre una linterna y se prepare para picar en la mina). La autenticación integrada con Active Directory debe ser la norma, no la excepción, y si aún usamos SQL Login para aplicaciones, que al menos estén cifrados y restringidos por roles mínimos.

Es fundamental auditar permisos y revisar regularmente los roles. Y no, eso no se hace con un Excel que alguien actualizó “hace unos meses”. Hay que generar informes automáticos, versionados, y con trazabilidad. Si alguien se añade al rol db_owner y nadie se entera, no tenemos un SGSI, tenemos una partida de ruleta rusa.

Registro y trazabilidad: En la 27001 lo que no se audita no existe

ISO 27001 es bastante explícita en esto: todo acceso relevante y toda operación sensible debe poder ser rastreada. Aquí entra en juego SQL Server Audit, nuestro viejo amigo. Bien configurado, nos permite registrar accesos, cambios de permisos, ejecuciones de procedimientos críticos y cualquier otra acción que entre en la categoría de “esto podría ser un problema si lo hace el usuario equivocado”.

Importante: no vale con activar la auditoría. Hay que almacenarla de forma segura, revisar los logs con periodicidad definida y tener mecanismos de alerta ante anomalías. Un fichero .sqlaudit guardado en una carpeta que nadie mira es como un extintor de cartón en una vitrina de cristal: muy decorativo pero no vale de nada.

Si usas Extended Events para auditorías avanzadas, perfecto. Pero asegúrate de que no sea algo que sólo entiendes tu y otro DBA senior. La documentación debe existir y ser entendible por otros perfiles técnicos.

Cifrado y protección de datos: porque el disco no se protege solo

El cifrado es una parte clave del cumplimiento, pero también uno de los terrenos donde más se abusa del postureo técnico. Que sí, que activar TDE está bien, pero eso no convierte el sistema en “cumplidor”. Hay que ir más allá.

Hablamos de cifrar tanto en reposo como en tránsito. Para lo primero, TDE más Backup Encryption son un buen punto de partida. Pero si hay datos sensibles, necesitamos también Always Encrypted para proteger valores a nivel de columna. Y eso implica repensar aplicaciones y procedimientos. ¿Molesta? Sí. ¿Es necesario? También.

El tráfico por la red entre cliente y servidor debe ir cifrado con TLS. Nada de conexiones en texto plano, y mucho menos con certificados auto-firmados abandonados en un rincón desde 2012. Una revisión de certificados y políticas de cifrado debe formar parte de las tareas periódicas del equipo de DBA, no un apéndice olvidado.

Lo que dice la ISO 27001 de gestión de vulnerabilidades y actualizaciones

Poner los parches de seguridad no es opcional, por mucho que el jefe de proyecto diga que “no conviene tocar nada en producción” o esa frase que tanto hemos oído “si funciona no lo toques”. ISO 27001 exige un proceso definido de gestión de vulnerabilidades, y eso implica inventario, evaluación del impacto, planificación de despliegues y pruebas.

Aquí SQL Server se alinea bien si lo integramos en un ciclo de gestión de parches serio. No vale con instalar el último CU cada seis meses “cuando haya tiempo”. Debemos definir criterios de urgencia, ventanas de mantenimiento, y mecanismos de rollback (sí, backups y pruebas en entornos espejo).

Si alguien aún depende del mail de Microsoft para enterarse de un nuevo CVE, hay que revisar el proceso. Un SGSI que no tiene un canal automático de recepción y evaluación de alertas es como un antivirus sin actualizaciones.

Disponibilidad y recuperación: lo que nadie quiere probar

La norma también cubre la resiliencia del servicio y la capacidad de recuperación ante desastres. Aquí es donde SQL Server tiene mucho que ofrecer, pero sólo si lo usamos bien.

Necesitamos backups automáticos, verificados y documentados. ¿Y las restauraciones? También. No basta con tener copias: hay que probar que funcionan y registrar esas pruebas. Los planes de recuperación deben contemplar diferentes escenarios: pérdida parcial, fallo total, ransomware…

Además, si hay servicios críticos, hay que implementar HA: desde grupos de disponibilidad Always On, hasta clústeres de failover, pasando por réplicas geográficas si el contexto lo exige. Pero cuidado: ningún mecanismo de alta disponibilidad sustituye una buena política de respaldo. El que lo crea debería dejar de leer folletos de marketing.

Documentación y procedimientos: el arte de escribir sin florituras para la 27001

Todo lo anterior no sirve de nada si no está documentado. Y con documentado no nos referimos a un PDF lleno de obviedades técnicas que nadie ha revisado desde 2021.

Debemos tener procedimientos claros para el alta y baja de usuarios, cambios de permisos, mantenimiento programado, revisión de auditorías, gestión de incidencias, y un largo etcétera. Todo ello debe estar accesible, versionado y validado. No se trata de cumplir por cumplir, sino de poder demostrar que sabemos lo que hacemos, cómo y por qué.

Además, durante una auditoría, estos documentos son el salvavidas que puede evitar un informe lleno de “no conformidades”. Si todo el conocimiento está en la cabeza del DBA veterano que ahora trabaja en otra empresa, tenemos un problema. Y un problema de los gordos.

Cultura de seguridad: porque no todo es técnica en la ISO 27001

Aunque suene raro en un blog de DBAs, ISO 27001 también exige que la organización tenga una cultura de seguridad. Esto implica formación, concienciación y procesos que no dependan exclusivamente de las ganas del equipo técnico.

Desde el punto de vista de SQL Server, esto se traduce en revisar que los desarrolladores no guarden contraseñas en texto plano, que las aplicaciones no se conecten como sa, y que los cambios estructurales no se hagan directamente en producción “porque lo pide el jefe”. En resumen: sentido común, respaldado por normas internas.

Conclusión

Adaptar SQL Server para cumplir con ISO 27001 no es cuestión de marcar casillas, sino de asumir responsabilidades. Hay que proteger los datos, controlar accesos, auditar acciones, cifrar donde toca, aplicar parches sin miedo y documentar sin aburrir.

No se trata de ser paranoico, sino profesional. De tener un entorno donde, si mañana alguien pide un informe de seguridad, podamos sacarlo sin sudar. Y si hay una brecha, podamos demostrar que lo hicimos todo bien. Porque al final, eso es la seguridad real: no solo evitar el desastre, sino estar preparados para responder con firmeza si llega.

Como siempre, que nadie os venda soluciones milagrosas. La seguridad en SQL Server, como todo lo que merece la pena, se trabaja. Y si lo hacemos bien, no solo cumplimos ISO 27001: dormimos un poco más tranquilos.

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!

Abr

2025

Grupos de alta disponibilidad Always On Distribuidos

Hay momentos en la vida de un DBA en los que la alta disponibilidad ya no es suficiente. Hemos sobrevivido a clústeres fallidos, a discos compartidos corruptos y a réplicas que se desconectan con la gracia de una llamada de Teams a las 3 de la madrugada. En ese punto, cuando el entorno ya es exigente, el SLA nos aprieta y la palabra «disponibilidad» se queda corta, es cuando entramos en el terreno de los Availability Groups distribuidos.

Y no, no hablamos de tener un par de réplicas en distintas zonas de disponibilidad dentro del mismo centro de datos. Hablamos de desacoplar entornos completos en distintas regiones, con su propio clúster, su propia lógica de failover, y aún así, mantener la sincronización de nuestras queridas bases de datos. Bienvenidos al club.

¿Qué demonios son los AG distribuidos?

Un AG distribuido (Distributed Availability Group, para los amigos) es una especie de “supergrupo” de alta disponibilidad. No estamos montando un único AG con réplicas dispersas. Estamos conectando dos AG independientes como si fueran nodos de un mismo sistema. Y eso lo cambia todo.

Cada uno de los AG que participan en un DAG (sí, también lo llaman así) tiene su propia topología: su clúster de Windows, sus réplicas, su configuración de quórum, su failover automático. Se comportan como entornos autónomos, que además se sincronizan entre sí a través de una réplica intermedia que hace de “puente” entre ambos mundos. ¿El resultado? Podemos tener un AG en Madrid y otro en Dublín, y replicar entre ellos de forma controlada, tolerando fallos completos del entorno primario sin perder la cabeza.

No es magia. Es ingeniería. Y, como todo lo potente, requiere cabeza y experiencia.

Arquitectura de un DAG: dos mundos bien separados

La gracia del AG distribuido es que cada uno de los AG participantes se gestiona por separado. Esto nos da una ventaja brutal en términos de recuperación ante desastres: si uno se cae por completo, el otro puede activarse sin necesidad de que el primero esté en línea. No hay dependencia directa entre ellos, ni a nivel de clúster, ni de quorum, ni de discos compartidos. Cada AG es soberano en su dominio, y eso, en un mundo donde los CPDs pueden arder, es oro puro.

La configuración básica requiere lo siguiente:

Dos AG independientes, cada uno con su propio clúster de Windows.
Al menos una réplica en cada AG que actuará como “forwarder” (la que se conecta con el otro AG).
Comunicación de red directa entre las réplicas forwarders (y permisos adecuados, claro).
Certificados válidos en ambos entornos si usamos endpoints con autenticación por certificado (spoiler: casi siempre).
DNS y nombres de servidor que no se pisen entre sí. Si tienes dos réplicas llamadas SQLSRV01 en distintas regiones, vas a llorar.

¿Resultado? Una topología que no depende de un solo clúster de Windows, que permite failover regional controlado, y que puede integrarse perfectamente con estrategias de backup y DR serias.

La sincronización es asíncrona. Y eso está bien

Una pregunta habitual: ¿puedo tener un DAG con sincronización síncrona?

Respuesta corta: no.

Respuesta larga: la sincronización entre los dos AG de un DAG siempre es asíncrona. No es negociable. Y antes de que alguien lo vea como una limitación, recordemos que estamos hablando de replicar entre regiones completas, separadas por cientos o miles de kilómetros. Pedir sincronía aquí es como pedirle baja latencia a una conexión satelital. Lo importante es entender que esto no es para alta disponibilidad de datos en tiempo real, sino para continuidad del negocio ante desastres mayores.

Si necesitamos RPO cero, esto no es para nosotros. Si podemos tolerar unos segundos (o minutos) de pérdida en caso de caída total del entorno primario, entonces un DAG puede ser nuestra mejor baza.

¿Qué se puede hacer con Always On Distribuidos?

Lo primero y más importante: podemos tener una réplica totalmente operativa en otra región, lista para convertirse en nueva primaria si la original cae. Esta réplica puede formar parte de un AG secundario completo, con su propio listener, sus propias réplicas locales, y servir tráfico de lectura si así lo queremos.

Lo segundo: la recuperación ante desastres se convierte en un proceso autónomo. Si se va la luz en todo nuestro entorno primario (sí, ha pasado), podemos activar el AG secundario sin tener que reconstruir el entorno entero o esperar a que vuelva a estar online. Y esto no solo ahorra tiempo: salva el negocio.

Y lo tercero: permite hacer actualizaciones o migraciones sin downtime completo. Podemos preparar todo en el AG secundario, sincronizar, hacer el failover distribuido, y luego ajustar el entorno primario con tranquilidad. Es una forma de reducir riesgos en cambios grandes sin jugar al funambulista con el entorno de producción.

El failover en los AG Distribuidos: aquí mandamos nosotros

Un punto clave en los AG distribuidos es que no hay failover automático entre los dos AG. Esto es deliberado. No estamos hablando de un nodo que se cae por una hora y queremos rebotarlo automáticamente. Estamos hablando de fallos graves, donde lo último que queremos es que el sistema tome decisiones por su cuenta sin entender el contexto.

Por eso, el failover entre AGs distribuidos es manual. Y eso está bien. Podemos automatizarlo con scripts, orquestarlo con herramientas de gestión, y tenerlo documentado al detalle. Pero el botón rojo lo apretamos nosotros, cuando hemos validado que el entorno primario está realmente muerto y no va a levantarse en los próximos 5 minutos.

Una vez hacemos el failover, el AG secundario se convierte en el nuevo primario del DAG. Desde ahí, podemos operar normalmente, restaurar backups, servir peticiones y mantener el negocio en marcha. Cuando el entorno primario vuelva, podremos reintegrarlo en el DAG, pero el proceso no es automático ni trivial. Hay que hacerlo bien, con scripts preparados, sin improvisar.

AG Distribuidos en la nube: promesas, realidades y facturas

Cuando nos movemos a la nube —sea Azure, AWS o cualquier otro proveedor que venda disponibilidad como si fuera pan caliente—, los DAG siguen siendo perfectamente viables, pero el terreno cambia. En Azure, por ejemplo, podemos montar un DAG entre dos regiones usando máquinas virtuales con clústeres de Windows tradicionales o bien utilizando SQL Server en instancias de Azure VM con ILB (Internal Load Balancer) para simular el listener. Lo mismo ocurre en AWS, donde los DAG pueden desplegarse entre zonas de disponibilidad o incluso regiones distintas, aunque allí la gestión de redes, rutas y permisos puede volverse un pequeño infierno si no se domina bien el entorno VPC.

La ventaja clara en la nube es la infraestructura: tenemos latencias razonables entre regiones, almacenamiento redundante, y posibilidad de automatizar el despliegue completo con plantillas (CloudFormation, Terraform u otro, según tus gustos). Pero también hay que tener en cuenta que el coste de mantener dos entornos completos sincronizados no es trivial. Especialmente si se usan discos premium, réplicas activas y tráfico constante entre regiones.

Además, muchos se olvidan de que en la nube no hay testigos compartidos para el quórum, lo que obliga a diseñar bien la lógica de los clústeres para evitar split-brain. Y ojo con los nombres DNS y los certificados: en la nube, los nombres internos de las máquinas cambian, los certificados caducan cuando nadie mira, y el tráfico entre regiones puede requerir ajustes de firewall que no siempre están bien documentados. En resumen: se puede, se debe, pero hay que saber lo que se está haciendo. Porque aquí, equivocarse cuesta dinero. Literalmente.

Otra opción sería tener un AG en local y el distribuido en la nube. De esta manera reducimos costes y tenemos lo mejor de ambos mundos, la infraestructura local controlada y con menor latencia desde nuestra red y la copia segura en la nube replicada casi en tiempo real. Lista para una actuación de emergencia, como ese seguro de viajes que pagas pero deseas no tener que usar nunca.

Cosas que pueden salir mal (y lo harán)

Como todo en SQL Server que involucra clústeres, redes y nombres, hay margen para el desastre elegante. Algunas perlas:

Si los certificados no están bien configurados en ambos lados, la réplica forwarder no podrá conectar. Y lo descubrirás justo cuando más prisa tengas.
Si los nombres de los nodos se repiten en ambas regiones, los endpoints fallarán y la sincronización no se iniciará.
Si los puertos necesarios están bloqueados por firewalls, los AG estarán técnicamente configurados pero no replicarán una coma.
Si no documentas el proceso de failover, nadie sabrá qué hacer cuando llegue el momento. Especialmente tú, bajo presión.

Por eso, cualquier DAG serio necesita una prueba completa de recuperación. Hay que simular la caída del entorno primario, validar el failover al secundario, probar el listener, comprobar la latencia, y luego revertir. Si no has hecho esto al menos una vez, tu DAG es una promesa. No una solución.

Conclusión

Un AG distribuido no es para todo el mundo. Tiene complejidad, tiene costes y tiene curva de aprendizaje. Pero si lo que queremos es resiliencia real frente a desastres a nivel de región, y si nuestro negocio no se puede permitir estar horas (o días) sin SQL Server, entonces es una de las mejores inversiones técnicas que podemos hacer.

Eso sí: que nadie lo monte “porque queda bien en el diagrama”. Un DAG sin pruebas, sin documentación y sin monitoreo adecuado es una trampa. Pero bien hecho, es una fortaleza. Una que sigue operativa cuando el resto del castillo se cae.

Y en tiempos de incertidumbre, eso vale más que cualquier SLA firmado con letra bonita.

Abr

2025

Técnicas de Recuperación ante Desastres (DR) en Always On (AG)

Cuando hablamos de alta disponibilidad en SQL Server, hay un elefante en la sala que muchos prefieren ignorar: la recuperación ante desastres (DR) no es lo mismo que la alta disponibilidad. Y sí, podemos tener un Always On Availability Group en producción, funcionando como un reloj suizo, con réplicas síncronas, listeners con balanceadores bonitos y monitorización con colores llamativos y alertas inmediatas… pero si mañana se prende fuego el CPD o se rompe el clúster de Windows, más nos vale tener algo más que buenas intenciones.

Always On no evita el 100% de los desastres

Empecemos por desmontar un mito recurrente: “Tengo Always On, no necesito backups”. Esta frase existe. La hemos oído. Nos ha dolido. Tener un Availability Group distribuido con tres réplicas no es un sustituto de una estrategia de backup coherente. Es como decir que no hace falta cinturón de seguridad porque llevas airbag. A nivel técnico, los AG están pensados para disponibilidad, no para recuperación. Y desde luego, no protegen contra errores humanos, corrupción lógica ni DROP DATABASE ejecutados por ese usuario avanzado al que le dieron permisos “para que pueda trabajar tranquilo”.

Así que, antes de emocionarnos con réplicas distribuidas y latencias internacionales, empecemos con lo básico.

Los backups si nos salvan ante desastres

Los backups siguen siendo la base de cualquier estrategia de recuperación ante desastres, incluso (y especialmente) cuando usamos Always On. No hay excusa. Y sí, sabemos que hay quien piensa que como tiene tres réplicas en tres regiones, puede dormir tranquilo. Hasta que se borra un dato en la base de datos primaria, y esa operación se replica con precisión quirúrgica a las secundarias. Una especie de ransomware lento y sin rescate.

En un entorno con AG, es fundamental tener claro dónde y cómo hacemos los backups. Idealmente, deberíamos delegar las copias a las réplicas secundarias para liberar carga de la primaria. SQL Server lo permite desde hace varias versiones, y con una correcta configuración de las preferencias de backup, podemos establecer qué réplica se encargará de cada tipo de backup: full, log o copy-only.

Pero cuidado, porque no todas las réplicas valen para todo. Las copias completas deben realizarse en una réplica con acceso legible a la base de datos, y los logs solo en réplicas sincronizadas que reciban todas las transacciones. Además, asegúrate de que el software de backup (si usas uno) es compatible con AG y respeta las preferencias de backup configuradas en el clúster. Hay soluciones “enterprise” que, sorprendentemente, no lo hacen.

Y por si acaso recuerda: sí, seguimos necesitando restaurar las copias de vez en cuando para comprobar que funcionan. Testear la restauración no es una opción, es parte del proceso. ¿Tienes backups diarios? Genial. ¿Los has restaurado alguna vez? Porque si no lo has hecho, lo que tienes son archivos que ocupan espacio, no un plan de recuperación.

AG distribuidos: la aspiración de los ya experimentados en desastres

Si nos tomamos en serio la continuidad de negocio, y el presupuesto lo permite, debemos hablar de Availability Groups distribuidos. Esto no es simplemente una extensión de AGs tradicionales, sino una arquitectura pensada para verdaderas estrategias de recuperación ante desastres geográficamente dispersas. Aquí no estamos hablando de movernos de Madrid a Barcelona, sino de poder perder el centro de datos entero en Frankfurt y que el negocio siga operando desde Dublín sin sudar tinta.

Un AG distribuido se compone de dos (o más) AG independientes que se sincronizan entre sí mediante un listener y una réplica que actúa como puente. Esto implica una configuración más compleja, pero aporta una flexibilidad enorme. Cada lado del AG distribuido puede tener su propio clúster de Windows, su propio quorum, su propia lógica de failover, y no dependen directamente del otro para estar operativos. Es decir, si se rompe todo el AG primario, el secundario puede levantar cabeza por sí mismo, sin necesidad de consultar a nadie. Autonomía total, como un buen DBA cansado de justificarle al jefe por qué no es culpa suya.

Pero no es magia ni es todo tan bonito. Los AG distribuidos no hacen failover automático. Necesitan intervención manual o scripts muy bien preparados, monitorizados y probados. Y además, la sincronización es asíncrona, por lo que hablamos de cierta pérdida de datos en caso de desastre. Aceptarlo o no dependerá del negocio y de su tolerancia al RPO.

Consideraciones adicionales: DR de verdad

¿Todo configurado, AG distribuido listo, backups funcionando? Perfecto. Ahora hablemos de lo que realmente se rompe cuando todo lo demás funciona: la red y el DNS. Porque puedes tener la mejor estrategia del mundo, pero si el listener de SQL no resuelve correctamente en la región de DR, o si el firewall bloquea el puerto de sincronización, todo tu diseño se convierte en una bonita maqueta de PowerPoint.

La recuperación ante desastres es un proceso que debe contemplar todos los componentes, y eso incluye:

Que los clientes puedan conectarse automáticamente al entorno de DR sin intervención manual (o con la mínima posible).
Que los certificados estén correctamente instalados en todos los nodos si estamos usando encriptación.
Que los endpoints estén accesibles, los firewalls configurados y los balanceadores preparados para redirigir tráfico.
Que el almacenamiento de backups esté accesible desde ambos lados del AG (o, al menos, replicado adecuadamente).
Y más cosas específicas de tu arquitectura que solo tu sabes…

Un test de DR que no valida los nombres DNS, las ACL de red y la resolución de nombres es como una auditoría de seguridad en la que solo se revisan los colores del logo.

Automatización: scripts o muerte

La recuperación ante desastres no debería depender del pulso de una persona que lleva 20 horas despierto. Por eso, automatizar el proceso de failover y recuperación es obligatorio. No deseable. No recomendable. Obligatorio. Y no, no hablo de automatización genérica. Hablo de scripts personalizados para tu entorno, que validen el estado de las réplicas, que ejecuten el ALTER AVAILABILITY GROUP … FAILOVER cuando toque, y que actualicen rutas, registros DNS o configuraciones post-failover si es necesario.

¿Y la documentación? Sí, también es importante. Porque cuando suena el teléfono a las 4 de la mañana, necesitas saber qué hacer y no improvisar con algo que has visto en Stack Overflow o con lo que te ha dicho Chat GPT.

Conclusión

Always On es una herramienta potentísima para mantener la disponibilidad de nuestras bases de datos, pero no sustituye una estrategia de recuperación ante desastres (DR) bien pensada, bien ejecutada y bien documentada. Los backups siguen siendo sagrados. Los AG distribuidos son una bendición si se usan bien. Y los entornos sin pruebas de restauración o sin scripts de failover son simplemente apuestas disfrazadas de arquitectura.

Que un sistema esté “disponible” no significa que esté “protegido”. Y si no lo tenemos claro antes de la caída, lo aprenderemos después. Y no será barato.

¿Recomendación final? Probemos los escenarios de desastre antes de que lo sean. Porque el caos no avisa, pero nosotros sí podemos estar preparados.

Mar

2025

Crecimiento del Persistent Version Store (PVS) en SQL Server

En el día a día de la administración de bases de datos SQL Server, nos encontramos con diversas funcionalidades que buscan optimizar el rendimiento y la disponibilidad de nuestros sistemas. Una de ellas, la Recuperación Acelerada de Bases de Datos (ADR), introdujo un concepto fundamental para la gestión de transacciones y la recuperación ante fallos: el Persistent Version Store (PVS). Aunque el ADR nos brinda notables ventajas en cuanto a la rapidez de las reversiones de transacciones y la disponibilidad de la base de datos, su componente central, el PVS, puede convertirse en una fuente de preocupación si no comprendemos su funcionamiento y cómo controlar su tamaño. En este artículo, profundizaremos en qué consiste el PVS, cómo impacta en el espacio de almacenamiento de nuestras bases de datos y, lo más importante, qué estrategias podemos implementar para mantenerlo bajo control.

¿Qué es el Persistent Version Store (PVS) de SQL Server y cómo funciona?

El Persistent Version Store (PVS) es un mecanismo introducido con la característica de Accelerated Database Recovery (ADR) en SQL Server. Su principal función es almacenar las versiones antiguas de las filas que han sido modificadas por transacciones aún activas o recientemente completadas. Esta estrategia difiere significativamente del comportamiento tradicional de SQL Server sin ADR, donde los valores antiguos se guardan en el registro de transacciones. Con ADR, al modificar una fila, SQL Server escribe una nueva versión de dicha fila en la misma tabla, manteniendo la versión anterior intacta en el PVS. Esta arquitectura permite que las reversiones de transacciones sean prácticamente instantáneas, ya que el motor no necesita recuperar y aplicar información desde el registro de transacciones.

Es crucial entender que el PVS reside dentro de la propia base de datos de usuario, específicamente en los mismos archivos de datos (.mdf). Esta ubicación contrasta con el almacén de versiones utilizado por el Read Committed Snapshot Isolation (RCSI) cuando ADR no está habilitado, el cual se crea y mantiene en la base de datos del sistema TempDB. Aunque ambos mecanismos se basan en el versionado de filas para ofrecer lecturas consistentes sin bloqueos, la persistencia del PVS dentro de la base de datos de usuario tiene implicaciones directas en su tamaño y gestión.

¿Cómo influye el PVS en el tamaño de nuestra base de datos?

La implementación del PVS tiene un impacto directo en el consumo de espacio de nuestras bases de datos. Al almacenar múltiples versiones de las filas modificadas, es inevitable que el tamaño de la base de datos en disco aumente para albergar estas versiones. De hecho, al habilitar ADR, incluso antes de realizar modificaciones, se observa un aumento inicial en el tamaño de la tabla en comparación con una tabla idéntica sin ADR. Esto se debe a que ADR necesita añadir una marca de tiempo a cada fila para rastrear sus versiones.

Además del espacio ocupado por las versiones de las filas en sí, cada fila de la tabla con ADR habilitado contiene un puntero de 14 bytes que apunta a la ubicación de su versión en el PVS, incluso si la fila no ha sido modificada recientemente. Este overhead por fila es un factor significativo que contribuye al aumento del tamaño de la base de datos. Es importante señalar que este mismo puntero existe incluso cuando solo RCSI está habilitado (sin ADR), aunque en ese caso apunte al almacén de versiones ubicado en TempDB. Por lo tanto, el crecimiento en la tabla de usuario debido a este overhead es similar tanto con ADR como con RCSI. Hablamos de esto aquí.

Los experimentos han demostrado que, tras la carga inicial de datos en tablas con ADR y/o RCSI activados, estas tienden a ser más grandes que las tablas sin estas funcionalidades. Este crecimiento se acelera considerablemente al realizar actividad de escritura, llegando incluso a duplicarse el tamaño de los objetos tras la primera actualización en bases de datos con ADR y/o RCSI habilitados. Esta tendencia se mantiene con rondas sucesivas de actualizaciones, donde las bases de datos con versionado de filas experimentan un crecimiento mucho más rápido que aquellas sin él.

El PVS y el mito de la reconstrucción de índices para ahorrar espacio

Ante este crecimiento acelerado de las tablas con ADR y RCSI, una reacción común podría ser recurrir a la reconstrucción de índices como una solución para recuperar el espacio aparentemente «perdido». Efectivamente, al reconstruir los índices en estas tablas, se observa una reducción drástica en su tamaño, igualando incluso el tamaño de tablas sin ADR. Esto podría generar la ilusión de haber «ahorrado» espacio en disco.

Sin embargo, esta ganancia de espacio es puramente ilusoria y temporal. Tan pronto como la carga de trabajo habitual se reanuda y se realizan nuevas actualizaciones, el tamaño de las tablas con ADR y RCSI vuelve a inflarse rápidamente. Nos encontramos, por lo tanto, en un ciclo continuo de crecimiento y reconstrucción sin abordar la causa fundamental del aumento de tamaño: el versionado de filas necesario para el funcionamiento de ADR y RCSI.

La reconstrucción de índices simplemente reorganiza los datos y elimina las versiones antiguas que ya no son necesarias en el momento de la reconstrucción, pero no impide la generación de nuevas versiones con futuras modificaciones. Por lo tanto, si nuestro principal objetivo al reconstruir índices en un entorno con ADR o RCSI es ganar espacio en disco, debemos comprender que este ahorro será efímero. El espacio «ahorrado» volverá a ser necesario a medida que se generen nuevas versiones de las filas. En lugar de centrarnos en la reconstrucción como una panacea para el espacio, debemos enfocarnos en dimensionar adecuadamente nuestro almacenamiento y comprender las implicaciones del versionado de filas en el crecimiento de nuestras bases de datos.

Estrategias efectivas para controlar el tamaño del PVS

Dado que la reconstrucción de índices no es una solución sostenible para controlar el tamaño del PVS, ¿qué alternativas tenemos a nuestra disposición? La clave reside en comprender la naturaleza del PVS y cómo interactúa con la actividad de nuestra base de datos.

En primer lugar, es fundamental realizar un dimensionamiento adecuado del almacenamiento. Si habilitamos ADR, debemos ser conscientes del potencial crecimiento adicional que experimentará nuestra base de datos debido al almacenamiento de las versiones de filas y al overhead por fila. Ignorar este aspecto puede llevarnos rápidamente a situaciones de falta de espacio en disco.

En segundo lugar, la monitorización activa del tamaño del PVS es esencial. SQL Server nos proporciona herramientas para observar el comportamiento del PVS y detectar patrones de crecimiento inusuales. Mediante el uso de Dynamic Management Views (DMVs), como sys.dm_tran_persistent_version_store_stats, podemos obtener información valiosa sobre el tamaño actual del PVS, el porcentaje que representa del tamaño total de la base de datos, el número de transacciones abortadas y la antigüedad de las transacciones activas.

Además de la monitorización del tamaño, es importante analizar la actividad de la base de datos. Cargas de trabajo con una alta intensidad de escritura generarán más versiones de filas y, por lo tanto, un mayor crecimiento del PVS. Asimismo, las transacciones de larga duración pueden impedir la limpieza de las versiones antiguas, contribuyendo a un aumento sostenido del tamaño del PVS. Identificar y optimizar estas transacciones puede tener un impacto significativo en la gestión del espacio del PVS.

Monitorizando el Persistent Version Store

Terminar u optimizar las transacciones de larga duración se convierte en una práctica crucial. Si una transacción permanece abierta durante un tiempo prolongado, las versiones de las filas modificadas tanto por esa transacción como por todas las transacciones siguientes no podrán ser limpiadas del PVS, lo que provocará su crecimiento descontrolado.

Como mencionaba anteriormente, las DMVs son nuestras principales aliadas para supervisar el PVS. La DMV sys.dm_tran_persistent_version_store_stats nos ofrece una visión detallada del estado del almacén de versiones persistente. Algunas de las columnas más relevantes que podemos consultar son:

persistent_version_store_size_kb: Indica el tamaño actual del PVS en kilobytes.
oldest_active_transaction_id: El ID de la transacción activa más antigua.
oldest_transaction_begin_time: La hora de inicio de la transacción activa más antigua.

Podemos utilizar la siguiente consulta (de la documentación oficial) para obtener una visión general del PVS en nuestras bases de datos habilitadas para ADR:

SELECT pvss.database_id,
       DB_NAME(pvss.database_id) AS database_name,
       pvss.persistent_version_store_size_kb / 1024. / 1024 AS persistent_version_store_size_gb,
       100 * pvss.persistent_version_store_size_kb / df.total_db_size_kb AS pvs_percent_of_database_size,
       df.total_db_size_kb / 1024. / 1024 AS total_db_size_gb,
       pvss.online_index_version_store_size_kb / 1024. / 1024 AS online_index_version_store_size_gb,
       pvss.current_aborted_transaction_count,
       pvss.aborted_version_cleaner_start_time,
       pvss.aborted_version_cleaner_end_time,
       pvss.oldest_aborted_transaction_id,
       pvss.oldest_active_transaction_id,
       dt.database_transaction_begin_time AS oldest_transaction_begin_time,
       asdt.session_id AS active_transaction_session_id,
       asdt.elapsed_time_seconds AS active_transaction_elapsed_time_seconds,
       pvss.pvs_off_row_page_skipped_low_water_mark,
       pvss.pvs_off_row_page_skipped_min_useful_xts,
       pvss.pvs_off_row_page_skipped_oldest_aborted_xdesid
FROM sys.dm_tran_persistent_version_store_stats AS pvss
CROSS APPLY (
            SELECT SUM(size * 8.) AS total_db_size_kb
            FROM sys.master_files AS mf
            WHERE mf.database_id = pvss.database_id
                  AND
                  mf.state = 0
                  AND
                  mf.type = 0
            ) AS df
LEFT JOIN sys.dm_tran_database_transactions AS dt
ON pvss.oldest_active_transaction_id = dt.transaction_id
   AND pvss.database_id = dt.database_id
LEFT JOIN sys.dm_tran_active_snapshot_database_transactions AS asdt
ON pvss.min_transaction_timestamp = asdt.transaction_sequence_num
   OR pvss.online_index_min_transaction_timestamp = asdt.transaction_sequence_num
WHERE pvss.persistent_version_store_size_kb > 0
ORDER BY persistent_version_store_size_kb DESC;

Esta consulta nos proporciona información crucial para entender el consumo de espacio del PVS y la antigüedad de las transacciones activas, lo que nos puede ayudar a identificar posibles cuellos de botella o transacciones problemáticas que estén impidiendo la limpieza del almacén de versiones.

También es útil esta otra consulta (misma fuente) para obtener las consultas que pueden ser un potencial problema. Está parametrizada por defecto para localizar las transacciones de más de 15 minutos de duración o 1 Gb de log de transacciones, lo que ya empieza a ser preocupante y puede tener un impacto en el tamaño del PVS.

DECLARE @LongTxThreshold int = 900;  /* The number of seconds to use as a duration threshold for long-running transactions */
DECLARE @LongTransactionLogBytes bigint = 1073741824; /* The number of bytes to use as the generated log threshold for long-running transactions */

SELECT  dbtr.database_id,
        DB_NAME(dbtr.database_id) AS database_name,
        st.session_id,
        st.transaction_id,
        atr.name,
        sess.login_time,
        dbtr.database_transaction_log_bytes_used,
        CASE WHEN GETDATE() >= DATEADD(second, @LongTxThreshold, tr.transaction_begin_time) THEN 'DurationThresholdExceeded'
             WHEN dbtr.database_transaction_log_bytes_used >= @LongTransactionLogBytes THEN 'LogThresholdExceeded'
             ELSE 'Unknown'
        END
        AS reason
FROM sys.dm_tran_active_transactions AS tr
INNER JOIN sys.dm_tran_session_transactions AS st
ON tr.transaction_id = st.transaction_id
INNER JOIN sys.dm_exec_sessions AS sess
ON st.session_id = sess.session_id
INNER JOIN sys.dm_tran_database_transactions AS dbtr
ON tr.transaction_id = dbtr.transaction_id
INNER JOIN sys.dm_tran_active_transactions AS atr
ON atr.transaction_id = st.transaction_id
WHERE GETDATE() >= DATEADD(second, @LongTxThreshold, tr.transaction_begin_time)
      OR dbtr.database_transaction_log_bytes_used >= @LongTransactionLogBytes;

Conclusión

La introducción del Persistent Version Store (PVS) con la Recuperación Acelerada de Bases de Datos (ADR) representa un avance significativo en la forma en que SQL Server gestiona las transacciones y la recuperación. Sin embargo, como hemos explorado, su funcionamiento basado en el versionado de filas tiene implicaciones directas en el tamaño de nuestras bases de datos. La idea de que la reconstrucción de índices sea una solución efectiva para controlar este tamaño ha demostrado ser una ilusión temporal.

En lugar de recurrir a prácticas de mantenimiento obsoletas, debemos adoptar un enfoque más informado y proactivo. Esto implica dimensionar adecuadamente nuestro almacenamiento, monitorizar activamente el tamaño del PVS mediante las DMVs proporcionadas por SQL Server y, fundamentalmente, comprender y optimizar la actividad de nuestras bases de datos, prestando especial atención a las transacciones de larga duración.

En definitiva, la gestión exitosa del PVS requiere que evolucionemos nuestras rutinas de mantenimiento y nos centremos en comprender el mecanismo subyacente del versionado de filas. Solo así podremos tomar decisiones informadas y evitar invertir tiempo y recursos en acciones que nos ofrecen solo una sensación temporal de mejora, asegurando un rendimiento óptimo y una gestión eficiente del espacio en nuestras bases de datos SQL Server.

Mar

2025

¿Reconstruir índices? Quizá ya no tiene tanto sentido como pensábamos

Durante años, una de las tareas de mantenimiento más comunes en nuestros servidores SQL Server ha sido la reconstrucción de índices. La idea de eliminar la fragmentación, mejorar el rendimiento de las consultas y, en ocasiones, recuperar espacio en disco ha estado firmemente arraigada en nuestras rutinas. Sin embargo, la evolución de SQL Server con la introducción de características como Accelerated Database Recovery (ADR) y Read Committed Snapshot Isolation (RCSI) nos obliga a replantearnos si esta práctica sigue teniendo el mismo sentido que antes. En este artículo, basándonos en un experimento que hice recientemente, veremos cómo estas nuevas funcionalidades impactan en la necesidad de reconstruir índices y por qué, en muchos casos, puede que estemos invirtiendo tiempo y recursos de forma innecesaria.

¿Reconstruir índices con ADR? Un nuevo paradigma en la recuperación

Para entender por qué la reconstrucción de índices podría ser menos relevante con ADR, primero debemos recordar cómo funciona esta característica. Sin ADR, cuando modificamos una fila, SQL Server guarda los valores antiguos en el registro de transacciones y actualiza la fila directamente. Si la transacción se revierte, el motor debe recuperar los valores antiguos del registro y aplicarlos de nuevo a la fila. Cuantas más filas se hayan modificado, más tiempo tardará la reversión.

Con ADR, esta operativa cambia radicalmente. En lugar de sobrescribir la fila original, SQL Server escribe una nueva versión de la fila dentro de la misma tabla, manteniendo la versión antigua intacta. Esta estrategia permite que las reversiones de transacciones sean casi instantáneas, ya que no es necesario leer y aplicar información del registro de transacciones.

Como seguramente ya habréis imaginado, almacenar múltiples versiones de una misma fila en la tabla tiene un impacto directo en el consumo de espacio. Para demostrarlo, hace unos días realicé una prueba creando dos bases de datos idénticas, una con ADR habilitado (Test_ADR) y otra sin él (Test), y cargué ambas con un millón de filas en tablas con la misma estructura. Inicialmente, como era de esperar, la tabla con ADR activado (Products_ADR) ocupó más espacio que la tabla normal (Products). Esto se debe a que, de forma similar a RCSI, ADR necesita añadir una marca de tiempo a cada fila para rastrear sus versiones.

¿Reconstruir índices con ADR y RCSI? Un experimento revelador

La primera sorpresa llegó al reconstruir los índices en ambas tablas. Tras la reconstrucción, el tamaño de la tabla Products_ADR, que inicialmente era mayor, se redujo drásticamente hasta igualar el tamaño de la tabla Products. Esto nos plantea una pregunta intrigante: si ADR ya estaba activo al cargar los datos, ¿por qué la reconstrucción de índices liberó tanto espacio? Se podría pensar que las marcas de tiempo de versionado deberían haberse insertado con los datos iniciales, sin causar una fragmentación excesiva.

Repetí este experimento varias veces, incluso en bases de datos con ADR y RCSI activados simultáneamente, y los resultados fueron consistentes. Después de la carga inicial de datos, las tablas con ADR y/o RCSI tendían a ser más grandes. Sin embargo, tras una reconstrucción de índices, todos los tamaños se normalizaban.

La verdadera diferencia se hizo evidente al simular actividad de escritura. Al actualizar un 10% de las filas en todas las tablas, observamos que en la base de datos “normal”, el tamaño de los objetos se mantenía relativamente estable, con un ligero aumento en el índice no clúster de la columna actualizada. Esto es comprensible, ya que las filas modificadas podrían necesitar moverse a nuevas páginas para mantener el orden del índice. No obstante, en las bases de datos con ADR y/o RCSI habilitados, el tamaño de los objetos explotó, llegando casi a duplicarse tras la primera actualización. Al realizar más rondas de actualizaciones, la tendencia se mantuvo: mientras que la base de datos sin ADR crecía de forma gradual, las bases de datos con ADR y RCSI experimentaban un crecimiento mucho más rápido.

¿Por qué crecen las bases de datos con el versionado de filas?

El crecimiento del tamaño de las bases de datos al habilitar funcionalidades como ADR (Accelerated Database Recovery) y RCSI (Read Committed Snapshot Isolation) se debe al mecanismo de versionado de filas, que permite lecturas consistentes sin bloqueos. Sin embargo, aunque la ubicación del almacén de versiones sea la TempDB como con RCSI existe un overhead por fila que explica este aumento de tamaño.

Cuando ADR está habilitado

La Recuperación Acelerada de Bases de Datos utiliza un almacén de versiones persistente (PVS) que se encuentra dentro de la propia base de datos de usuario. Esto significa que las versiones anteriores de las filas modificadas se almacenan en el mismo archivo de datos (.mdf) de la base de datos. Como resultado directo, el tamaño de la base de datos en disco aumenta para albergar estas versiones.

Adicionalmente, cada fila de la tabla contendrá un puntero de 14 bytes que apunta a la ubicación de su versión en el PVS, incluso si la fila no ha sido modificada recientemente. Este overhead por fila es el principal causante del aumento del tamaño de la base de datos.

Cuando RCSI está habilitado (sin ADR)

Si la base de datos tiene habilitado el aislamiento por instantánea de lectura confirmada (RCSI) pero no la Recuperación Acelerada de Bases de Datos (ADR), el almacén de versiones se crea y se mantiene en la base de datos del sistema TempDB. Esto significa que las versiones de las filas modificadas en la base de datos de usuario se almacenan temporalmente en TempDB. Por lo tanto, podriamos pensar que la base de datos de usuario en sí misma debería no experimentar un aumento tan drástico debido al almacenamiento de las versiones, aunque TempDB sí crecerá para acomodar estas versiones.

Sin embargo, al igual que con ADR, cada fila de la tabla en la base de datos de usuario seguirá teniendo el puntero de 14 bytes que apunta al almacén de versiones, aunque en este caso, el almacén esté ubicado en TempDB. Este overhead por fila en la base de datos de usuario hace que el crecimiento que veamos en la tabla sea igual que en las que están en una base de datos con ADR.

Otras funcionalidades afectadas por el versionado de filas

Además de ADR y RCSI que, como acabamos de ver, usan un almacén de versiones, hay más funcionalidades de SQL que lo necesitan. En concreto, las más comunes son las bases de datos secundarias legibles en configuraciones Always On que emplean un almacén de versiones para ofrecer lecturas consistentes en la réplica secundaria.

Otra característica son las vistas indexadas que utilizan el versionado de filas para mantener la consistencia y los Triggers AFTER UPDATE que pueden depender del versionado de filas para acceder a los estados anteriores de las filas modificadas.

En resumen, el crecimiento de las bases de datos con el versionado de filas se debe tanto al almacenamiento de las versiones anteriores de las filas en sí (dentro de la base de datos con ADR, o en TempDB con RCSI) como al overhead de un puntero de 14 bytes añadido a cada fila en la base de datos de usuario para referenciar este almacén de versiones. Es crucial tener en cuenta estas implicaciones de almacenamiento al planificar la implementación de estas funcionalidades.

¿Reconstruir índices para ahorrar espacio? Una ilusión temporal

Ante este crecimiento acelerado de las tablas con ADR y RCSI, la reacción natural sería pensar en la reconstrucción de índices como una solución para recuperar el espacio «perdido». Y, efectivamente, al reconstruir los índices en estas tablas infladas, su tamaño volvía a los valores iniciales, dando la sensación de haber «ahorrado» espacio en disco.

Sin embargo, esta ganancia de espacio es puramente ilusoria y temporal. En cuanto la carga de trabajo habitual se reanudaba y se volvían a realizar actualizaciones, el tamaño de las tablas con ADR y RCSI volvía a inflarse rápidamente. Nos encontrábamos en un ciclo sin fin de crecimiento y reconstrucción, sin abordar la causa fundamental del aumento de tamaño.

La clave para entender esta dinámica reside en la forma en que ADR y RCSI gestionan el versionado de filas. Al mantener las versiones antiguas de las filas modificadas, es inevitable que el espacio ocupado por la tabla crezca con la actividad de escritura. La reconstrucción de índices simplemente reorganiza los datos y elimina las versiones antiguas que ya no son necesarias en el momento de la reconstrucción, pero no evita que se generen nuevas versiones con futuras modificaciones. Por lo tanto, si nuestro objetivo es «ahorrar» espacio mediante la reconstrucción de índices en un entorno con ADR o RCSI, debemos entender que este ahorro será efímero. El espacio «ahorrado» volverá a ser necesario a medida que se generen nuevas versiones de las filas.

¿Reconstruir índices como en 2005? Los tiempos cambian

Esta observación nos lleva a una reflexión importante sobre nuestras prácticas de mantenimiento. Si seguimos reconstruyendo índices como si estuviéramos en 2005, pensando que estamos logrando una mejora significativa en términos de espacio en disco y rendimiento, es hora de detenernos y reconsiderar nuestra estrategia. Las mejores prácticas evolucionan con los nuevos avances de la tecnología.

La evolución de las mejores prácticas nos indica que la obsesión por la utilización del espacio en disco a menudo nos lleva a tratar los síntomas, como la hinchazón de las tablas, en lugar de la causa subyacente, que en entornos con ADR y RCSI es el versionado de filas necesario para su funcionamiento. Reconstruir índices regularmente en estos entornos puede ser una solución ilusoria para el espacio , ya que el espacio ganado se volverá a utilizar rápidamente a medida que la carga de trabajo genere nuevas versiones de las filas.

Incluso podría ser contraproducente a largo plazo si se realiza sin una justificación real de mejora del rendimiento, especialmente considerando la menor penalización por fragmentación en unidades de estado sólido (SSD), que ofrecen tiempos de acceso aleatorio mucho más rápidos que los discos duros tradicionales (HDD). Además en entornos con almacenamiento virtualizado, la contigüidad física de los datos es aún menos común y tiene menos relevancia la fragmentación de los índices.

Casos donde la reconstrucción sí tiene sentido

Existen casos específicos donde la reconstrucción sí tiene sentido, pero son menos comunes. Por ejemplo, cuando se insertan inicialmente filas con muchos valores nulos que posteriormente se actualizan y ya no se modifican. En estos casos una reconstrucción podría compactar las páginas y liberar espacio que ya no es necesario. Sin embargo, en la mayoría de los escenarios con ADR o RCSI habilitados, si nuestro principal objetivo al reconstruir índices es ganar espacio en disco, las ganancias serán en gran medida temporales e insignificantes. Debemos enfocarnos en el problema real que estamos tratando de resolver: ¿es el espacio en disco o el rendimiento de las consultas? En muchos casos, ADR y RCSI están diseñados para mejorar la concurrencia y la disponibilidad, lo que podría reducir la necesidad de reconstrucciones de índices frecuentes con fines de rendimiento, especialmente en combinación con un hardware de almacenamiento adecuado.

Conclusión

Los experimentos que he realizado nos muestran claramente que la reconstrucción de índices en bases de datos con ADR y/o RCSI activados tiene un impacto diferente al que estábamos acostumbrados. Si bien inicialmente puede parecer que recuperamos espacio en disco, este ahorro es fugaz, ya que la propia naturaleza del versionado de filas hará que las tablas vuelvan a crecer con la actividad de escritura.

Es fundamental que nosotros, como profesionales de bases de datos, comprendamos a fondo cómo funcionan estas nuevas características y cómo impactan en nuestras tareas de mantenimiento. En lugar de seguir ciegamente las prácticas del pasado, debemos analizar el problema real que intentamos resolver. Si el aumento de tamaño de nuestras tablas es una consecuencia directa del versionado de filas necesario para ADR y RCSI, quizás la solución no sea reconstruir índices constantemente, sino dimensionar adecuadamente nuestro almacenamiento y enfocar nuestros esfuerzos en otras áreas de optimización.

En definitiva, la llegada de ADR y RCSI nos invita a replantearnos nuestras rutinas de mantenimiento de índices. Entender el mecanismo subyacente del versionado de filas es crucial para tomar decisiones informadas y evitar invertir tiempo y recursos en acciones que nos ofrecen solo una sensación temporal de mejora. La evolución de SQL Server nos exige una evolución en nuestra forma de gestionarlo.

Mar

2025

¿Por qué usar SSAS o Azure Analysis Services (AAS) en 2025?

Estamos viviendo la época dorada de los datos, la toma de decisiones basada en datos se ha convertido en un pilar fundamental para las organizaciones que buscan competitividad y eficiencia, por no hablar de la inteligencia artificial y el machine learning no serían nada sin datos. Esto ha llevado a una necesidad cada vez más creciente de datos, pero no datos de cualquier manera, la necesidad de herramientas que permitan el modelado y análisis avanzados es más crítica que nunca. En este sentido, SQL Server Analysis Services (SSAS) y Azure Analysis Services (AAS) continúan siendo soluciones clave para transformar datos en información estratégica.

En este artículo, quiero intentar responder a la pregunta ¿por qué SSAS y AAS siguen siendo relevantes en 2025? Para ello vamos a hablar de sus beneficios, y cuándo optar por una solución on-premises o en la nube.

La evolución del análisis de datos y la relevancia de SSAS/AAS

Con el crecimiento de plataformas de datos como Microsoft Fabric, Power BI y Synapse Analytics, es normal preguntarse si SSAS o AAS siguen siendo relevantes. La respuesta corta es sí, y la larga es que su uso ha evolucionado para adaptarse a nuevos escenarios.

SSAS y AAS siguen siendo las mejores soluciones para modelos de datos semánticos con alta reutilización y complejidad. Los modelos analíticos requieren rendimiento, escalabilidad, seguridad y gobernanza de primer nivel, y estas tecnologías lo ofrecen mejor que muchas alternativas.

Tendencias que refuerzan la importancia de SSAS y AAS:

La demanda de análisis de datos en tiempo real ha crecido significativamente, impulsando el uso de modelos híbridos que combinan almacenamiento en memoria con consultas en vivo a bases de datos. Al mismo tiempo, la necesidad de modelos escalables que puedan soportar miles de usuarios simultáneamente hace que soluciones como SSAS y AAS sean fundamentales para empresas de gran tamaño. Además, estas herramientas siguen desempeñando un papel clave en la integración con otras plataformas de Microsoft como Power BI, SQL Server, Synapse Analytics y Azure Data Lake, lo que refuerza su importancia en arquitecturas modernas de inteligencia empresarial.

Beneficios de SSAS y AAS

Uno de los principales motivos por los que SSAS y AAS siguen siendo relevantes es su capacidad para ofrecer un rendimiento excepcional en el análisis de datos. Gracias a la tecnología VertiPaq, los modelos tabulares permiten consultas rápidas mediante compresión y almacenamiento en memoria. Esto es crucial en un contexto donde los usuarios esperan tiempos de respuesta inmediatos en sus informes y dashboards.

Otro aspecto fundamental es la capacidad de manejar grandes volúmenes de información de manera eficiente. Los modelos en SSAS y AAS pueden procesar billones de filas sin comprometer el rendimiento, algo que sigue siendo una ventaja en comparación con otras soluciones. Aunque Power BI Premium y Fabric han mejorado en este aspecto, SSAS y AAS continúan siendo superiores para centralizar y administrar modelos de datos complejos que requieren alto rendimiento y reutilización en múltiples reportes.

La seguridad es otro factor determinante. Este 2025, la protección de datos debería ser una prioridad para todas las organizaciones. Tanto SSAS como AAS permiten la implementación de mecanismos avanzados de seguridad, como Row-Level Security (RLS) y Object-Level Security (OLS), lo que garantiza que cada usuario acceda únicamente a la información que le corresponde. Esta capacidad es especialmente valiosa en entornos empresariales donde la confidencialidad de los datos es crítica.

Por último, la integración con otras herramientas sigue siendo una de sus grandes ventajas. SSAS y AAS se conectan de manera nativa con Power BI, SQL Server, Azure Synapse Analytics y Data Factory, facilitando la creación de soluciones analíticas robustas y escalables. La posibilidad de definir modelos semánticos reutilizables permite a las empresas garantizar la consistencia de los datos en toda la organización, evitando la duplicación de esfuerzos y asegurando que todos los usuarios trabajen con la misma información consolidada.

¿SSAS o AAS? ¿On-premises o en la nube?

La elección entre SSAS (on-premises) y AAS (Azure) depende del contexto de cada empresa. Los factores clave siguen siendo coste, escalabilidad, mantenimiento y requisitos de seguridad.

¿Cuándo elegir SSAS?

Es cierto que la nube se está imponiendo como solución pero aún quedan casos donde puede ser recomendable una solución local como SSAS. Si la empresa sigue operando mayormente on-premises y no ha migrado a la nube o si tenemos licenciamiento de SQL Server con SSAS ya incluido SSAS puede ser mejor solución que AAS. Además, con esta solución tendremos el máximo control sobre la infraestructura y cumpliremos con los requisitos de esos escenarios con estrictos requisitos de seguridad que impiden almacenar datos en la nube ya sea por legislación o políticas de empresa. En este último caso podremos combinar SSAS con PBIRS todo el local.

¿Cuándo elegir AAS?

Por el contrario, si la empresa ya usa Azure y otros servicios en la nube o si necesitamos escalabilidad dinámica sin administrar servidores AAS es una solución que puede reducir costes en mantenimiento y licencias on-premises. Si usamos Power BI o Fabric en la nube también podremos aprovechar la integración nativa con AAS.

¿Y Microsoft Fabric? ¿Sustituye a AAS?

Microsoft Fabric ha introducido un nuevo paradigma con Power BI Semantic Models, que combina capacidades de SSAS/AAS con Power BI Premium. Sin embargo, AAS sigue siendo la mejor opción en entornos donde se requiere máxima flexibilidad y control sobre modelos semánticos.

Conclusión

A pesar de la evolución de las plataformas de datos en la nube, SSAS y AAS siguen siendo fundamentales en arquitecturas de BI modernas. Su capacidad para ofrecer modelos de datos centralizados, rendimiento óptimo y seguridad avanzada los mantiene como una opción relevante para empresas que buscan eficiencia en el análisis de datos.

Si la empresa opera on-premises, SSAS sigue siendo una opción válida. Por el contrario, si la estrategia es cloud-first, AAS ofrece flexibilidad y escalabilidad sin preocuparse por infraestructura. Si se usa Power BI, Microsoft Fabric puede ser una alternativa para simplificar la arquitectura, aunque AAS sigue siendo preferible en entornos empresariales grandes.

En resumen, SSAS y AAS continúan siendo pilares del análisis de datos en 2025, y su relevancia dependerá del contexto y la estrategia de cada organización. La clave está en aprovechar su potencia para construir soluciones analíticas de alto rendimiento, integradas con las últimas tecnologías de Microsoft.

Mar

2025

SQL Server Analysis Services (SSAS)

SQL Server Analysis Services (SSAS) es una de las tecnologías más robustas y flexibles para el análisis de datos en el ecosistema Microsoft. Desde su introducción en 1998 como OLAP Services (parte de SQL Server 7), ha evolucionado hasta convertirse en un pilar fundamental para la inteligencia empresarial (BI), proporcionando capacidades avanzadas para el modelado y la explotación de datos. En este artículo, os quiero introducir SSAS como herramienta, sus modelos, arquitectura y buenas prácticas para su implementación.

Introducción a SSAS

SSAS es una solución de Microsoft para la creación de modelos analíticos que permiten consultas optimizadas sobre grandes volúmenes de datos. Se integra con el ecosistema de SQL Server y herramientas como Power BI, Excel y otros clientes de BI. Su propósito es ofrecer un rendimiento excepcional en la consulta de datos y permitir cálculos complejos con una estructura optimizada.

Existen dos modos principales en los que SSAS puede operar el multidimensional y el tabular.

Modelos de SSAS: Multidimensional vs. Tabular

La elección entre los modelos multidimensional y tabular depende de diversos factores como el volumen de datos, la complejidad del análisis y la facilidad de uso.

Modelo Multidimensional (OLAP)

El clásico modelo analítico utiliza cubos y dimensiones para organizar la información de manera jerárquica. Se basa en la idea de organizar los datos en cubos OLAP (Online Analytical Processing), donde cada cubo representa un conjunto de datos preprocesados y optimizados para consultas analíticas rápidas. Estos cubos contienen medidas numéricas (como ventas o ingresos) y dimensiones (como tiempo, ubicación o producto), que permiten a los usuarios explorar la información desde múltiples perspectivas. Estos cubos pueden almacenarse como MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) o HOLAP (Hybrid OLAP). Gracias a esta arquitectura, las consultas se ejecutan con una latencia mínima, permitiendo análisis complejos como agregaciones, drill-downs y cálculos avanzados sin afectar el rendimiento de la base de datos transaccional. Por cierto, estas consultas son expresiones MDX (Multidimensional Expressions), que es el lenguaje de consulta optimizado para OLAP.

Como ventajas del Modelo Multidimensional podemos destacar su alto rendimiento en consultas agregadas preprocesadas y el soporte avanzado para modelado complejo de datos lo que lo hacen ideal para escenarios con jerarquías bien definidas.

Como desventajas del Modelo Multidimensional tenemos una curva de aprendizaje elevada debido a la necesidad de conocer MDX y una mayor complejidad en la administración y diseño de modelos que con otras alternativas.

Modelo Tabular (In-Memory)

Un modelo tabular en SQL Server Analysis Services (SSAS) es un enfoque más moderno para el análisis de datos que utiliza una arquitectura en memoria basada en el motor VertiPaq (si, igual que Power BI), optimizado para consultas de alto rendimiento. A diferencia del modelo multidimensional, el modelo tabular almacena los datos en formato columnar en lugar de estructuras de cubo preprocesadas, lo que permite una mayor comprensión y rapidez en las consultas. Se basa en tablas y relaciones, similar a un modelo relacional, y emplea el lenguaje DAX (Data Analysis Expressions) para la creación de cálculos y medidas. Su flexibilidad y facilidad de desarrollo lo han convertido en una alternativa popular al modelo multidimensional, ya que permite una integración más sencilla con herramientas de BI como Power BI y Excel, facilitando el análisis de datos sin la complejidad de los cubos OLAP tradicionales.

Como ventajas del Modelo Tabular destacaría su mayor facilidad de desarrollo en comparación con el modelo multidimensional (DAX es más sencillo que MDX), sus excelentes tiempos de respuesta debido a su estructura en memoria y su mejor integración con herramientas modernas como Power BI.

Por el contrario, las desventajas principales del Modelo Tabular son el consumo de memoria más elevado en modelos de gran tamaño y las limitaciones en la gestión de relaciones complejas en comparación con OLAP.

Arquitectura de SSAS

SSAS opera bajo una arquitectura de servidor que permite múltiples conexiones concurrentes de usuarios y herramientas de BI. La arquitectura básica que tenemos que tener clara antes de empezar incluye la o las fuentes de datos, es decir el origen de los datos (que puede ser de SQL Server, Azure SQL Database, Oracle, Teradata, entre otros) y el modelo de datos. Obviamente estos datos se van a introducir en un modelo de datos de SSAS mediante un cubo OLAP o un modelo tabular (en estrella a poder ser 🙂).

Una vez con esto definido llega la parte del modelado. En SSAS la información se procesa y se almacena en SSAS en formatos optimizados. En este punto igual hay que hacer algunas consultas a través de MDX (para OLAP) o DAX (para modelos tabulares) para terminar de pulir detalles antes de conectar nuestros clientes BI que serán herramientas como Power BI, Excel, Reporting Services y aplicaciones personalizadas consumen los modelos de SSAS.

Prácticas recomendadas en la implementación de SSAS

Al diseñar una solución con SSAS, es importante seguir ciertas recomendaciones para garantizar rendimiento y escalabilidad. Tenemos que tener en cuenta que estas aplicaciones analíticas van a almacenar y operar con gran cantidad de datos y por tanto definir un buen modelo de datos es fundamental. Tendremos que prestar especial atención para evitar redundancias y asegurar integridad referencial. En modelos tabulares, minimizar el uso de columnas de texto para optimizar la compresión.

A la hora de optimizar el rendimiento en OLAP utilizaremos agregaciones para reducir el tiempo de consulta mientras que en modelos tabulares, buscaremos reducir la cardinalidad de las columnas para mejorar la compresión. También podemos implementar particionamiento en modelos grandes para mejorar el procesamiento.

En cuanto a seguridad, podremos configurar roles y permisos en SSAS para restringir el acceso a datos sensibles. Si queremos ir más allá tenemos también Row-Level Security en modelos tabulares para aplicar filtros por usuario.

Y para cerrar este apartado, como no podía ser de otra manera, tenemos que hablar de la monitorización del uso de memoria y CPU sobre todo en entornos productivos.

SSAS en la Nube: Azure Analysis Services

Como ha pasado con otros servicios, Microsoft también ha llevado SSAS a la nube de Azure con Azure Analysis Services (AAS), ofreciendo las mismas capacidades de modelado de datos pero con las ventajas adicionales propias de Azure. Estas son la escalabilidad dinámica según la demanda de consultas, la integración con servicios de Azure como Azure SQL Database y Azure Synapse Analytics y el modelo de pago por uso sin necesidad de administrar infraestructura.

Para organizaciones que buscan reducir costes de mantenimiento y beneficiarse de la flexibilidad de la nube, Azure Analysis Services es una excelente opción.

Conclusión

SSAS sigue siendo una herramienta clave para arquitecturas de BI en empresas de todos los tamaños. Su capacidad para manejar grandes volúmenes de datos y realizar análisis avanzados lo convierte en una opción robusta tanto en entornos on-premises como en la nube. La elección entre modelo tabular o multidimensional dependerá de los requisitos del negocio y la facilidad de integración con otras herramientas.

Infra

Técnicas de Recuperación ante Desastres (DR) en Always On (AG)

Always On no evita el 100% de los desastres

Los backups si nos salvan ante desastres

AG distribuidos: la aspiración de los ya experimentados en desastres

Consideraciones adicionales: DR de verdad

Automatización: scripts o muerte

Conclusión

Crecimiento del Persistent Version Store (PVS) en SQL Server

¿Qué es el Persistent Version Store (PVS) de SQL Server y cómo funciona?

¿Cómo influye el PVS en el tamaño de nuestra base de datos?

El PVS y el mito de la reconstrucción de índices para ahorrar espacio

Estrategias efectivas para controlar el tamaño del PVS

Monitorizando el Persistent Version Store

Conclusión

La SQLCon llega a España

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes