Lo que se pierde al reiniciar: cuándo fiarte de las DMVs y cuándo no

Confiar ciegamente en las Dynamic Management Views (DMVs) de SQL Server sin conocer su ciclo de vida es uno de los errores más comunes en la consultoría de bases de datos. Muchos administradores y desarrolladores de BI ejecutan consultas de diagnóstico un lunes por la mañana, tras un mantenimiento de fin de semana, y concluyen erróneamente que el servidor está «sano» simplemente porque no ven consultas lentas o esperas significativas. La realidad es que el contador se ha puesto a cero.

Las DMVs no son un registro histórico persistente; son ventanas al estado actual de la memoria del proceso sqlserver.exe. En proyectos de retail o industria, donde los picos de carga ocurren en momentos muy específicos, basar una optimización en datos recolectados apenas dos horas después de un reinicio es una temeridad profesional. Si no hay historial, no hay contexto.

En este artículo desglosamos qué información es volátil, el impacto real de perder las estadísticas de ejecución y cómo puedes estructurar una estrategia de captura propia para que el próximo reinicio no te deje a ciegas.

La naturaleza efímera de las DMVs: ¿Qué vive en la RAM?

La mayoría de las DMVs que utilizamos para el tuning de rendimiento recolectan datos desde el momento en que se inicia el motor de base de datos. Esto incluye estadísticas de uso de índices, estadísticas de ejecución de procedimientos almacenados y contadores de espera (wait stats). Cuando el servicio se detiene, ya sea por una actualización del sistema operativo, un fallo de energía o un reinicio planificado, el espacio de memoria que contenía estos contadores se libera.

Esto genera un problema de «falso positivo» de rendimiento. Un servidor que lleva meses sin reiniciarse mostrará una imagen fiel de su carga de trabajo real. Un servidor recién reiniciado parecerá extremadamente eficiente, simplemente porque el plan cache está vacío y los contadores de sys.dm_os_wait_stats apenas han tenido tiempo de acumular milisegundos de fricción.

Antes de analizar cualquier métrica, lo primero que debes comprobar es cuánto tiempo lleva el motor encendido. Puedes hacerlo con esta consulta:

-- Comprobar el tiempo de actividad del servicio
SELECT 
 sqlserver_start_time AS [Fecha Inicio Servidor],
 DATEDIFF(hour, sqlserver_start_time, GETDATE()) AS [Horas Activo],
 DATEDIFF(day, sqlserver_start_time, GETDATE()) AS [Dias Activos]
FROM sys.dm_os_sys_info;

Si el servidor lleva menos de una semana encendido, los datos de las DMVs de uso de índices o de consultas pesadas deben tomarse con cautela. No representan el ciclo completo de negocio (cargas nocturnas, cierres mensuales, procesos de fin de semana).

¿Qué se pierde exactamente tras el reinicio?

No todas las vistas de sistema se comportan igual. Es fundamental distinguir entre las vistas de catálogo (que leen de tablas de sistema en disco) y las DMVs de rendimiento (que leen de estructuras en memoria). Para una correcta monitorización gratuita de SQL Server, debes saber que lo siguiente desaparece por completo:

• Estadísticas de ejecución: sys.dm_exec_query_stats, sys.dm_exec_procedure_stats y similares se limpian. Perderás el rastro de cuáles fueron tus 10 consultas más costosas del mes.
• Uso de índices: sys.dm_db_index_usage_stats se reinicia. Esto es crítico: si intentas identificar índices no utilizados para borrarlos y el servidor acaba de reiniciar, podrías borrar un índice vital que solo se usa en el cierre mensual.
• Wait Stats: sys.dm_os_wait_stats vuelve a cero. Pierdes la visibilidad sobre si tu cuello de botella histórico es el disco (PAGEIOLATCH), la CPU (SOS_SCHEDULER_YIELD) o los bloqueos.
• Plan Cache: Todos los planes de ejecución compilados se pierden. Esto provoca un pico de CPU inicial tras el reinicio mientras SQL Server vuelve a compilar las consultas entrantes.

En cambio, las vistas de catálogo como sys.tables, sys.indexes o sys.partitions son persistentes, ya que describen la estructura física y lógica de la base de datos, no su comportamiento dinámico.

Comparativa de volatilidad por tipo de vista

Como vemos en la tabla, el Query Store es la gran excepción. Introducido en SQL Server 2016, es la solución oficial al problema de la volatilidad. Si estás trabajando en escenarios modernos o incluso en un Mirroring de SQL Server en Fabric, asegúrate de tener Query Store activo para no depender exclusivamente de las DMVs en memoria.

Cómo crear un histórico de DMVs persistente

Si por razones de versión (SQL 2014 o inferior) o políticas internas no puedes usar Query Store, necesitas capturar instantáneas. En mis proyectos de consultoría, suelo implementar un proceso sencillo de «Staging de Rendimiento».

El objetivo es volcar el contenido de las DMVs críticas a una tabla física de una base de datos de administración (DBA_Admin) mediante un Job de SQL Agent. Aquí tienes un ejemplo de cómo capturar el uso de índices de forma persistente:

-- Crear tabla para persistencia de estadísticas de índices
IF OBJECT_ID('DBA_Admin.dbo.Historial_Uso_Indices') IS NULL
BEGIN
 SELECT 
 GETDATE() AS FechaCaptura,
 database_id, object_id, index_id, 
 user_seeks, user_scans, user_lookups, user_updates
 INTO DBA_Admin.dbo.Historial_Uso_Indices
 FROM sys.dm_db_index_usage_stats
 WHERE 1 = 0; -- Solo crear estructura
END

-- Insertar captura (ejecutar en un Job cada 24h)
INSERT INTO DBA_Admin.dbo.Historial_Uso_Indices
SELECT 
 GETDATE(),
 database_id, object_id, index_id, 
 user_seeks, user_scans, user_lookups, user_updates
FROM sys.dm_db_index_usage_stats
WHERE database_id = DB_ID('TuBaseDatosProduccion');

Con estos datos, puedes sumarizar los user_seeks a lo largo de los meses. Si tras un reinicio la DMV dice que un índice tiene 0 búsquedas, pero tu tabla histórica dice que tuvo 2 millones el mes pasado, sabrás que no debes borrarlo.

Errores frecuentes al interpretar DMVs

• Ignorar el tiempo de actividad: Mirar las esperas de bloqueo sin ver antes sys.dm_os_sys_info.
• Optimizar para el momento actual: Resolver un problema de CPU que solo aparece los lunes por la mañana porque es cuando se lanza el proceso de facturación, ignorando que el resto de la semana el servidor está ocioso.
• No considerar la limpieza manual: Recuerda que un DBA puede ejecutar DBCC FREEPROCCACHE o DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR). Esto resetea las DMVs sin reiniciar el servidor.
• Confundir lecturas lógicas con físicas: Tras un reinicio, las primeras consultas harán muchas lecturas físicas (disco) porque el Buffer Pool está vacío. Esto no significa que el disco sea lento, sino que la caché está fría.

Es vital que antes de realizar cambios estructurales, como añadir o quitar índices, sepas leer planes de ejecución en SQL Server para entender si el motor realmente está pidiendo esa ayuda o si es un espejismo de datos incompletos.

Estrategias de análisis en entornos modernos

En el ecosistema actual, donde realizamos pruebas de rendimiento en Fabric Warehouse o SQL Managed Instances, la persistencia de las métricas de rendimiento suele venir gestionada por la plataforma (Azure Monitor, Log Analytics). Sin embargo, la lógica subyacente es la misma.

Si detectas una consulta lenta, no te limites a mirar el total_worker_time acumulado en la DMV. Usa sys.dm_exec_query_plan para ver el plan actual y compáralo con el histórico si lo tienes. A veces, tras un reinicio, SQL Server elige un plan de ejecución subóptimo debido a una estimación de cardinalidad incorrecta, algo que ocurre con frecuencia cuando hay estimaciones con datos sesgados.

En esos casos, un reinicio puede ser el detonante de una degradación de rendimiento masiva (Plan Regression), ya que el plan «bueno» que estaba en caché ha desaparecido y el nuevo se genera con estadísticas desactualizadas.

Resumen y buenas prácticas

La monitorización de SQL Server es una carrera de fondo, no un sprint. Para que tu criterio de consultor sea sólido, sigue este checklist antes de proponer cambios basados en DMVs:

• Verifica siempre el sqlserver_start_time.
• Activa Query Store en todas las bases de datos de producción (a partir de SQL 2016).
• Implementa capturas manuales de sys.dm_db_index_usage_stats para decisiones de limpieza de índices.
• Usa herramientas externas o scripts de comunidad (como los de Brent Ozar o SQLskills) que manejan la persistencia por ti.
• No tomes decisiones críticas con menos de 48-72 horas de datos tras un reinicio.

Preguntas frecuentes

¿El comando DBCC SHRINKDATABASE reinicia las DMVs?

No, los comandos de mantenimiento de base de datos no resetean los contadores de las DMVs de rendimiento. Solo los comandos específicos de limpieza (como FREEPROCCACHE) o el reinicio del servicio afectan a estos datos.

¿Por qué han desaparecido mis missing indexes tras reiniciar?

La vista sys.dm_db_missing_index_details es puramente volátil. SQL Server identifica índices sugeridos a medida que analiza consultas. Si reinicias, el motor «olvida» esas sugerencias hasta que las consultas vuelvan a ejecutarse y se identifique de nuevo la carencia.

¿Es seguro usar Query Store en lugar de DMVs para todo?

Query Store es excelente para el rendimiento de consultas, pero no sustituye a DMVs de sistema como sys.dm_os_wait_stats o sys.dm_io_virtual_file_stats. Para un diagnóstico completo, necesitas ambas fuentes: Query Store para el historial de T-SQL y DMVs para el estado de salud del servidor.

¿Puedo forzar la persistencia de una DMV de forma nativa?

No existe un interruptor nativo para que sys.dm_exec_query_stats se guarde en disco al apagar el servicio. La única forma es mediante herramientas de terceros, Extended Events o scripts personalizados que vuelquen los datos a tablas físicas antes del apagado.

»
}