У меня есть база данных с файлом журнала транзакций 28gig. Режим восстановления прост. Я просто взял полную резервную копию базы данных, а затем запустил оба:
backup log dbmcms with truncate_only
DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)
Имя db - db_mcms, а имя файла журнала транзакций - Wxlog0.
Ничего не помогло. Я не уверен, что делать дальше.
Спасибо всем за ответ.
Мы наконец нашли проблему. В sys.databases значение log_reuse_wait_desc равно "репликация". По-видимому, это означает, что SQL Server ожидает завершения задачи репликации до повторного использования пространства журнала.
Репликация никогда не использовалась в этой БД или на этом сервере играли раз в то время на этом db. Мы очистили неправильное состояние, запустив sp_removedbreplication. После того, как мы запустили это, файл резервного копирования и dbcc shrinkfile работал нормально.
Определенно один для мешков-трюков.
Источники:
http://www.eggheadcafe.com/conversation.aspx?messageid=34020486&threadid=33890705
Вы можете столкнуться с этой проблемой, если ваша база данных настроена на автоматический просмотр журнала, и в итоге вы получаете множество виртуальных файлов журналов.
Запустите DBCC LOGINFO('databasename') и посмотрите на последнюю запись, если это 2, тогда ваш файл журнала не будет сокращаться. В отличие от файлов данных файлы виртуального журнала не могут перемещаться внутри файла журнала.
Вам нужно будет несколько раз запустить BACKUP LOG и DBCC SHRINKFILE, чтобы уменьшить размер файла журнала.
Для дополнительных бонусных очков запустите DBBC LOGINFO между журналом и ширками
Вам это не нужно
DBCC SHRINKFILE ('Wxlog0', 0)
Просто убедитесь, что вы знаете об опасности: см. здесь: Не обрезайте ваши файлы ldf!
И здесь Резервный журнал с Truncate_Only: как ловушка медведя
'sp_removedbreplication' не решила проблему для меня, поскольку SQL только что вернулся, заявив, что база данных не является частью репликации...
Я нашел здесь свой ответ:
В основном мне приходилось создавать репликацию, reset все указатели репликации до нуля; затем удалите репликацию, которую я только что сделал. то есть.
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
Этот ответ был снят с здесь и отправлен здесь, если удаляется другой поток:
Проблема в том, что у вас есть нераспределенный LSN в журнале - проблема. Я видел это однажды, прежде чем не уверен, почему мы не отменим транзакция как реплицированная. Мы будем исследовать это внутренне. Вы может выполнить следующую команду, чтобы отменить транзакцию как реплицируются
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
На этом этапе вы сможете урезать журнал.
У меня была такая же проблема в прошлом. Обычно сжатие и резервное копирование trn необходимо выполнять несколько раз. В крайних случаях я устанавливаю БД в "Простое" восстановление, а затем запускаю операцию сжатия в файле журнала. Это всегда работает для меня. Однако в последнее время у меня была ситуация, когда это не сработало. Проблема была вызвана длинным запросом, который не был завершен, поэтому любые попытки сжиматься были бесполезны, пока я не смог убить этот процесс, а затем запустить мои операции сжатия. Мы говорим о файле журнала, который вырос до 60 ГБ и теперь сокращен до 500 МБ.
Помните, как только вы перейдете с ПОЛНОГО в режим простого восстановления и сделаете сжатие, не забудьте вернуть его в ПОЛНЫЙ. Затем сразу после этого вы должны сделать резервную копию FULL DB.
Если вы установите режим восстановления в базе данных в 2005 году (не знаете, что до 2005 года), он все равно выведет файл журнала, а затем вы сможете вернуть его в полный режим восстановления, чтобы перезапустить/восстановить файл журнала. Мы столкнулись с этим с выражением SQL 2005 в том смысле, что мы не смогли приблизиться к пределу 4 ГБ с данными до тех пор, пока не изменим режим восстановления.
Я знаю, что это уже несколько лет, но хотелось добавить некоторую информацию.
Я нашел в очень больших журналах, особенно когда БД не была настроена на резервное копирование журналов транзакций (журналы были очень большими), первая резервная копия журналов не установила бы log_reuse_wait_desc ничем, кроме как оставить статус как резервное копирование. Это блокирует сжатие. Запуск резервной копии второй раз правильно reset log_reuse_wait_desc в НИЧЕГО, позволяя обрабатывать сжатие.
Вы пробовали из студии управления SQL Server с помощью графического интерфейса. Щелкните правой кнопкой мыши на базе данных, задачах, сокращениях, файлах. Выберите filetype = Log.
Я работал на неделю неделю назад.
Попробуйте использовать целевой размер, необходимый для TRUNCATEONLY в DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
И проверьте это на статьи:
http://msdn.microsoft.com/en-us/library/ms189493(SQL.90).aspx
http://support.microsoft.com/kb/907511
Edit:
Вы можете попытаться переместить выделенные страницы в начало файла журнала сначала с помощью
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
и после этого
DBCC SHRINKFILE ('Wxlog0', 1)
Попробуйте создать еще одну полную резервную копию после резервного копирования журнала w/truncate_only (IIRC вы должны сделать это в любом случае, чтобы поддерживать цепочку журналов). В простом режиме восстановления ваш журнал не должен сильно расти, так как он эффективно усекается после каждой транзакции. Затем попробуйте указать размер, в котором должен быть файл журнала, например
-- shrink log file to c. 1 GB
DBCC SHRINKFILE (Wxlog0, 1000);
Параметр TRUNCATEONLY не переупорядочивает страницы внутри файла журнала, поэтому у вас может быть активная страница в конце файла, что может помешать ее сокращению.
Вы также можете использовать DBCC SQLPERF (LOGSPACE), чтобы убедиться, что в файле журнала действительно освобождено место.
Верните БД в полный режим, запустите резервную копию журнала транзакций (а не только полную резервную копию), а затем сократите.
После того, как он уменьшится, вы можете вернуть БД в простой режим, и журнал txn останется прежним.
Вы не можете уменьшить журнал транзакций, который меньше первоначально созданного.
Я попробовал все перечисленные решения, и никто из них не работал. Мне пришлось сделать sp_detach_db, а затем удалить ldf файл и повторно подключить базу данных, вынудив ее создать новый ldf файл. Это сработало.