Поделиться через

Ошибка 9002: журнал транзакций для базы данных заполнен из-за сообщения об ошибке AVAILABILITY_REPLICA в SQL Server

  • Статья

Эта статья поможет устранить ошибку 9002, которая возникает, когда журнал транзакций становится большим или не работает в SQL Server.

Исходная версия продукта: SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012
Исходный номер базы знаний: 2922898

Симптомы

Рассмотрим следующий сценарий:

  • На сервере установлена microsoft SQL Server 2012 или более поздняя версия.
  • Экземпляр SQL Server является основной репликой в среде групп доступности AlwaysOn.
  • Параметр автоматического увеличения файлов журнала транзакций установлен в SQL Server.

В этом сценарии журнал транзакций может стать большим и истекать из дискового пространства или превысить параметр MaxSize для журнала транзакций в первичной реплике, и вы получите сообщение об ошибке, похожее на следующее:

Ошибка: 9002, серьезность: 17, состояние: 9. Журнал транзакций для базы данных "%.*ls" заполнен из-за "AVAILABILITY_REPLICA"

Причина

Это происходит, когда зарегистрированные изменения на первичной реплике еще не закрепились на вторичной реплике. Дополнительные сведения о процессе синхронизации данных в среде AlwaysOn см. в разделе Синхронизация данных hronization Process.

Устранение неполадок

Существует два сценария, которые могут привести к росту журнала в базе данных доступности и 'AVAILABILITY_REPLICA' log_reuse_wait_desc:

  • Сценарий 1. Задержка доставки зарегистрированных изменений в дополнительный

    При изменении данных транзакций в первичной реплике эти изменения инкапсулируются в блоки записей журнала, а эти блоки журнала передаются и закрепляются в файл журнала базы данных во вторичной реплике. Первичная реплика не может перезаписать блоки журнала в собственном файле журнала до тех пор, пока эти блоки журнала не будут доставлены и закрепены в соответствующий файл журнала базы данных во всех вторичных репликах. Любая задержка в доставке или ужесточении этих блоков в любую реплику в группе доступности не позволит усечение зарегистрированных изменений в базе данных на первичной реплике и привести к росту использования файла журнала.

    Дополнительные сведения см. в статье с высокой задержкой сети или низкой пропускной способностью сети, что приводит к созданию журнала на первичной реплике.

  • Сценарий 2. Задержка повтора

    После защиты до файла журнала базы данных-получателя выделенный поток повтора в экземпляре вторичной реплики применяет содержащиеся записи журнала к соответствующим файлам данных. Первичная реплика не может перезаписать блоки журнала в собственном файле журнала, пока все потоки повтора во всех вторичных репликах не применили содержащиеся записи журнала.

    Если операция повторного входа в любой вторичной реплике не в состоянии следить за скоростью, при которой блоки журналов закрепляются на этой вторичной реплике, это приведет к росту журнала на первичной реплике. Первичная реплика может усечь и повторно использовать собственный журнал транзакций до точки применения всех потоков повтора вторичной реплики. Если существует несколько вторичных, сравните truncation_lsn столбец динамического административного sys.dm_hadr_database_replica_states представления в нескольких вторичных файлах, чтобы определить, какая база данных-получатель задерживает усечение журнала больше всего.

    Вы можете использовать панель мониторинга AlwaysOn и sys.dm_hadr_database_replica_states динамические административные представления, чтобы отслеживать очередь отправки журнала и очередь повторного выполнения. Ниже приведены некоторые ключевые поля:

    Поле Description
    log_send_queue_size Количество записей журнала, которые не прибыли на вторичную реплику
    log_send_rate Скорость отправки записей журнала в базы данных-получатели.
    redo_queue_size Объем записей журнала в файлах журнала вторичной реплики, которая еще не была переопределена в килобайтах (КБ).
    redo_rate Скорость повторного изменения записей журнала в данной базе данных-получателе в килобайтах (КБ)/секунде.
    last_redone_lsn Фактический регистрационный номер транзакции последней записи в журнале, повторенной в базе данных-получателе. last_redone_lsn всегда меньше last_hardened_lsn.
    last_received_lsn Идентификатор блока журнала, определяющий точку, к которой были получены все блоки журнала вторичной репликой, в которой размещается эта база данных-получатель. Отражает идентификатор блока журнала, заполненный нулями. Это не фактический номер последовательности журналов.

    Например, выполните следующий запрос к первичной реплике, чтобы сообщить реплике с самой truncation_lsn ранней и является верхней границой, которую основной может восстановить в собственном журнале транзакций:

    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

    Корректирующие меры могут включать в себя, но не ограничиваются следующими:

    • Убедитесь, что в дополнительном ресурсе или производительности нет узких мест.
    • Убедитесь, что поток Повтора не блокируется во вторичной. Используйте расширенное lock_redo_blocked событие, чтобы определить, когда это происходит, и о том, какие объекты блокируются потоком повтора.

Обходное решение

После идентификации базы данных-получателя, которая делает это происходит, попробуйте один или несколько следующих методов временно обойти эту проблему:

  • Отключите базу данных из группы доступности для обиженного вторичного объекта.

    Примечание.

    Этот метод приведет к потере сценария высокого уровня доступности и аварийного восстановления для дополнительного объекта. Возможно, вам придется снова настроить группу доступности в будущем.

  • Если поток повтора часто блокируется, отключите Readable Secondary эту функцию, изменив ALLOW_CONNECTIONS параметр SECONDARY_ROLE реплики на NO.

    Примечание.

    Это позволит пользователям считывать данные во вторичной реплике, что является основной причиной блокировки. После того как очередь повторного ввода упала до приемлемого размера, попробуйте снова включить эту функцию.

  • Включите параметр автоматического увеличения , если он отключен и имеется свободное место на диске.

  • Увеличьте значение MaxSize для файла журнала транзакций, если оно достигнуто и доступно место на диске.

  • Добавьте дополнительный файл журнала транзакций, если текущий достиг системы не более 2 ТБ или если дополнительное пространство доступно в другом доступном томе.

Дополнительная информация

Применяется к

  • 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