Soporte SQL Server para incidentes, performance y alta disponibilidad

Problema típico: réplicas que dejan de sincronizar o un failover que no ocurre cuando se necesita.

Síntomas: estados NOT SYNCHRONIZING, SUSPENDED o RESOLVING; send queue o redo queue crecientes; errores de endpoint o de seeding.

Riesgo: la réplica secundaria deja de ser una opción real de failover, exponiendo a la organización a pérdida de datos o de disponibilidad sin que sea evidente hasta el momento del fallo.

Cómo lo diagnosticamos: revisión de estado de sincronización, latencia entre réplicas, configuración de quorum y listener, y una prueba de conmutación controlada cuando es viable.

Qué recibes: estado real de cada réplica, RPO/RTO estimado con evidencia, y hallazgos priorizados para restablecer una alta disponibilidad confiable.

Es urgente cuando: el grupo de disponibilidad queda sin réplica sincronizada o el failover automático deja de funcionar.

Problema típico: el clúster está "arriba" pero no se sabe si un failover real funcionaría hoy.

Síntomas: eventos de clúster recurrentes, recursos que quedan en estado de advertencia, dependencias de red o disco poco claras.

Riesgo: un failover fallido durante una ventana de mantenimiento o una falla real puede convertir un evento planeado en una caída no planeada.

Cómo lo diagnosticamos: salud del quorum, discos y dependencias, revisión de eventos del clúster y validación de failover en ventana controlada.

Qué recibes: inventario de riesgos de configuración de nodos y un plan para probar el failover con impacto mínimo.

Es urgente cuando: un nodo queda inestable o el clúster reporta pérdida de quorum.

Problema típico: el secundario está más atrasado de lo que el negocio cree.

Síntomas: jobs de backup, copy o restore fallando; archivos faltantes; latencia creciente sin alerta.

Riesgo: al momento de activar el secundario, el RPO real puede ser mucho mayor al esperado.

Cómo lo diagnosticamos: revisión del monitor server, historial de los tres jobs, retención configurada y una prueba de continuidad de la cadena de restauración.

Qué recibes: latencia real medida, brechas en la cadena de log y procedimiento validado de activación del secundario.

Es urgente cuando: el job de restore lleva fallando varios ciclos consecutivos.

Problema típico: una base pasa a SUSPECT por error de I/O, corrupción o problema de log.

Síntomas: la base no abre, errores de acceso, alertas de almacenamiento previas al evento.

Riesgo: intervenciones apresuradas pueden aumentar la pérdida de datos. Priorizamos primero contener y preservar evidencia.

Cómo lo diagnosticamos: identificación de la causa raíz, revisión de backups disponibles y evaluación de la pérdida potencial antes de decidir la vía de recuperación.

Qué recibes: la restauración desde backup válido es siempre la primera opción evaluada. Opciones como EMERGENCY o REPAIR_ALLOW_DATA_LOSS se consideran último recurso, nunca como solución automática, y toda intervención queda documentada.

Es urgente cuando: una base productiva queda inaccesible. Esto se clasifica como P1.

Problema típico: errores 823, 824 u 825 en el log de SQL Server, o inconsistencias detectadas por monitoreo.

Síntomas: errores de I/O reportados por el motor, consultas que fallan sobre tablas específicas, alertas de almacenamiento.

Riesgo: la corrupción no revisada tiende a extenderse, y algunas reparaciones automáticas implican pérdida de datos irreversible.

Cómo lo diagnosticamos: DBCC CHECKDB con estrategia según el tamaño de la base (incluyendo PHYSICAL_ONLY cuando aplica), revisión del subsistema de almacenamiento y de la disponibilidad de backups.

Qué recibes: diagnóstico del alcance de la corrupción, prioridad de restauración desde backup sobre reparación, y validación posterior si se ejecuta una reparación como último recurso.

Es urgente cuando: aparecen errores 823/824/825 en un ambiente productivo.

Problema típico: tempdb como cuello de botella por contención, crecimiento descontrolado o presión del version store.

Síntomas: waits PAGELATCH, autogrowth frecuente, spills a disco en consultas con mucho ordenamiento o agregación.

Riesgo: tempdb afecta a toda la instancia, no solo a una base, por lo que un problema aquí puede degradar todo el servidor.

Cómo lo diagnosticamos: línea base de waits, número y tamaño de archivos, patrón de uso por sesión y el impacto de RCSI o snapshot isolation cuando están habilitados. No aplicamos reglas fijas como "un archivo por núcleo" sin validar la carga real.

Qué recibes: configuración recomendada de archivos y crecimiento, validada con evidencia antes y después del cambio.

Es urgente cuando: tempdb se queda sin espacio y detiene operaciones en toda la instancia.

Problema típico: una consulta que funcionaba bien empieza a usar un plan de ejecución más lento (regresión de plan) tras un cambio o actualización de estadísticas.

Síntomas: lentitud repentina sin cambios en el código de la consulta, planes inconsistentes entre ejecuciones.

Riesgo: sin Query Store habilitado, identificar cuándo y por qué cambió un plan es mucho más difícil de reconstruir después del hecho.

Cómo lo diagnosticamos: habilitación y revisión de captura, identificación de regresiones, y evaluación de forzar un plan solo cuando hay evidencia suficiente y validación posterior.

Qué recibes: reporte de regresiones detectadas y una estrategia de monitoreo continuo con límites de tamaño y limpieza configurados.

Es urgente cuando: una regresión de plan afecta un proceso crítico de negocio en producción.

Problema típico: necesidad de capturar deadlocks, bloqueos o consultas lentas sin el impacto de Profiler.

Síntomas: falta de visibilidad histórica sobre eventos intermitentes que ya no se pueden reproducir.

Riesgo: sin captura adecuada, cada incidente intermitente requiere esperar a que se repita para poder diagnosticarlo.

Cómo lo diagnosticamos: diseño de sesiones ligeras con filtros específicos (deadlocks, duración de consultas, recompilaciones, errores) y lectura de los archivos .xel generados.

Qué recibes: sesiones de captura sostenibles en producción, sin el overhead de las trazas clásicas.

Es urgente cuando: un problema intermitente no se puede reproducir bajo demanda.

Problema típico: existe un backup, pero nunca se probó una restauración real.

Síntomas: jobs de backup "exitosos" sin verificación, ausencia de pruebas de restore documentadas, recovery model inconsistente con el RPO esperado.

Riesgo: un backup no probado es una promesa, no una garantía. El momento de descubrir que falla no debería ser durante un incidente real.

Cómo lo diagnosticamos: revisión de la cadena full/differential/log, recovery model, checksum, cifrado, retención, y una prueba real de restauración en ambiente controlado.

Qué recibes: RPO y RTO medidos con evidencia (no estimados), y un runbook de recuperación validado.

Es urgente cuando: no existe certeza de que los backups actuales realmente restauran.

Problema típico: jobs de mantenimiento o backup que fallan silenciosamente sin que nadie se entere.

Síntomas: pasos fallidos sin alerta configurada, jobs huérfanos, dependencias entre jobs no documentadas.

Riesgo: un job crítico (backup, mantenimiento de índices, ETL) que falla sin notificación puede pasar desapercibido durante semanas.

Cómo lo diagnosticamos: revisión del historial, operadores y alertas configuradas, proxies y credenciales, y consistencia de los schedules con la ventana de mantenimiento real.

Qué recibes: inventario de jobs críticos con alertas correctamente configuradas y sin dependencias ocultas.

Es urgente cuando: un job de backup lleva fallando más de un ciclo sin alerta.

Problema típico: dudas sobre qué tan lista está una carga on-premise para moverse a Azure, o incidentes en una instancia ya migrada.

Síntomas: diferencias de comportamiento frente a SQL Server on-premise, dudas de compatibilidad, costos que no cuadran con lo esperado.

Riesgo: migrar sin evaluar readiness puede generar incompatibilidades funcionales o sobrecostos no anticipados.

Cómo lo diagnosticamos: evaluación de compatibilidad, elastic pools, alta disponibilidad administrada, conectividad y private endpoints, autenticación con Entra ID, y monitoreo con Azure Monitor / Log Analytics / Defender for SQL.

Qué recibes: evaluación de readiness para migración o diagnóstico de la instancia Azure ya existente, con limitaciones y costos identificados.

Es urgente cuando: una instancia Azure SQL productiva presenta errores de conectividad o degradación.

Problema típico: una versión heredada de SQL Server que ya no recibe soporte, o una migración detenida por miedo al riesgo.

Síntomas: features deprecados en uso, cardinality estimator antiguo, dependencias no documentadas (logins, jobs, linked servers).

Riesgo: una migración sin plan de pruebas y reversa puede introducir regresiones de performance o romper integraciones no documentadas.

Cómo lo diagnosticamos: evaluación de compatibilidad y features deprecados, inventario de logins, jobs, linked servers, certificados y claves, y definición de ventana, pruebas y rollback antes de ejecutar.

Qué recibes: plan de migración documentado con estrategia (in-place, side-by-side, backup/restore, Always On, o herramientas de Azure según el destino), ventana estimada y plan de reversa.

Es urgente cuando: la versión actual ya no recibe parches de seguridad.

Problema típico: cuentas con privilegios excesivos, superficie de ataque más amplia de la necesaria.

Síntomas: logins con sysadmin sin justificación clara, cuentas de servicio sobre-privilegiadas, backups sin cifrar.

Riesgo: cada acceso innecesario es una vía adicional de exposición ante un incidente de seguridad.

Cómo lo diagnosticamos: revisión de logins, roles y permisos, autenticación, cifrado (TLS, TDE), auditoría, estado de parches y superficie de configuración expuesta.

Qué recibes: hallazgos priorizados de seguridad con recomendación de mínimo privilegio y separación de funciones.

Es urgente cuando: se detecta una cuenta con privilegios excesivos activa y sin dueño identificado.

Problema típico: los problemas se descubren cuando el usuario reporta, no antes.

Síntomas: ausencia de alertas de capacidad, backups o Always On; sin tendencias históricas de CPU, memoria o I/O.

Riesgo: sin monitoreo proactivo, cada incidente empieza en desventaja: no hay línea base para comparar.

Cómo lo diagnosticamos: revisión de qué se monitorea hoy (disponibilidad, waits, espacio, tempdb, jobs, errores) y qué brechas existen frente a lo que realmente importa para el negocio.

Qué recibes: plan de monitoreo con alertas accionables y reportes ejecutivos y técnicos diferenciados.

Es urgente cuando: no existe ninguna alerta activa sobre espacio en disco o fallas de backup.

Problema típico: un incidente activo donde cada minuto de indecisión aumenta el impacto.

Nuestro proceso: triage y clasificación de severidad, estabilización priorizada sobre diagnóstico completo, recolección y preservación de evidencia antes de intervenir, comunicación del estado, y trabajo sobre la causa raíz una vez el servicio está estable.

Qué recibes: informe post-incidente con línea de tiempo, causa raíz, acciones ejecutadas, riesgos asumidos y acciones preventivas recomendadas.

Es urgente cuando: el servicio ya está afectando la operación. Ver la clasificación P1/P2/P3 más arriba.