Почему я не могу сжать файл журнала транзакций даже после резервного копирования?

Question

У меня есть база данных с 28-гигабайтным файлом журнала транзакций. Режим восстановления прост. Я просто сделал полную резервную копию базы данных, а затем запустил оба:

backup log dbmcms with truncate_only</p> <p>DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

Имя базы данных - db_mcms, а имя файла журнала транзакций - Wxlog0.

Ни то, ни другое не помогло. Я не уверен, что делать дальше.

Answer 1

Спасибо всем за ответы.

Мы наконец нашли проблему. В sys.database log_reuse_wait_desc был равен «репликация». Очевидно, это что-то означает, что SQL Server ожидает завершения задачи репликации, прежде чем он сможет повторно использовать пространство журнала.

Репликация никогда не использовалась на этой БД, или этот сервер когда-то использовался на этой БД. Мы очистили неправильное состояние, запустив sp_removedbreplication. После того, как мы запустили это, журнал резервного копирования и dbcc shrinkfile работали просто отлично.

Определенно один для мешка с трюками.

Источники:

http://social.technet.microsoft.com/Forums/pt-BR/sqlreplication/thread/34ab68ad-706d-43c4-8def-38c09e3bfc3b

http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705

Answer 2

Вы можете столкнуться с этой проблемой, если ваша база данных настроена на автоматическое наращивание журнала, и в результате вы получаете множество виртуальных файлов журнала.
Запустите DBCC LOGINFO('databasename') и посмотрите на последнюю запись, если это 2, то ваш файл журнала не будет уменьшаться. В отличие от файлов данных, файлы виртуальных журналов нельзя перемещать внутри файла журнала.

Вам потребуется несколько раз запустить BACKUP LOG и DBCC SHRINKFILE, чтобы сжать файл журнала.

Для получения дополнительных бонусных баллов запускайте DBBC LOGINFO между журналом и прогонами

Answer 3

'sp_removedbreplication' не решила проблему для меня, поскольку SQL только что вернулся, сказав, что база данных не была частью репликации ...

Я нашел свой ответ здесь:

• http://www.sql -server-performance.com / форума / темы / лог-файлы не удается к truncate.25410 /
• http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx

По сути, мне пришлось создать репликацию, сбросить все указатели репликации на ноль; затем удалите репликацию, которую я только что сделал. т.е.

Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO

Answer 4

Этот ответ был снят с здесь и размещен здесь в случае удаления другой темы:

Проблема в том, что у вас есть нераспределенный LSN в журнале. Я видел это однажды, прежде чем не уверен, почему мы не помечаем транзакция как реплицированная. Мы будем расследовать это внутренне. Вы может выполнить следующую команду, чтобы отменить пометку транзакции как реплицируются

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1

На этом этапе вы сможете обрезать журнал.

Answer 5

Вам не нужно это

DBCC SHRINKFILE ('Wxlog0', 0)

Просто будьте уверены, что вы знаете об опасностях: см. Здесь: Не обрезайте свои файлы ldf!

А здесь Резервный журнал с Truncate_Only: как медвежья ловушка

Answer 6

У меня была такая же проблема в прошлом. Обычно сжатие и резервное копирование trn должны выполняться несколько раз. В крайних случаях я устанавливаю «простое» восстановление БД, а затем запускаю операцию сжатия файла журнала. Это всегда работает для меня. Однако недавно у меня возникла ситуация, когда это не сработало. Эта проблема была вызвана продолжительным запросом, который не завершился, поэтому любые попытки сжатия были бесполезны, пока я не смог завершить этот процесс, а затем запустить свои операции сжатия. Мы говорим о файле журнала, который вырос до 60 ГБ и теперь сокращен до 500 МБ.

Помните, как только вы перейдете из ПОЛНОГО режима в режим Простого восстановления и выполните сжатие, не забудьте снова установить его в ПОЛНОЕ. Затем сразу же после этого вы должны сделать полную резервную копию БД.

Answer 7

Я знаю, что это несколько лет, но хотел бы добавить информацию.

Я обнаружил в очень больших журналах, в частности, когда БД не была настроена на резервное копирование журналов транзакций (журналы были очень большими), первая резервная копия журналов не установила бы log_reuse_wait_desc в ничто, а оставила бы состояние как резервное копирование. Это заблокирует сокращение. При повторном запуске резервной копии правильно установите для log_reuse_wait_desc значение НИЧЕГО, что позволяет обрабатывать сжатие.

Answer 8

Если вы установите режим восстановления для базы данных в 2005 году (не знаю, что было до 2005 года), он удалит файл журнала все вместе, а затем вы сможете вернуть его в режим полного восстановления, чтобы перезапустить / воссоздать файл журнала. Мы столкнулись с этим с помощью SQL 2005 Express в том смысле, что мы не могли приблизиться к пределу в 4 ГБ с данными, пока мы не изменили режим восстановления.

Answer 9

У меня была такая же проблема. Я запустил процесс дефрагментации индекса, но журнал транзакций заполнился, и процесс дефрагментации завершился ошибкой. Журнал транзакций остался большим.

Я сделал резервную копию журнала транзакций, затем приступил к сжатию файла журнала транзакций .ldf. Однако журнал транзакций вообще не уменьшался.

Затем я выдал «CHECKPOINT», затем «DBCC DROPCLEANBUFFER» и после этого смог сжать файл .ldf журнала транзакций

Answer 10

Я перепробовал все перечисленные решения, но ни одно из них не сработало. В итоге мне пришлось выполнить процедуру sp_detach_db, затем удалить файл ldf и заново присоединить базу данных, заставив ее создать новый файл ldf. Это сработало.