Solucionar problemas: Grupo de disponibilidad superado RTO

SQL Server 2012
 

Después de una conmutación por error automática o planeada manual sin pérdida de datos en un grupo de disponibilidad, es posible que el tiempo de conmutación por error supera su objetivo de tiempo de recuperación (RTO). O bien, al calcular el tiempo de conmutación por error de una réplica secundaria de confirmación sincrónica (por ejemplo, un asociado de conmutación por error automática) utilizando el método en Monitor de rendimiento para los grupos de disponibilidad AlwaysOn, encontrará que supera el RTO.

Si la conmutación por error automática aún no se ha completado, consulte solución de problemas de conmutación por error automática en entornos de SQL Server 2012 AlwaysOn.

Esta sección describe las causas comunes de una conmutación por error de tiempo que supera el RTO.

  1. Informes de carga de trabajo bloquea el subproceso de puesta al día de ejecución

  2. Rehacer subproceso se encuentra detrás de debido a la contención de recursos

Informes de carga de trabajo bloquea el subproceso de puesta al día de ejecución

Se bloquea el subproceso de puesta al día en la réplica secundaria de realizar cambios DDL (lenguaje) de definición de datos por una consulta de solo lectura de ejecución prolongada.

Explicación

En la réplica secundaria, las consultas de solo lectura adquieren bloqueos de estabilidad (Sch-S) de esquema. Estos bloqueos Sch-S pueden bloquear el subproceso de puesta al día de adquirir bloqueos de modificación (Sch-M) de esquema para realizar cualquier cambio DDL. Un subproceso de rehacer bloqueadas no puede aplicar entradas del registro hasta que se desbloquea. Una vez desbloqueado, puede continuar para ponerse al día hasta el final del registro y permitir que el proceso de conmutación por error para continuar y deshacer posterior.

Diagnóstico y resolución

Cuando se bloquea el subproceso de puesta al día, llama a un evento extendido sqlserver.lock_redo_blocked se genera. Además, puede consultar el sys.dm_exec_request DMV en la réplica secundaria para averiguar qué sesión está bloqueando el subproceso de puesta al día, y, a continuación, puede realizar una acción correctora. La siguiente consulta devuelve el identificador de sesión de la consulta de solo lectura que está bloqueando el subproceso de puesta al día.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'  

Se puede permitir que la carga de trabajo informe a fin, en qué momento se desbloquea el subproceso de puesta al día. Puede desbloquear el subproceso de puesta al día inmediatamente mediante la ejecución de la KILL ( Transact-SQL ) comando en el identificador de sesión bloqueo.

Rehacer subproceso se encuentra detrás de debido a la contención de recursos

Una gran carga de trabajo informe en la réplica secundaria se ralentice el rendimiento de la réplica secundaria, y el subproceso de puesta al día se ha retrasado.

Explicación

Al aplicar los registros en la réplica secundaria, el subproceso de puesta al día lee las entradas del registro desde el disco de registro y, a continuación, para cada entrada del registro tiene acceso a las páginas de datos para aplicar la entrada del registro. El acceso a la página puede ser enlazadas a E/S (acceso al disco físico) si la página no está ya en el grupo de búferes. Si no hay que e/s enlaza la carga de trabajo informe, la carga de trabajo informe compite por los recursos de E/S con el subproceso de puesta al día y puede ralentizar el subproceso de puesta al día.

Diagnóstico y resolución

Puede usar la siguiente consulta DMV para ver hasta qué punto el subproceso de puesta al día se ha retrasado, mediante la medición de la diferencia entre la brecha entre last_redone_lsn y last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states  
  

Si el subproceso de puesta al día realmente se retrasa, debe investigar la causa raíz de la degradación del rendimiento en la réplica secundaria. Si se produce una contención de E/S con la carga de trabajo informe, puede usar regulador de recursos al control de CPU ciclos que se usan indirectamente mediante la carga de trabajo informe para controlan los ciclos de E/S realizados hasta cierto punto. Por ejemplo, si la carga de trabajo informes está consumiendo el 10 por ciento de la CPU, pero la carga de trabajo es enlazadas a E/S, puede utilizar el regulador de recursos para limitar el uso de recursos de CPU en un 5 por ciento para cargas de trabajo lectura acelerador, lo que reduce el impacto de e/s.

Solucionar problemas de rendimiento en SQL Server (se aplica a SQL Server 2012)

Mostrar: