¿La ejecución de una consulta grande en una base de datos secundaria en un grupo de disponibilidad afectará el rendimiento de la transacción en la base de datos primaria?
Depende del modo de sincronización que haya utilizado al configurar el grupo de disponibilidad: ¡Sincronizar o Async!
En la réplica secundaria , todas las transacciones utilizan el nivel de aislamiento de instantánea SOLAMENTE y todas las sugerencias de bloqueo también se ignoran. Por eso es importante probar su carga de trabajo al adoptar AlwaysON.
De: minimizar el bloqueo del hilo REDO al ejecutar la carga de trabajo de informes en la réplica secundaria
Si bien la asignación de la carga de trabajo de informes al aislamiento de instantáneas elimina el bloqueo entre la carga de trabajo DML aplicada por el subproceso REDO en la réplica secundaria y la carga de trabajo de lectura o informe, no elimina el posible bloqueo del subproceso REDO cuando se ejecuta una operación DDL .
Si usa
Modo sincrónico
El problema de bloqueo en su réplica secundaria afectará el rendimiento de sus consultas en la réplica principal. Por lo tanto, una carga de trabajo de lectura (select) ejecutada en secundaria podría bloquear el hilo de rehacer para que no aplique los cambios que provienen de la réplica principal. Esto significa que la réplica principal tiene que esperar a que se apliquen los cambios a todas las réplicas SYNC secundarias antes de comprometerse localmente y podría terminar en tiempos de espera o bloqueo o bloqueo.
El hilo REDO se puede ver en el secundario legible como el DB STARTUP
comando en sys.dm_exec_requests
. Si ese hilo está siendo bloqueado, entonces su carga de trabajo de lectura en el secundario podría estar causando un impacto en el primario.
Para obtener más información, consulte - Escenario 1: REDO bloqueado debido a una consulta grande en la réplica secundaria
Modo asincrónico
- El primario no espera el acuse de recibo del secundario. Un problema de bloqueo en el secundario solo se aísla en el secundario en el que la cola de rehacer crecerá en el secundario hasta que los bloqueos estén limpios y el hilo de rehacer pueda aplicar los bloques de registro. Esto no afectará a la réplica principal.
Su definición de "en tiempo real o casi en tiempo real" necesita más reflexión teniendo en cuenta el método de sincronización utilizado, la latencia de la red y qué tan ocupado está la réplica principal y la actividad de registro que debe transportarse en forma secundaria.
SQL Server 2016 ha realizado algunas mejoras importantes en el dominio AlwaysON, por ejemplo