Error 9002: El registro de transacciones de la base de datos está lleno debido a AVAILABILITY_REPLICA mensaje de error en SQL Server

  • Artículo

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 la sys.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 que last_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 el ALLOW_CONNECTIONS parámetro de SECONDARY_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

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