SQL Server Counters
UID:
sql_server_countersVersión: 1.3.1 Paneles: ~72
Propósito
Este dashboard permite revisar el estado global de las instancias de SQL Server, incluyendo aspectos críticos como:
- Tamaño de bases de datos y ficheros de log
- Uso de memoria y estado del buffer pool
- Contadores de rendimiento internos de SQL Server
- Page Life Expectancy y Buffer Cache Hit Ratio
- Métricas de I/O y latencia de disco
- Estado de alta disponibilidad (Availability Groups)
Variables
| Variable | Descripción |
|---|---|
$Instance | Instancia SQL Server a monitorizar |
Secciones
Instance Info
Información general de la instancia seleccionada, incluyendo tiempo de actividad, configuración de memoria y contadores clave.
Up Time stat
Tiempo transcurrido desde el último inicio de la instancia SQL Server.
Importancia: Un reinicio reciente puede indicar mantenimiento planificado, actualización de parches, o un problema inesperado como un crash o falta de memoria.
Umbrales:
| Valor | Color | Estado |
|---|---|---|
| < 1 día | Magenta | Revisar - reinicio reciente |
| >= 1 día | Verde | Normal |
Recomendación práctica
Tras un reinicio, SQL Server necesita tiempo para "calentar" su caché. El Buffer Cache Hit Ratio y PLE serán bajos inicialmente. Monitorice estos valores durante las primeras horas para asegurar que se estabilizan.
Max SQL Server Memory stat
Valor máximo de memoria que SQL Server puede utilizar (Target Server Memory).
Importancia: Según la documentación oficial de Microsoft, configurar correctamente la memoria máxima es crítico para evitar que SQL Server consuma toda la RAM del servidor, dejando sin recursos al sistema operativo.
Fórmula recomendada por Microsoft:
- Servidores dedicados: RAM Total - 4 GB (para el SO) - RAM para otros servicios
- Servidores con 16+ GB: Dejar 4 GB para los primeros 16 GB, más 1 GB por cada 8 GB adicionales
Buena práctica
Nunca dejar este valor en el predeterminado (2,147,483,647 MB). Un servidor con 32 GB de RAM debería tener Max Server Memory configurado aproximadamente en 26-28 GB.
Used SQL Server Memory stat
Cantidad de memoria que SQL Server está utilizando actualmente (Total Server Memory).
Importancia: La diferencia entre Target y Total Server Memory indica si SQL Server está bajo presión de memoria. Si Total es significativamente menor que Target, puede indicar que el sistema no tiene suficiente carga o que hay problemas de configuración.
Free Space in Tempdb stat
Espacio libre dentro de los ficheros de tempdb. Indica la diferencia entre el espacio asignado y el espacio utilizado por objetos.
Importancia: TempDB es utilizado por SQL Server para ordenaciones, hash joins, tablas temporales, versionado de filas (RCSI/Snapshot) y operaciones internas. Es una de las bases de datos más críticas para el rendimiento.
Umbrales:
| Valor | Color | Acción |
|---|---|---|
| < 512 MB | Rojo | Crítico - liberar espacio |
| 512 MB - 1 GB | Magenta | Revisar |
| > 1 GB | Verde | Normal |
Mejores prácticas para TempDB (Microsoft)
Según las recomendaciones de Microsoft:
- Múltiples archivos de datos: Crear un archivo por cada core lógico (hasta 8 archivos)
- Tamaño igual: Todos los archivos deben tener el mismo tamaño inicial y crecimiento
- Disco dedicado: Ubicar TempDB en discos rápidos (SSD/NVMe) separados de los datos de usuario
- Pre-dimensionar: Configurar un tamaño inicial adecuado para evitar autocrecimientos frecuentes
Page Life Expectancy (PLE) stat
Tiempo en segundos que una página de datos permanece en el buffer pool antes de ser descartada. Es el indicador más importante de presión de memoria en SQL Server.
Importancia: El PLE es uno de los contadores más críticos según la documentación de Microsoft sobre Buffer Manager. Un PLE bajo significa que las páginas se expulsan rápidamente del buffer pool, forzando lecturas constantes desde disco.
Interpretación:
| Valor | Estado | Acción |
|---|---|---|
| < 300 seg | Rojo - Crítico | Investigar inmediatamente |
| 300 - 1000 seg | Magenta - Revisar | Monitorizar tendencia |
| 1000 - 3000 seg | Amarillo | Aceptable pero mejorable |
| > 3000 seg | Verde - Normal | Sistema saludable |
Causas comunes de PLE bajo
- Memoria insuficiente: Max Server Memory configurado muy bajo
- Table scans: Queries que escanean tablas completas en lugar de usar índices
- Índices faltantes: Falta de índices apropiados para las queries ejecutadas
- Queries con resultados grandes: SELECT * de tablas grandes sin filtros
- Carga de trabajo pico: Aumento temporal de actividad
Recomendación práctica
Fórmula moderna para PLE: Microsoft ya no recomienda un valor fijo de 300. La fórmula actualizada es:
PLE mínimo = (Max Server Memory en GB / 4) × 300Ejemplo: Servidor con 64 GB → PLE mínimo = (64/4) × 300 = 4,800 segundos
Acciones de remediación:
- Revisar queries con alto logical reads usando
sys.dm_exec_query_stats - Identificar índices faltantes con
sys.dm_db_missing_index_details - Evaluar incrementar Max Server Memory
- Analizar si hay table scans innecesarios
Buffer Cache Hit Ratio stat
Porcentaje de páginas de datos encontradas en memoria caché sin necesidad de leer desde disco.
Importancia: Este contador mide la eficiencia del buffer pool. Según Microsoft, un valor alto indica que la mayoría de las solicitudes de datos se satisfacen desde memoria.
Interpretación:
| Valor | Estado | Acción |
|---|---|---|
| < 95% | Rojo | Crítico - problema serio de memoria |
| 95% - 98% | Magenta | Revisar configuración de memoria |
| 98% - 99% | Amarillo | Aceptable |
| > 99% | Verde | Óptimo |
Nota importante
Para sistemas OLTP, este valor debería estar siempre por encima del 99%. Valores más bajos son aceptables solo para:
- Sistemas de Data Warehouse con queries ad-hoc
- Inmediatamente después de un reinicio (período de calentamiento)
- Cargas de trabajo que leen datos históricos raramente accedidos
Diferencia entre PLE y Buffer Cache Hit Ratio:
- Buffer Cache Hit Ratio: Mide el porcentaje de aciertos (instantáneo)
- PLE: Mide cuánto tiempo permanecen las páginas (estabilidad)
Un sistema puede tener buen Hit Ratio pero mal PLE si las páginas se están rotando constantemente.
Backup/Restore Throughput stat
Velocidad de operaciones de backup y restore en bytes por segundo.
Importancia: Permite evaluar si los backups están operando a velocidad óptima o si hay cuellos de botella de I/O.
Optimización de backups
Para mejorar el throughput de backups:
- Usar backup compression (reducción típica del 60-80%)
- Realizar backups a múltiples archivos en paralelo
- Configurar BUFFERCOUNT y MAXTRANSFERSIZE apropiados
- Usar almacenamiento rápido para destino de backups
CPU Count stat
Número de núcleos de CPU disponibles para SQL Server.
Importancia: Este valor afecta directamente la configuración de MAXDOP y el licenciamiento. SQL Server Standard Edition está limitado a 24 cores.
Memory Grants Pending stat
Número de procesos esperando que se les asigne memoria de workspace para ejecutar operaciones.
Importancia: Según Microsoft, este contador indica si hay queries esperando memoria para realizar ordenaciones, hash joins u otras operaciones que requieren workspace memory.
Interpretación:
| Valor | Estado | Acción |
|---|---|---|
| 0 | Verde | Normal - no hay esperas |
| 1-5 | Magenta | Revisar queries con memory grants altos |
| > 5 | Rojo | Crítico - investigar inmediatamente |
Impacto de Memory Grants Pending > 0
Cuando hay queries esperando memory grants:
- Las queries se encolan y esperan, aumentando la latencia
- El rendimiento general del sistema se degrada
- Los usuarios experimentan timeouts
El valor debe ser SIEMPRE cero en un sistema saludable.
Acciones de remediación:
- Identificar queries con memory grants excesivos usando
sys.dm_exec_query_memory_grants - Revisar queries con estimaciones de cardinalidad incorrectas
- Actualizar estadísticas con
UPDATE STATISTICS - Considerar Resource Governor para limitar memory grants por query
Active Temp Tables stat
Número de tablas temporales (#temp) existentes actualmente en el servidor.
Importancia: Un número muy alto puede indicar que las aplicaciones están creando muchas tablas temporales sin liberarlas, o que hay sesiones de larga duración acumulando objetos temporales.
Version Store Size stat
Tamaño del almacén de versiones en TempDB utilizado para Snapshot Isolation y RCSI.
Importancia: El Version Store es usado por:
- Read Committed Snapshot Isolation (RCSI): Permite lecturas consistentes sin bloqueos
- Snapshot Isolation: Aislamiento a nivel de transacción
- Online Index Operations: Reconstrucción de índices sin bloquear lecturas
- Always On Readable Secondaries: Lecturas en réplicas secundarias
Según Microsoft
Un Version Store muy grande puede indicar:
- Transacciones de larga duración que mantienen versiones antiguas
- Alta carga de escrituras con RCSI habilitado
- Queries de larga duración en réplicas secundarias de Always On
Monitorizar con: sys.dm_tran_version_store_space_usage
Checkpoint pages/sec stat
Páginas modificadas (dirty pages) escritas a disco durante operaciones de checkpoint.
Importancia: Los checkpoints escriben páginas modificadas del buffer pool al disco para garantizar la durabilidad de las transacciones. Un valor muy alto sostenido puede indicar:
- Alta carga de escrituras
- Checkpoints muy frecuentes
- Posible cuello de botella de I/O
Indirect Checkpoints (SQL Server 2016+)
Microsoft recomienda usar Indirect Checkpoints con TARGET_RECOVERY_TIME configurado a 60 segundos. Esto proporciona tiempos de recuperación más predecibles y reduce los picos de I/O.
Page lookups/sec stat
Número de solicitudes por segundo para localizar una página en el buffer pool.
Importancia: Indica el nivel de actividad de lectura lógica. Valores muy altos pueden indicar queries ineficientes que leen muchas páginas.
Average User Connections stat
Promedio de conexiones de usuario simultáneas. SQL Server soporta un máximo de 32,767 conexiones.
Umbrales:
| Valor | Estado | Acción |
|---|---|---|
| < 25,000 | Verde | Normal |
| >= 25,000 | Magenta | Revisar - cercano al límite |
Connection Pooling
Un número muy alto de conexiones puede indicar problemas de connection pooling en las aplicaciones. Cada conexión consume memoria (~1.5 MB por conexión). Verificar:
- Que las aplicaciones usen connection pooling
- Que las conexiones se cierren correctamente
- Que no haya conexiones huérfanas
Databases Info
Estado y salud de las bases de datos en la instancia.
Databases Health stat
Indicador agregado de salud. Suma de bases de datos en estados problemáticos.
Interpretación:
| Valor | Texto | Estado |
|---|---|---|
| 0 | HEALTHY | Verde - todas las bases de datos operativas |
| >= 1 | NOT HEALTHY | Magenta - investigar inmediatamente |
Estados de Base de Datos stat
Contadores individuales por estado de base de datos.
Estados de base de datos según Microsoft:
| Estado | Descripción | Acción |
|---|---|---|
| ONLINE | Base de datos accesible | Estado normal |
| OFFLINE | Desconectada manualmente | Verificar si es intencional |
| SUSPECT | Posible corrupción detectada | Ejecutar DBCC CHECKDB, restaurar si es necesario |
| RECOVERING | En proceso de recuperación | Esperar a que termine |
| PENDING | Error de recursos durante recovery | Revisar logs de errores |
| RESTORING | Restauración en progreso | Estado transitorio normal |
Estado SUSPECT
Una base de datos SUSPECT indica que el filegroup primario puede estar dañado. Acciones inmediatas:
- Revisar el SQL Server Error Log
- Ejecutar
DBCC CHECKDB('database_name') WITH NO_INFOMSGS - Si hay corrupción, evaluar opciones de reparación o restauración
- Nunca usar
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSSsin entender las consecuencias
Database Size
Visualización del tamaño de bases de datos individuales y evolución temporal.
Data File Size / Log File Size piechart
Distribución visual del tamaño de archivos de datos y log por base de datos.
Buenas prácticas de gestión de archivos
- Pre-dimensionar archivos: Evitar autocrecimientos frecuentes
- Crecimiento en MB, no en %: Usar incrementos fijos (512 MB - 1 GB)
- Separar data y log: Ubicar en discos diferentes si es posible
- Monitorizar crecimiento: Detectar crecimientos anormales temprano
Performance Counters
Gráficos de evolución temporal de los principales contadores de rendimiento.
SQL Stats timeseries
Métricas de actividad SQL: batch requests, compilaciones, logins y bloqueos.
Métricas incluidas y su significado:
| Métrica | Descripción | Valor ideal |
|---|---|---|
| Batch Requests/sec | Número de lotes SQL recibidos | Depende de la carga |
| SQL Compilations/sec | Nuevos planes de ejecución creados | < 10% de Batch Requests |
| SQL Re-Compilations/sec | Planes recompilados | < 1% de Compilations |
| Processes blocked | Procesos esperando locks | 0 |
Ratio de Compilaciones
Si SQL Compilations/sec es alto respecto a Batch Requests/sec, indica que los planes no se están reutilizando. Causas comunes:
- Queries ad-hoc sin parametrización
- Uso excesivo de SQL dinámico
OPTION (RECOMPILE)innecesario- Estadísticas desactualizadas
Solución: Habilitar "Optimize for Ad Hoc Workloads" y parametrizar queries.
Access Methods timeseries
Contadores que muestran cómo SQL Server accede a los datos: scans, seeks, lookups.
Métricas clave de Access Methods:
| Métrica | Significado | Objetivo |
|---|---|---|
| Index Searches/sec | Operaciones de búsqueda por índice (seeks) | Alto = bueno |
| Full Scans/sec | Escaneos completos de tabla/índice | Bajo = bueno |
| Range Scans/sec | Escaneos de rango en índices | Depende |
| Page Splits/sec | Divisiones de página por inserciones | Bajo = bueno |
Ratio Scans vs Seeks
Un ratio alto de Full Scans/sec respecto a Index Searches/sec indica posibles índices faltantes o queries mal optimizadas. Investigar con el DMV sys.dm_db_missing_index_details.
Guía de Interpretación
Indicadores Críticos
| Métrica | Valor Crítico | Impacto | Acción Recomendada |
|---|---|---|---|
| Page Life Expectancy | < 300 seg | Rendimiento degradado | Aumentar memoria, optimizar queries |
| Buffer Cache Hit Ratio | < 95% | Lecturas excesivas a disco | Aumentar RAM, revisar índices |
| Memory Grants Pending | > 0 | Queries en cola | Actualizar estadísticas, revisar queries |
| Databases SUSPECT | >= 1 | Posible pérdida de datos | DBCC CHECKDB, restaurar si necesario |
Correlación de Métricas
Para diagnosticar problemas de rendimiento, correlacione estas métricas:
| Síntoma | Métricas a revisar | Causa probable |
|---|---|---|
| Queries lentas | PLE, Buffer Cache, Memory Grants | Presión de memoria |
| Timeouts | Processes Blocked, User Connections | Bloqueos o límite de conexiones |
| I/O alto | Checkpoint pages/sec, Full Scans/sec | Índices faltantes o checkpoints |
| CPU alto | Batch Requests, Compilations | Alta carga o recompilaciones |
Frecuencia de Revisión
| Tarea | Frecuencia | Herramienta |
|---|---|---|
| Revisar PLE y Buffer Cache | Diario | Este dashboard |
| Verificar estado de bases de datos | Diario | Este dashboard |
| Analizar tendencias de crecimiento | Semanal | Database Growth dashboard |
| Revisar Memory Grants y bloqueos | Semanal | Process Status dashboard |
| Auditoría completa de rendimiento | Mensual | Todos los dashboards |
Referencias de Microsoft
| Tema | Enlace | |------|--------|6 | Buffer Manager Object | learn.microsoft.com | | Memory Manager Object | learn.microsoft.com | | Server Memory Options | learn.microsoft.com | | TempDB Best Practices | learn.microsoft.com | | Database States | learn.microsoft.com | | Database Checkpoints | learn.microsoft.com |
Stored Procedures Utilizados
Este dashboard utiliza procedimientos almacenados del esquema [Counters]:
| Procedimiento | Descripción |
|---|---|
spUpTimeDatabase | Calcula el tiempo de actividad |
spLastPerformanceCounters | Obtiene el último valor de un contador |
spAVGPerformanceCountersGroupByInterval | Promedio de contadores agrupado por intervalo |
spMaxPerformanceCountersGroupByInterval | Máximo de contadores agrupado por intervalo |
Vistas Utilizadas
| Vista | Descripción |
|---|---|
[Counters].[vwDatabaseStatus] | Estado de las bases de datos por servidor |