Error 9002: El registro de transacciones de la base de datos está lleno debido a AVAILABILITY_REPLICA mensaje de error en SQL Server
Este artículo le ayuda a resolver el error 9002 que se produce cuando el registro de transacciones se vuelve grande o se queda sin espacio en SQL Server.
Versión original del producto: SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Número de KB original: 2922898
Síntomas
Imagine la siguiente situación:
- Tiene Microsoft SQL Server 2012 o una versión posterior instalada en un servidor.
- La instancia de SQL Server es una réplica principal en Always On entorno de grupos de disponibilidad.
- La opción de crecimiento automático de los archivos de registro de transacciones se establece en SQL Server.
En este escenario, el registro de transacciones puede ser grande y quedar sin espacio en disco o superar la opción MaxSize establecida para el registro de transacciones en la réplica principal y recibirá un mensaje de error similar al siguiente:
Error: 9002, gravedad: 17, estado: 9. El registro de transacciones de la base de datos '%.*ls' está lleno debido a 'AVAILABILITY_REPLICA'
Causa
Esto ocurre cuando los cambios registrados en la réplica principal aún no se han protegido en la réplica secundaria. Para obtener más información sobre el proceso de sincronización de datos en Always On entorno, consulte Proceso de sincronización de datos.
Solución de problemas
Hay dos escenarios que pueden dar lugar al crecimiento del registro en una base de datos de disponibilidad y :'AVAILABILITY_REPLICA' log_reuse_wait_desc
Escenario 1: Latencia al entregar los cambios registrados en la secundaria
Cuando las transacciones cambian los datos de la réplica principal, estos cambios se encapsulan en bloques de registros de registro y estos bloques registrados se entregan y protegen en el archivo de registro de base de datos en la réplica secundaria. La réplica principal no puede sobrescribir los bloques de registro en su propio archivo de registro hasta que esos bloques de registro se hayan entregado y protegido en el archivo de registro de base de datos correspondiente en todas las réplicas secundarias. Cualquier retraso en la entrega o protección de estos bloques en cualquier réplica del grupo de disponibilidad impedirá el truncamiento de los cambios registrados en la base de datos en la réplica principal y hará que su uso del archivo de registro aumente.
Para obtener más información, consulte Alta latencia de red o bajo rendimiento de red provoca la compilación de registros en la réplica principal.
Escenario 2: Rehacer la latencia
Una vez protegido al archivo de registro de base de datos secundario, un subproceso de rehacer dedicado en la instancia de réplica secundaria aplica los registros contenidos a los archivos de datos correspondientes. La réplica principal no puede sobrescribir bloques de registro en su propio archivo de registro hasta que todos los subprocesos de rehacer de todas las réplicas secundarias hayan aplicado los registros contenidos.
Si la operación de rehacer en cualquier réplica secundaria no puede mantenerse al día con la velocidad a la que se protegen los bloques de registro en esa réplica secundaria, provocará un crecimiento del registro en la réplica principal. La réplica principal solo puede truncar y reutilizar su propio registro de transacciones hasta el punto en que se han aplicado todos los subprocesos de rehacer de la réplica secundaria. Si hay más de una base de datos secundaria, compare la
truncation_lsn
columna de lasys.dm_hadr_database_replica_states
vista de administración dinámica entre varias secundarias para identificar qué base de datos secundaria retrasa más el truncamiento del registro.Puede usar el panel de Always On y
sys.dm_hadr_database_replica_states
las vistas de administración dinámica para ayudar a supervisar la cola de envío de registros y la cola de rehacer. Algunos campos clave son:Campo Descripción log_send_queue_size
Cantidad de registros que no han llegado a la réplica secundaria log_send_rate
Velocidad a la que se envían los registros a las bases de datos secundarias. redo_queue_size
Cantidad de registros en los archivos de registro de la réplica secundaria que aún no se ha vuelto a crear, en kilobytes (KB). redo_rate
Velocidad a la que se vuelven a crear los registros en una base de datos secundaria determinada, en kilobytes (KB)/segundo. last_redone_lsn
Número de secuencia de registro real del último registro que se realizó en la base de datos secundaria. last_redone_lsn
siempre es menor quelast_hardened_lsn
.last_received_lsn
Identificador de bloque de registro que identifica el punto hasta el que la réplica secundaria que hospeda esta base de datos secundaria ha recibido todos los bloques de registro. Refleja un identificador de bloque de registro rellenado con ceros. No es un número de secuencia de registro real. Por ejemplo, ejecute la siguiente consulta en la réplica principal para notificar la réplica con la versión más antigua
truncation_lsn
y es el límite superior que el principal puede reclamar en su propio registro de transacciones:SELECT ag.name AS [availability_group_name] , d.name AS [database_name] , ar.replica_server_name AS [replica_instance_name] , drs.truncation_lsn , drs.log_send_queue_size , drs.redo_queue_size FROM sys.availability_groups ag INNER JOIN sys.availability_replicas ar ON ar.group_id = ag.group_id INNER JOIN sys.dm_hadr_database_replica_states drs ON drs.replica_id = ar.replica_id INNER JOIN sys.databases d ON d.database_id = drs.database_id WHERE drs.is_local=0 ORDER BY ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC
Las medidas correctivas pueden incluir, entre otras, las siguientes:
- Asegúrese de que no haya ningún cuello de botella de rendimiento o de recursos en el secundario.
- Asegúrese de que el subproceso Redo no esté bloqueado en el secundario. Use el
lock_redo_blocked
evento extendido para identificar cuándo se produce y en qué objetos se bloquea el subproceso de rehacer.
Solución alternativa
Después de identificar la base de datos secundaria que hace que esto ocurra, pruebe uno o varios de los métodos siguientes para solucionar este problema temporalmente:
Saque la base de datos del grupo de disponibilidad de la secundaria infractora.
Nota:
Este método provocará la pérdida del escenario de alta disponibilidad y recuperación ante desastres para el secundario. Es posible que tenga que volver a configurar el grupo de disponibilidad en el futuro.
Si el subproceso de rehacer se bloquea con frecuencia, deshabilite la
Readable Secondary
característica cambiando elALLOW_CONNECTIONS
parámetro deSECONDARY_ROLE
para la réplica a NO.Nota:
Esto impedirá que los usuarios lean los datos de la réplica secundaria, que es la causa principal del bloqueo. Una vez que la cola de rehacer se haya reducido a un tamaño aceptable, considere la posibilidad de volver a habilitar la característica.
Habilite la configuración de crecimiento automático si está deshabilitada y hay espacio en disco disponible.
Aumente el valor de MaxSize para el archivo de registro de transacciones si se ha alcanzado y hay espacio disponible en disco.
Agregue un archivo de registro de transacciones adicional si el actual ha alcanzado el máximo de 2 TB del sistema o si hay espacio adicional disponible en otro volumen disponible.
Más información
Para obtener más información sobre por qué un registro de transacciones crece inesperadamente o se llena en SQL Server, vea Solución de problemas de un registro de transacciones completo (SQL Server error 9002)..
Para obtener más información sobre el problema de bloqueo de la operación Rehacer, vea AlwaysON - HADRON Learning Series: lock_redo_blocked/rehacer trabajo Bloqueado en la réplica secundaria.
Para obtener más información sobre las columnas de log_reuse_wait basadas en AVAILABILITY_REPLICA, vea Factores que pueden retrasar el truncamiento del registro.
Para obtener más información sobre la
sys.dm_hadr_database_replica_states
vista, vea sys.dm_hadr_database_replica_states (Transact-SQL).Para obtener más información sobre cómo supervisar y solucionar problemas de los cambios registrados que no llegan y que no se aplican de forma oportuna, consulte Supervisión del rendimiento de Always On grupos de disponibilidad.
Se aplica a
- SQL Server 2012 Enterprise
- SQL Server 2014 Enterprise
- SQL Server 2014 Business Intelligence
- SQL Server 2014 Standard
- SQL Server 2016 Enterprise
- SQL Server 2016 Standard
- SQL Server 2017 Enterprise
- SQL Server 2017 Standard Windows