Solucionar problemas: Cambios en la réplica principal no se reflejan en la réplica secundaria

SQL Server 2012
 

La aplicación cliente finaliza una actualización en la réplica principal correctamente, pero consulta la réplica secundaria se muestra que el cambio no se refleja. En este caso, se da por supuesto que su disponibilidad tiene un estado de sincronización correcto. En la mayoría de los casos, este comportamiento se resuelve después de unos minutos.

Si los cambios aún no se reflejan en la réplica secundaria después de unos minutos, puede haber un cuello de botella en el flujo de trabajo de sincronización. La ubicación del cuello de botella depende de si la réplica secundaria se establece en confirmación sincrónica o asincrónica.

Confirmación sincrónica

Cada uno de ellos correcta actualización en la réplica principal ya se ha sincronizado con la réplica secundaria, o que las entradas del registro ya se han vaciado para la protección en la réplica secundaria. Por lo tanto, debe ser el cuello de botella en el proceso de puesta al día que se produce después de que el registro se vacía en la réplica secundaria.

Sin embargo, una vez que rehacer está puesto al día, todas las cargas de trabajo de lectura en la réplica secundaria son el aislamiento de instantánea

  • Transacciones de larga ejecución en la réplica principal

  • Puesta al día en la réplica secundaria

Confirmación asincrónica

Como confirmación asincrónica confirma una transacción en cuanto se vuelca en el disco local, el cuello de botella puede ser en cualquier lugar después de ese punto.

  • Transacciones de larga ejecución en la réplica principal

  • Latencia de red o rendimiento

  • Proteger el registro en la réplica secundaria

  • Puesta al día en la réplica secundaria

Esta sección describe las causas comunes de los cambios en la réplica principal no se refleja en la réplica secundaria para las consultas de solo lectura.

Transacciones activas de ejecución prolongada

Una transacción de larga duración en la réplica principal impide que las actualizaciones que se va a leer en la réplica secundaria.

Explicación

Todas las cargas de trabajo de lectura en la réplica secundaria son consultas de aislamiento de instantánea. En el aislamiento de instantánea, clientes de solo lectura verán la base de datos de disponibilidad en la réplica secundaria en el punto de comienzo de la transacción activa más antigua en el registro de rehacer. Si una transacción no se ha ejecutado durante horas, la transacción abierta bloquea todas las consultas de solo lectura vean alguna actualización nueva.

Diagnóstico y resolución

En la réplica principal, use DBCC OPENTRAN ( Transact-SQL ) para ver las transacciones activas más antiguas y vea si se pueden revertir. Una vez, las transacciones activas más antiguas se revierte y sincronizado con la réplica secundaria, leer las cargas de trabajo en la base de datos secundaria réplica puede ver las actualizaciones en la base de datos de disponibilidad hasta el principio de la transacción activa más antigua, a continuación.

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

Alta latencia de red o un rendimiento bajo puede evitar que los registros que 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. Esta situación puede tener un impacto más grave en la posible pérdida de datos, posiblemente poner en peligro su objetivo de punto de recuperación (RPO).

Diagnóstico y resolución

Un valor alto de DMV log_send_queue_size puede indicar los registros que se retienen en la réplica principal. Dividir este valor por log_send_rate puede proporcionar una estimación aproximada de cuándo igualados datos en la réplica secundaria.

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/s. 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 y Monitor de recursos para evaluar el uso de la red.

  • DMV log_send_queue_size

  • DMV 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.

Otra carga de trabajo informe 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. El subproceso de puesta al día deben desbloquearse antes de poder realizar más actualizaciones disponibles para la carga de trabajo de lectura.

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.

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 carga de trabajo informe 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. Esta situación no solo afecta a otras cargas de trabajo informes de ver datos actualizados, pero también afecta al RTO.

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 2008

Mostrar: