SQL Server 2005, Огромный файл LDF

Сводка: при нахождении в этой ситуации Вы, вероятно, хотите Опцию 1 ниже. Пропустите там, чтобы решить проблему или продолжать читать для большего количества объяснения.

База данных в Microsoft SQL Server имеет различные "режимы восстановления", это может быть настроено, чтобы быть в:

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

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

2. Полный. Все еще можно взять и полное резервное копирование и дифференциальное резервное копирование, но также необходимо взять периодические резервные копирования журнала транзакций. Принимая во внимание, что дифференциальное резервное копирование содержит изменения базы данных начиная с последнего полного резервного копирования, регистрируется, backukps только содержат данные начиная с последнего резервного копирования журнала, таким образом, резервные копии журнала должны быть маленькими и быстрыми.

   План резервного копирования относительно полной базы данных восстановления мог бы быть "еженедельным полным резервным копированием, ежедневным дифференциальным резервным копированием и резервным копированием журнала транзакций каждые 5 минут". Это означает, что Вы никогда не теряете больше чем 5 минут данных. При восстановлении такой базы данных Вы восстановили бы к последнему дифференциальному резервному копированию, затем применили бы каждое резервное копирование журнала, сделанное начиная с той точки.

3. С массовым протоколированием. Это - вид подобного "полного режима восстановления, кроме тех случаев, когда я говорю иначе".

Полное восстановление является большим, потому что можно восстановить базу данных почти до времени катастрофического отказа, но это также требует этого, Вы берете резервные копии журнала. Почему? Поскольку журналы в файле журнала транзакций только отмечены как "усеченные", после того как Вы берете резервное копирование журнала. После того как журнал является усеченным, новым журналам позволяют перезаписать его.

Если Вы никогда не берете резервное копирование журнала, то ничто в журнале транзакций никогда не отмечается как усеченное, и поэтому файл журнала должен вырасти с каждым изменением базы данных.

Для получения дополнительной информации о том, как работает журнал транзакций, прочитайте превосходные статьи Paul Randal:

• Понимание входа и восстановления в SQL Server
• Важность надлежащего управления размером журнала транзакций
• Неправильные представления вокруг журнала и резервных копий журнала: как убедить себя

Теперь, в ситуации, где Вы оказываетесь с огромным журналом транзакций, существует две реальных опции:

Опция 1: Переключитесь на простую модель восстановления

Вы, вероятно, не должны брать резервные копии журнала (так как Вы не делаете его теперь), таким образом, можно просто переключиться на простую модель восстановления:

ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE

Это отметит все в журнале транзакций как усеченное, таким образом, файл журнала не станет немного больше. После того как Вы сделали это, для уменьшения физического файла журнала:

DBCC SHRINKFILE N'MyDatabase.ldf'

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

Опция 2: Начните брать резервные копирования журнала транзакций

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

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

BACKUP LOG [MyDatabase] WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE N'MyDatabase.ldf'
GO

Теперь Ваш файл журнала транзакций должен быть разумным размером. Это начнет расти снова сразу;все же. необходимо теперь начать брать резервные копии журнала регулярно. Можно сделать это через план технического обслуживания, или посредством регулярного выполнения команды, такой как:

BACKUP LOG [MyDatabase] TO DISK = N'C:\Backups\MyDatabase_Log_Backup1.bak' WITH INIT

Примечание стороны

DBCC SHRINKFILE не предназначен, чтобы регулярно использоваться:

• Файлы журнала вырастут снова в конюшню, измеренную на основе действия базы данных и как часто Вы берете резервные копии журнала.
• Уменьшение файлов данных полностью фрагментирует Ваши индексы.

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