Artículos prácticos sobre ClickHouse, SQL Server, arquitectura analítica, rendimiento, migración y operaciones de bases de datos.
Una guía práctica para detectar planes sensibles a parámetros en SQL Server, demostrar la causa y elegir la solución con menos riesgo.
Leer el artículoUn job puede indicar éxito aunque omita bases, no procese filas o termine demasiado tarde. El estado final no demuestra el resultado esperado.
Leer el artículoAmbas guardan filas intermedias, pero estadísticas, compilación, índices y transacciones pueden generar planes de ejecución muy distintos.
Leer el artículoLa compresión row y page reduce almacenamiento y E/S, pero añade CPU y no beneficia igual a todas las tablas. La decisión depende de datos y carga.
Leer el artículoEl particionamiento suele presentarse como una mejora automática. Sus mayores beneficios aparecen en ciclo de vida, ventana deslizante, archivo y límites de mantenimiento.
Leer el artículoEl SQL dinámico sirve para filtros opcionales y formas variables, pero concatenar texto introduce inyección, errores de comillas, mala reutilización de planes y diagnóstico difícil.
Leer el artículoFallos de almacenamiento, memoria, firmware o software pueden dañar páginas sin detener inmediatamente la aplicación. Las copias pueden conservar corrupción no detectada.
Leer el artículoLectores y escritores pueden bloquearse con read committed basado en bloqueos. RCSI usa versiones de fila para reducirlo, pero cambia recursos y concurrencia.
Leer el artículoUn índice no puede ayudar si el predicado oculta su columna dentro de una función o cálculo. SQL Server puede escanear todas las filas candidatas.
Leer el artículoCon tipos incompatibles, SQL Server puede convertir una columna indexada durante la ejecución. Esto provoca scans, malas estimaciones y CPU innecesaria.
Leer el artículoEl crecimiento inesperado puede llenar un volumen, ralentizar transacciones, retrasar réplicas y prolongar la recuperación. Reducir el archivo solo trata el síntoma.
Leer el artículoEl valor predeterminado de max server memory puede dejar sin memoria a Windows y otros servicios. Un valor bajo causa lecturas, compilaciones y presión de grants.
Leer el artículoLos valores predeterminados rara vez representan un diseño consciente. Demasiado paralelismo aumenta presión de CPU y workers; limitarlo demasiado frena consultas analíticas.
Leer el artículoUna larga lista de sesiones bloqueadas hace que todas parezcan culpables. Normalmente una transacción al principio de la cadena controla la duración y el impacto.
Leer el artículoUn job correcto demuestra que SQL Server escribió una copia. No demuestra que bases, claves, cadena de registros y dependencias puedan recuperarse a tiempo.
Leer el artículoUn grupo de disponibilidad puede mostrar réplicas sanas mientras los objetivos de recuperación siguen en riesgo. Colas, listener, copias y failover requieren supervisión explícita.
Leer el artículoEl optimizador elige joins, accesos y memoria según las filas estimadas. Cuando la estimación se aleja de la realidad, un plan razonable puede resultar muy caro.
Leer el artículoTempDB soporta ordenaciones, hashes, versiones de filas, objetos temporales, spills y tablas internas. Una mala configuración puede convertirla en un cuello de botella compartido.
Leer el artículoUn deadlock es un ciclo donde varias sesiones retienen recursos que otras necesitan. SQL Server finaliza una sesión, pero la víctima no siempre es la causa.
Leer el artículoMuchos incidentes terminan antes de capturar el plan. Query Store conserva consultas, planes, tiempos y esperas para analizarlos después.
Leer el artículoReconstruir todos los índices con un calendario fijo consume CPU, E/S, registro y tiempo de mantenimiento sin aportar necesariamente una mejora medible.
Leer el artículo