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

Ошибка 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 является основным реплика в среде групп доступности Always On.
  • Параметр автоматического увеличения для файлов журнала транзакций задается в SQL Server.

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

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

Причина

Это происходит, когда зарегистрированные изменения на первичном реплика еще не ужесточились на вторичном реплика. Дополнительные сведения о процессе синхронизации данных в Always On среде см. в разделе Процесс синхронизации данных.

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

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

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

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

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

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

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

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

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

    Поле Описание
    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_CONNECTIONSSECONDARY_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
  • Windows SQL Server 2017 (стандартный)