Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:
SQL Server
Después de efectuar 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 supere 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 descrito en Monitor Performance for Always On Availability Groups, comprueba que supera su RPO.
Una réplica secundaria de confirmación sincrónica garantiza que no se pierdan datos, pero la pérdida de datos potencial de una réplica secundaria de confirmación asincrónica depende de la cantidad de registro que todavía está esperando a ser protegido en la réplica secundaria.
En las siguientes secciones se describen las causas más probables de una gran pérdida de datos en una réplica secundaria de confirmación asincrónica, suponiendo que no tenga ningún problema de rendimiento sistémico en la instancia del servidor que no esté relacionado con los grupos de disponibilidad.
Un cuello de botella de E/S de disco ralentiza la confirmación del registro en la réplica secundaria
La alta latencia de red o el bajo rendimiento de red producen una acumulación de registros en la réplica principal
La causa que provoca con más frecuencia que las bases de datos superen su RPO es que no se pueden enviar lo suficientemente rápido a la réplica secundaria.
Explicación
La réplica principal activa el control de flujo en el envío del registro de transacciones cuando supera el número máximo permitido de mensajes no confirmados enviados a la réplica secundaria. Hasta que no se acepten algunos de estos mensajes, no se podrán enviar más bloques de registro a la réplica secundaria. Puesto que la pérdida de datos solo se puede evitar cuando se protegen 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
El reenvío de un gran número de mensajes a la réplica secundaria puede indicar una alta latencia y ruido en la red. También puede comparar el valor DMV log_send_rate con el objeto de rendimiento Log Bytes Flushed/sec. Si los logs se vacían en disco más rápido de lo que se envían, la posible pérdida de datos puede aumentar indefinidamente.
Además, resulta útil para comprobar los dos objetos de rendimiento: SQL Server:Availability Replica > Flow Control Time (ms/sec) y SQL Server:Availability Replica > Flow Control/sec. Al multiplicar estos dos valores, se muestra cuánto tiempo se pasó esperando, durante el último segundo, a que se liberara el control de flujo. Cuanto mayor sea el tiempo de espera del control de flujo, menor será la tasa de envío.
Las siguientes métricas son útiles para diagnosticar el rendimiento y la latencia de red. Puede usar otras herramientas de Windows, como ping.exe y Monitor de red para evaluar el uso de la latencia y la red.
DMV
sys.dm_hadr_database_replica_states, log_send_queue_sizeDMV
sys.dm_hadr_database_replica_states, log_send_rateContador de rendimiento
SQL Server:Database > Log Bytes Flushed/secContador de rendimiento
SQL Server:Database Mirroring > Send/Receive Ack TimeContador de rendimiento
SQL Server:Availability Replica > Bytes Sent to Replica/secContador de rendimiento
SQL Server:Availability Replica > Bytes Sent to Transport/secContador de rendimiento
SQL Server:Availability Replica > Flow Control Time (ms/sec)Contador de rendimiento
SQL Server:Availability Replica > Flow Control/secContador de rendimiento
SQL Server:Availability Replica > Resent Messages/sec
Para solucionar este problema, intente actualizar el ancho de banda de red o eliminar o reducir el tráfico de red innecesario.
Un cuello de botella de E/S de disco ralentiza el refuerzo en la réplica secundaria
Según cómo esté implementado el archivo de base de datos, el endurecimiento del registro puede ralentizarse por la contención de E/S con la carga de trabajo de generación de informes.
Explicación
La pérdida de datos se evita tan pronto como el bloque de registro se consolida en el archivo de registro. Por lo tanto, es fundamental aislar el archivo de registro del archivo de datos. Si el archivo de registro y el archivo de datos se asignan al mismo disco duro, la carga de trabajo de los informes con lecturas intensivas del archivo de datos consumirá los mismos recursos de E/S necesarios para la operación de protección del registro. Una protección de registro lenta puede traducirse en una aceptación lenta de la réplica principal, lo que puede producir una activación excesiva y largos tiempos de espera del control de flujo.
Diagnóstico y resolución
Si ha comprobado que la red no presenta una alta latencia o un rendimiento bajo, verifique si existen contenciones de E/S en la réplica secundaria. Las consultas de SQL Server: minimizar la E/S de disco son útiles para identificar las contenciones. A continuación encontrará los ejemplos de ese artículo.
En el siguiente script verá el número de lecturas y escrituras de cada archivo de datos y de registro para cada base de datos de disponibilidad que se ejecute en una instancia de SQL Server. Está ordenado por el tiempo de pausa de E/S promedio, en milisegundos. Tenga en cuenta que los números se acumulan desde la última vez que se inició la instancia del servidor. Por lo tanto, debe tomar la diferencia entre dos mediciones después de que haya transcurrido cierto 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 puntual (no acumulativa) de las solicitudes de E/S pendientes en su 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;
Puede comparar cómo coinciden entre ellas la E/S de lectura y la E/S de escritura para identificar la contención de E/S.
A continuación se indican otros contadores de rendimiento que pueden ayudarle a diagnosticar cuellos de botella de E/S:
Disco físico: todos los contadores
Disco físico: Promedio en segundos de disco/Transferencia
SQL Server: Bases de datos > Tiempo de espera de vaciado del registro de transacciones
SQL Server: Bases de datos > esperas de vaciado del registro de transacciones por segundo
SQL Server: bases de datos > lecturas de disco del grupo de registros/segundo
Si detecta un cuello de botella de E/S y ha colocado el archivo de registro y el archivo de datos en el mismo disco duro, lo primero que debe hacer es colocar dichos archivos en discos separados. Este procedimiento recomendado impide que la carga de trabajo de informes interfiera con la ruta de transferencia de registros de la réplica principal al búfer de registro y con su capacidad de proteger la transacción en la réplica secundaria.