Artículos técnicos sobre SQL Server, Data Engineering, IA y automatización.13 artículos publicados
Snapshots delta de dm_io_virtual_file_stats, interpretación de PAGEIOLATCH, HADR_SYNC_COMMIT y WRITELOG, y umbrales de referencia para storage empresarial. Una guía práctica para diferenciar entre fallo de cabina y simple sobrecarga.
Un SELECT compilado con parámetros de un dominio pequeño se ejecutó contra el dominio principal con millones de filas, causando 104 millones de lecturas y un bloqueo de 5 minutos que afectó a 200.000 INSERTs por hora.
Un CROSS APPLY TOP 1 sobre una tabla de mil millones de filas pasó de 16 minutos a 24 horas por un índice que no cubría la columna ORDER BY. El plan forzado de Query Store fue ignorado silenciosamente.
Una función escalar con un bucle WHILE que limpia caracteres especiales forzó DOP=1, consumió 84 GB de memoria y bloqueó el Resource Governor durante 11 horas. Diagnóstico y solución con inline TVF.
Cómo el patrón NOT IN sobre una tabla de 190 millones de filas sin índice adecuado convirtió una consulta simple en el mayor consumidor de I/O de toda la base de datos. Diagnóstico con Query Store y solución definitiva.
Recibe nuevos artículos sobre SQL Server, automatización e IA directamente en tu bandeja de entrada. Sin spam, solo contenido técnico de valor.
Contactar para suscribirmeUn INDEX REORGANIZE sin TimeLimit sobre tablas con carga CDC continua produce deadlocks que paran la replicación. Job de 17 horas, latencia acumulada en cabecera. Por qué INDEX_REBUILD_ONLINE puede ser más sano que REORGANIZE.
Reiniciar un nodo AlwaysOn con snapshots activos deja la BD fuente atrapada en estado Not Recovering. El Error 5094 no apunta directamente al snapshot — y el AG no sincroniza hasta que lo eliminas. Cómo detectarlo antes del reinicio.
Tablas con más de 300 millones de filas y auto-stats síncronas pueden bloquear la compilación de stored procedures durante más de una hora, con grants de memoria de 100 GB. Cómo detectarlo y por qué AUTO_UPDATE_STATISTICS_ASYNC es obligatorio en data warehouses.
Force Plan en Query Store puede dejar de aplicarse sin marcarlo en force_failure_count. Tu plan figura como forzado, el contador a cero, pero el optimizador está usando otro plan. Cómo detectarlo y por qué nunca debe ser tu solución definitiva.
Un INSERT masivo en una sola transacción llenó un log de 293 GB y dejó la BD bloqueada: ni siquiera ALTER DATABASE para ampliar el log funcionaba. El motivo y la lección aprendida sobre batches y COMMIT intermedio.
Un borrado por lotes de 23 millones de registros dejó 6 estadísticas con un 83% de modificaciones sin reflejar. Al día siguiente aparecieron deadlocks en producción. Análisis completo del patrón DELETE vs UPDATE, el comportamiento del auto-update de estadísticas y cómo evitarlo.
Revisión proactiva en un servidor SQL Server 2019 AlwaysOn de producción que reveló un PLE de 22 segundos (el mínimo recomendado es 300), latencias de disco de 35ms y tres volúmenes por debajo del 12%. Guía completa del checklist DBA para detectar estas crisis antes de que exploten.
Caso real en un servidor SQL Server 2019 de Data Warehouse donde un plan forzado incorrecto multiplicó el tiempo de ejecución de 10 minutos a 26 horas y generó 12.000 millones de lecturas lógicas. Diagnóstico completo, causa raíz y resolución paso a paso.