Журнал транзакций SQL Server 2005 не будет обрезаться

Question

У меня есть база данных .mdf файл 138 ГБ вместе с файлом журнала транзакций 55 ГБ.

Модель восстановления была установлена ​​в Полная (которой это не обязательно). Я выполнил полную резервную копию базы данных и журнала транзакций. Журнал транзакций по-прежнему составляет 55 ГБ без свободного места для сжатия файла.

Я запустил эту резервную копию с помощью графического интерфейса SQL Server Management Studio. Затем я выполнил следующие команды, чтобы попытаться сжать трансформацию:

BACKUP LOG database WITH TRUNCATE_ONLY 
DBCC SHRINKFILE (logfile, TRUNCATEONLY) 

Файл журнала по-прежнему составляет 55 ГБ. Затем я изменил модель восстановления на Simple и позволил ему сидеть несколько дней, но он все еще находится на уровне 55 ГБ. Я попробовал эти 2 команды выше, но он все равно ничего не урезает.

Независимо от того, что я пытаюсь, этот файл журнала не будет сокращаться. Поскольку нам вообще не нужен журнал транзакций, я даже пытался отсоединить базу данных, переименовать файл журнала и снова подключиться. Это не работает, так как на самом деле есть 2 журнала транзакций, и я получаю сообщение об ошибке при попытке повторно подключиться без журналов. Другой файл журнала составляет всего 1 МБ, и я попытался его удалить, но также получаю сообщение о том, что он не пуст.

Есть ли что-то, что мне не хватает, или что-то еще, что я могу попробовать?

Спасибо за помощь!

Answer 1

«Я даже пытался отсоединить базу данных, переименовать файл журнала и снова подключиться»: журнал не является необязательным компонентом! Запустите DBCC CHECKDB немедленно, чтобы узнать, вызвали ли вы коррупцию. Вы будете вызывать коррупцию, если по какой-то причине были несвязанные страницы. Даже если вы не играете в азартные игры.

Файл журнала SQL Server не является информационным текстовым журналом.

Если вам не нужен журнал, переключитесь в простой режим и сжимайте файл журнала (вы уже это сделали). TRUNCATE_ONLY is obsolete, я не знаю, делает ли оно что-либо.

Посмотрите на sys.databases и посмотрите на значение в столбце log_reuse_wait_desc. Он расскажет вам, что хранит журнал.

Answer 2

Попробуйте установить checkpointhttp://msdn.microsoft.com/en-us/library/ms188748.aspx

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

Answer 3

Во-первых, вы можете установить начальный размер файла журнала ниже? Если кто-то запустил его на уровне 55 ГБ, он может не пойти ниже этого.

Во-вторых, вы, вероятно, don't need two transaction logs. Второй будет «активным», но не будет использоваться до тех пор, пока первый не будет заполнен. Первый может никогда не заполнить, если у вас нет ограниченного роста, и у вас все еще осталось место на диске.

В-третьих, поскольку @JohnNolan предложил (и, как я собирался предложить), попробуйте контрольную точку, так как это должно позволить усечение журнала под простой моделью восстановления.

Также рекомендуется, чтобы вы avoid using TRUNCATE_ONLY.

Answer 4

В тех редких случаях, когда я должен сжать журнал транзакций, я использую немного другой команды на SQL Server 2005, чем тот, который вы пытались:

backup log database with no_log 
dbcc shrinkfile (logfile,1) 

(...with no_log вместо ...with truncate_only, и второй параметр из dbcc shrinkfile должен быть нужный новый размер файла журнала)

Чтобы убедиться, что я правильно получил имя файла журнала (и потому, что я слишком ленив, чтобы набирать имя базы данных), я использую это скрипт, который автоматически получает имена базы данных и файла журнала:

declare @dbname varchar(255) 
declare @logfile varchar(255) 

select @dbname = db_name() 
select @logfile = name from sysfiles where filename like '%.ldf' 

backup log @dbname with no_log 
dbcc shrinkfile (@logfile,1) 

Вам необходимо запустить его непосредственно в базе данных, для которой вы хотите сжать файл журнала.
Отказ от ответственности: я никогда не использовал его в базе данных, содержащей более одного файла журнала, например, вашего. Возможно, вам придется изменить его, если он по ошибке обнаружил неправильный файл журнала.

Вы можете установить режим восстановления на Simple, прежде чем запускать сценарий, если вам не нужен режим восстановления Full.

И вы должны сделать полную резервную копию сразу после сокращения журнала.
Это очень важно, если вы покинете базу данных в Full режиме восстановления!
(из-за сокращение журнала разбивает цепочку журналов, что означает, что последующие резервные копии журнала бесполезны, пока вы не сделаете следующую полную резервную копию)

Answer 5

это была проблема с MS SQL серверами, но вот решение ....

, чтобы заставить усечение БД делать ФФ:

1. запустить полную резервную копию дб до сокращения
2. набор восстановления от полного до простого
3. DBCC SHRINKFILE
4. комплект восстановление вернуться к полной
5. запустить полную резервную копию базы данных после сморщенных

вот код силы сокращения

use master 
Alter database dbname set Recovery simple; 

use dbname 
DBCC SHRINKFILE (dbname_log, 0, TRUNCATEONLY) 
Alter database dbname set Recovery full; 

надеюсь, что это помогает.

Answer 6

Как бы устранить эту:

1) выберите log_reuse_wait_desc из sys.databases где имя = 'your_db_name'

Это даст вам то, что предотвращение VLFs от повторного использования. Во время медленных периодов (т. Е. Когда журнал не используется много, это должно быть «НЕТ»). Возможно, вам придется устранить неполадки, если вы увидите другое значение.

2) Взгляните на выход dbcc loginfo. Он возвращает одну строку для каждого VLF, который у вас есть в вашем файле журнала. Столбец статуса сообщает вам, используется ли VLF или нет.Чтобы сжать журнал, вам нужно, чтобы неиспользованные VLF были в конце файла. Возможно, вам придется ждать естественной активности. Поскольку VLF используются в виде кольца, неиспользованный (-ые) должен в конечном итоге находиться в конце файла.

Answer 7

Использование ниже запроса:

backup log [dbname] with truncate_only 
go 
DBCC SHRINKDATABASE ([dbname], 10, TRUNCATEONLY) 
go