SQL Server sys.databases log_reuse_wait вопрос
Я исследовал быстрый рост журнала транзакций SQL Server 2005, когда обнаружил, что журналы транзакций будут только правильно обрезаться - если столбец sys.databases "log_reuse_wait" установлен в 0 - это означает, что ничто не мешает журналу транзакций повторно использовать существующее пространство. .
Однажды, когда я намеревался создать резервную копию / усечь файл журнала, я обнаружил, что в этом столбце в базе данных tempdb было значение 4 или ACTIVE_TRANSACTION. Затем я проверил любые открытые транзакции, используя DBCC OPENTRAN ('tempdb') и столбец open_tran из sysprocesses. В результате я не смог найти никаких активных транзакций в системе.
Правильны ли настройки в столбце log_reuse_wait? Существуют ли транзакции, которые невозможно обнаружить с помощью описанных выше методов? Я просто упускаю что-то очевидное?
Ответы 6
Хм, сложно. Может быть, сам вопрос к sys.databases вызывает ACTIVE_TRANSACTION? Однако в этом случае он должен находиться в MASTER, а не в TEMPDB.
Есть несколько ссылок на дополнительные инструменты / справочные материалы, которые вы можете использовать для устранения этой проблемы, в ссылке «Справочные материалы» для этого видео:
Управление файлами журналов SQL Server 2005 и 2008
Тем не менее, информация в log_reuse_wait должна быть точной. Скорее всего, у вас только что застопорилась или осиротела транзакция, которую вы каким-то образом не смогли обнаружить.
Спасибо за ссылку! Я посмотрел видео и кое-что узнал, но, к сожалению, он не ответил на мой основной вопрос.
Мой ответ от Файл журнала для базы данных заполнен:
Как только вы делаете полную резервную копию базы данных, а база данных не использует модель простого восстановления, SQL Server сохраняет полную запись всех транзакций, когда-либо выполнявшихся с базой данных. Это сделано для того, чтобы в случае катастрофического сбоя, когда вы потеряете файл данных, вы можете восстановить его до точки отказа, сделав резервную копию журнала, и, как только вы восстановите старую резервную копию данных, восстановите журнал, чтобы воспроизвести потерянный файл. сделки.
Чтобы предотвратить это накопление, вы должны создать резервную копию журнала транзакций. Или вы можете разорвать цепочку в текущей точке, используя опции TRUNCATE_ONLY или NO_LOG в BACKUP LOG.
Если вам не нужна эта функция, установите модель восстановления «Простая».
Мне была известна информация в вашем ответе. Я исправил растущий журнал транзакций, установив простую модель записи. Однако мой вопрос: почему log_reuse_wait должен показывать мне, что есть активные транзакции, когда я не могу их найти в системе.
Данные, вероятно, точные. Что вам нужно сделать, так это иметь регулярную резервную копию журнала транзакций. Вопреки другим советам, вы НЕ должны использовать опцию NO_TRUNCATE в 2005 году, поскольку она очищает журнал совершенных транзакций, но не создает их резервную копию.
Вам следует выполнить резервное копирование хвостового журнала с помощью оператора BACKUP LOG с параметром NO_TRUNCATE. Вам также следует использовать регулярные журналы транзакций в течение дня. Это должно помочь сохранить приемлемый размер.
Я до сих пор не знаю, почему я видел 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
Здесь есть объяснения, как работает log_reuse_wait_desc:
We also need to understand how the log_reuse_wait_desc reporting mechanism works. It gives the reason why log truncation couldn’t happen the last time log truncation was attempted. This can be confusing – for instance if you see ACTIVE_BACKUP_OR_RESTORE and you know there isn’t a backup or restore operation running, this just means that there was one running the last time log truncation was attempted.
Итак, в вашем случае АКТИВНОЙ ТРАНЗАКЦИИ сейчас нет, но это было, когда в прошлый раз была предпринята попытка усечения журнала.
Возможно, но примерно через час ACTIVE_TRANSACTION исчезнет и вернется на 0 (НИЧЕГО). Если бы ваше предложение было верным, то каждый раз, когда я запрашивал sys.databases, tempdb (или master) всегда находился бы в режиме ACTIVE_TRANSACTION.