SQL Server sys.databases log_reuse_wait вопрос

Question

Я исследовал быстрый рост журнала транзакций SQL Server 2005, когда обнаружил, что журналы транзакций будут корректно усекаться только в том случае, если для столбца sys.databases "log_reuse_wait" установлено значение 0, что означает, что журнал транзакций не удерживает повторное использование существующего пространства.

Однажды, когда я намеревался сделать резервную копию / усечь файл журнала, я обнаружил, что в этом столбце есть 4 или ACTIVE_TRANSACTION, происходящие в базе данных tempdb. Затем я проверил все открытые транзакции, используя DBCC OPENTRAN ('tempdb') и столбец open_tran из sysprocesses. В результате я не смог найти активных транзакций нигде в системе.

Точны ли настройки в столбце log_reuse_wait? Происходят ли транзакции, которые невозможно обнаружить с помощью методов, описанных выше? Я что-то упускаю из виду?

Answer 1

Я до сих пор не знаю, почему я видел ACTIVE_TRANSACTION в столбце sys.databases log_reuse_wait_desc - когда не было запущенных транзакций, но мой последующий опыт показывает, что столбец log_reuse_wait для базы данных tempdb изменяется по причинам, которые не очень понятны и для моих целей не очень актуально. Кроме того, я обнаружил, что запуск DBCC OPENTRAN или кода "select open_tran from sysprocess" намного менее информативен, чем использование приведенных ниже операторов при поиске информации о транзакции:

select * from sys.dm_tran_active_transactions

select * from sys.dm_tran_session_transactions 

select * from sys.dm_tran_locks

Answer 2

Здесь есть объяснения, как работает log_reuse_wait_desc:

Нам также необходимо понять, как работает механизм отчетов log_reuse_wait_desc. Это дает причину, по которой усечение журнала не могло произойти при последней попытке усечения журнала. Это может сбивать с толку - например, если вы видите ACTIVE_BACKUP_OR_RESTORE и знаете, что не выполняется операция резервного копирования или восстановления, это просто означает, что она выполнялась при последней попытке усечения журнала.

Так что в вашем случае сейчас нет АКТИВНОЙ СДЕЛКИ, но это было, когда в последний раз была предпринята попытка усечения журнала.

Answer 3

Мой ответ из Файл журнала базы данных заполнен :

Как только вы делаете полную резервную копию базы данных, а база данных не использует модель простого восстановления, SQL Server сохраняет полную запись всех транзакций, когда-либо выполненных в базе данных. Это происходит так, что в случае катастрофического сбоя, когда вы теряете файл данных, вы можете восстановить его до точки отказа, сделав резервную копию журнала и, после восстановления старой резервной копии данных, восстановить журнал, чтобы воспроизвести потерянный сделки.

Чтобы предотвратить такое наращивание, необходимо создать резервную копию журнала транзакций. Или вы можете разорвать цепочку в текущей точке, используя опции TRUNCATE_ONLY или NO_LOG BACKUP LOG.

Если вам не нужна эта функция, установите модель восстановления на Simple.

Answer 4

Существует несколько ссылок на дополнительные инструменты / ссылки, которые можно использовать для устранения этой проблемы по ссылке «Ссылки» для этого видео:
Управление файлами журналов SQL Server 2005 и 2008

Тем не менее, информация в log_reuse_wait должна быть точной. Скорее всего, вы только что потерпели неудачную или осиротевшую транзакцию, которую не смогли обнаружить.

Answer 5

Данные, вероятно, точные. Что вам нужно сделать, это иметь регулярное резервное копирование журнала транзакций. Вопреки другим советам, вам НЕ следует использовать параметр NO_TRUNCATE в 2005 году, поскольку он очищает журнал совершенных транзакций, но не создает их резервные копии.

То, что вам следует делать, - это выполнять резервное копирование журналов с использованием оператора BACKUP LOG с параметром NO_TRUNCATE. Вы должны применять регулярные журналы транзакций в течение дня. Это должно помочь сохранить размер достаточно управляемым.

Answer 6

Хм, сложно. Может ли быть так, что сам вопрос к sys.databases вызывает ACTIVE_TRANSACTION? Однако в этом случае он должен быть в MASTER, а не в TEMPDB.