Solucionar problemas: Grupo de disponibilidad superado RPO

SQL Server 2012
 

Después de realizar una conmutación por error manual forzada de un grupo de disponibilidad a una réplica secundaria de confirmación asincrónica, es posible que la pérdida de datos es mayor que el objetivo de punto de recuperación (RPO). O bien, al calcular la posible pérdida de datos de una réplica secundaria de confirmación asincrónica mediante el método en Monitor de rendimiento para los grupos de disponibilidad AlwaysOn, encontrará que supera el RPO.

Una réplica secundaria de confirmación sincrónica garantiza la pérdida de datos, pero la posible pérdida de datos de una réplica secundaria de confirmación asincrónica depende de cuánto registro todavía está esperando a ser protegidos en la réplica secundaria.

Esta sección describe las causas comunes de alta posible pérdida de datos de una réplica secundaria de confirmación asincrónica. Se supone que no tiene un problema de rendimiento sistémico en la instancia del servidor que no está relacionado con grupos de disponibilidad AlwaysOn.

  1. Alta latencia de red o un rendimiento de red bajo produce acumulación del registro en la réplica principal

  2. Un cuello de botella de E/S de disco se ralentiza la protección de registro en la réplica secundaria

Alta latencia de red o un rendimiento de red bajo produce acumulación del registro en la réplica principal

La razón más común para las bases de datos que superen su RPO es que no se envían a la réplica secundaria lo suficientemente rápido.

Explicación

La réplica principal activa el control de flujo en el envío de registro cuando ha superado el número máximo permitido de mensajes no confirmados enviados a través de a la réplica secundaria. Hasta que hayan sido reconocidas algunos de estos mensajes, no hay más bloques de registro pueden enviarse a la réplica secundaria. Puesto que se puede evitar la pérdida de datos solo cuando se hayan protegido en la réplica secundaria, la acumulación de mensajes de registro sin enviar aumenta la posible pérdida de datos.

Diagnóstico y resolución

Puede indicar un gran número de mensajes reenviados a la réplica secundaria alta latencia de red y el ruido de la red. También puede comparar el valor DMV log_send_rate con el objeto de rendimiento Bytes de registro lisa/seg. Si los registros se están vaciando mucho más rápido que se envían en el disco, la posible pérdida de datos puede aumentar indefinidamente.

Además, resulta útil para comprobar los objetos de rendimiento de dos réplica de disponibilidad del servidor: SQL > tiempo de Control de flujo (ms/s) y réplica de disponibilidad del servidor: SQL > Control de flujo por segundo. Multiplicar estos dos valores se muestra en el último segundo cuánto tiempo espera de control de flujo borrar. Cuanto más tiempo el control de flujo tiempo de espera, menor será la velocidad de envío.

A continuación se muestra una lista de métricas útiles para diagnosticar el rendimiento y la latencia de red. Puede usar otras herramientas de Windows, como ping.exe, Monitor de recursos, y Monitor de red para evaluar el uso de la latencia y la red.

  • DMV sys.dm_hadr_database_replica_states, log_send_queue_size

  • DMV sys.dm_hadr_database_replica_states, log_send_rate

  • Contador de rendimiento SQL Server: base de datos > lisa Bytes de registro/seg.

  • Contador de rendimiento creación de reflejo de SQL Server: base de datos > hora de confirmación de enviar/recibir

  • Contador de rendimiento réplica de disponibilidad del servidor: SQL > Bytes enviados a réplica/seg.

  • Contador de rendimiento réplica de disponibilidad del servidor: SQL > Bytes enviados a transporte/seg.

  • Contador de rendimiento réplica de disponibilidad del servidor: SQL > tiempo de Control de flujo (ms/s)

  • Contador de rendimiento réplica de disponibilidad del servidor: SQL > Control de flujo/seg.

  • Contador de rendimiento réplica de disponibilidad del servidor: SQL > mensajes reenviados/s

Para solucionar este problema, intente actualizar el ancho de banda de red o el tráfico de red innecesario de reducción o eliminación.

Un cuello de botella de E/S de disco se ralentiza la protección de registro en la réplica secundaria

Dependiendo de la implementación del archivo de base de datos, la protección de registro puede originar una ralentización debido a la contención de E/S con cargas de trabajo de informes.

Explicación

Se evita la pérdida de datos tan pronto como el bloque de registro se grabe en el archivo de registro. Por lo tanto, es fundamental para aislar el archivo de registro del archivo de datos. Si el archivo de registro y el archivo de datos se asignan en el mismo disco duro, carga de trabajo con lecturas intensivas en el archivo de datos de informes utilizará los mismos recursos de E/S necesarios para el registro de protección de la operación. Protección de registro lento puede traducir a confirmación lenta a la réplica principal, lo que puede producir excesivo activación del control de flujo y tiempos de espera de control de flujo prolongado.

Diagnóstico y resolución

Si ha comprobado la red no presenta una alta latencia o un rendimiento bajo, a continuación, debería investigar la réplica secundaria para contenciones de E/S. Consultas de SQL Server: minimizar la E/S de disco son útiles para identificar la contención. Ejemplos de ese artículo se obtienen a continuación para su comodidad.

La siguiente secuencia de comandos le permite ver el número de lecturas y escrituras en cada archivo de datos y de registro para cada base de datos de disponibilidad que se ejecutan en una instancia de SQL Server. Se ordena por el tiempo de pausa promedio de E/S, en milisegundos. Tenga en cuenta que los números son acumulativos desde la última vez que se inició la instancia de servidor. Por lo tanto, debe tomar la diferencia entre dos mediciones después de que haya transcurrido algún tiempo.

SELECT DB_NAME(database_id) AS   
   [Database Name] ,   
   file_id ,   
   io_stall_read_ms ,   
   num_of_reads ,   
   CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,   
   io_stall_write_ms ,   
   num_of_writes ,  
   CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,   
   io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,   
   num_of_reads + num_of_writes AS [total_io] ,   
   CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads  
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]  
FROM sys.dm_io_virtual_file_stats(NULL, NULL)  
WHERE DB_NAME(database_id) IN (SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)  
ORDER BY avg_io_stall_ms DESC;  

La siguiente consulta proporciona una instantánea (no acumulativa) en el momento de solicitudes de E/S pendientes en el sistema.

SELECT DB_NAME(mf.database_id) AS [Database] ,   
   mf.physical_name ,  
   r.io_pending ,   
   r.io_pending_ms_ticks ,   
   r.io_type ,   
   fs.num_of_reads ,   
   fs.num_of_writes  
FROM sys.dm_io_pending_io_requests AS r   
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle   
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id  
AND fs.file_id = mf.file_id  
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;  

También puede comparar cómo la E/S de lectura y la E/S de escritura coincidan entre sí para identificar la contención de E/S.

A continuación o algunos contadores de rendimiento que pueden ayudarle a diagnosticar cuellos de botella de E/S:

  • Disco físico: todos los contadores

  • Disco físico: promedio Segundos de disco/transferencia

  • SQL Server: Las bases de datos > tiempo de espera de vaciado de registro

  • SQL Server: Las bases de datos > vaciado esperas registro/seg.

  • SQL Server: Las bases de datos > iniciar grupo lecturas de disco/seg.

Si se identifica un cuello de botella de E/S y coloque el archivo de registro y el archivo de datos en el mismo disco duro, lo primero que debe hacer es colocar el archivo de datos y el archivo de registro en discos independientes. Esta práctica recomendada impide reporting carga de trabajo de interferir con la ruta de transferencia de registros de la réplica principal para el búfer de registro y su capacidad para reforzar la transacción en la réplica secundaria.

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

Mostrar: