Compartir a través de

Error 9002: El registro de transacciones de la base de datos está lleno debido a un mensaje de error AVAILABILITY_REPLICA 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

Considere el caso siguiente:

  • 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 el entorno de grupos de disponibilidad AlwaysOn.
  • La opción de crecimiento automático para los archivos de registro de transacciones se establece en SQL Server.

En este escenario, el registro de transacciones puede llegar a ser grande y agotar el espacio en disco o superar la opción MaxSize establecida para el registro de transacciones en la réplica principal y recibe 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 protegen en la réplica secundaria. Para obtener más información sobre el proceso de sincronización de datos en el entorno AlwaysOn, consulte Proceso de sincronización de datos.

Solución de problemas

Hay dos escenarios que pueden provocar el crecimiento del registro en una base de datos de disponibilidad y :'AVAILABILITY_REPLICA' log_reuse_wait_desc

  • Escenario 1: Latencia que entrega los cambios registrados en la base de datos secundaria

    Cuando las transacciones cambian datos en la réplica principal, estos cambios se encapsulan en bloques 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 al 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 evitará 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 Latencia de red alta o rendimiento de red bajo causa la compilación de registros en la réplica principal.

  • Escenario 2: Latencia de puesta al día

    Una vez protegido en el archivo de registro de base de datos secundario, un subproceso de puesta al día dedicado en la instancia de réplica secundaria aplica los registros de registro contenidos a los archivos de datos correspondientes. La réplica principal no puede sobrescribir los bloques de registro en su propio archivo de registro hasta que todos los subprocesos de puesta al día de todas las réplicas secundarias hayan aplicado los registros de registro 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á el 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 puesta al día 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 las varias secundarias para identificar qué base de datos secundaria retrasa el truncamiento del registro más.

    Puede usar el panel AlwaysOn 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 puesta al día. 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 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 rehacen los registros de registro en una base de datos secundaria determinada, en kilobytes (KB)/segundo.
    last_redone_lsn El número de secuencia de registro real de la última entrada de registro que se rehízo 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 al que han recibido todos los bloques de registro la réplica secundaria que hospeda esta base de datos secundaria. 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 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 hay ningún cuello de botella de rendimiento o recurso en la base de datos secundaria.
    • Asegúrese de que el subproceso rehacer no está bloqueado en la base de datos secundaria. Use el lock_redo_blocked evento extendido para identificar cuándo se produce y en qué objetos está bloqueado el subproceso de puesta al día.

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:

  • Sacar la base de datos del grupo de disponibilidad para el secundario infractor.

    Nota:

    Este método provocará la pérdida del escenario de alta disponibilidad o recuperación ante desastres de la base de datos secundaria. Es posible que tenga que volver a configurar el grupo de disponibilidad en el futuro.

  • Si el subproceso de puesta al día se bloquea con frecuencia, deshabilite la Readable Secondary característica cambiando el ALLOW_CONNECTIONS parámetro de para SECONDARY_ROLE 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 ha eliminado 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 MaxSize para el archivo de registro de transacciones si se ha alcanzado y hay espacio en disco disponible.

  • Agregue un archivo de registro de transacciones adicional si el actual ha alcanzado el máximo del sistema de 2 TB 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