Установите размер файла журнала вручную после сжатия SQL Server 2008 R2

Я становлюсь несколько непроизвольным администратором базы данных на работе в настоящее время и действительно нуждаюсь в некоторой помощи на чем-то.

У нас есть база данных объемом 40 ГБ в режиме полного восстановления, не настроена резервная копия журнала и огромный файл журнала размером 84 ГБ. На данный момент я планирую спасти эту ситуацию, чтобы выполнить полное резервное копирование журнала в базе данных, сжать файл журнала и составить план обслуживания, чтобы каждую ночь запускать резервное копирование журнала с резервной копией базы данных, чтобы держать ее под контролем.

Моя проблема в том, что я не хочу, чтобы файл журнала сокращался до нуля и проводил первое утро в понедельник, постоянно увеличиваясь. У меня есть приблизительная оценка того, каким должен быть файл (около 20% базы данных), и я хотел бы установить его с самого начала, чтобы обеспечить как можно больше смежного пространства. Это просто случай изменения «Начального размера» в свойствах базы данных -> Файлы? Я бы также предположил, что база данных должна быть в автономном режиме, чтобы это произошло?

заранее спасибо

Просто сядьте до того, что вы считаете оптимальным размером. Не используйте пользовательский интерфейс, просто сделайте это - скажем, 200 МБ - ваш оптимальный размер:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);

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

Если вы хотите, чтобы резервные копии журналов были значимыми, не планируйте делать полное резервное копирование ночью, а затем сразу же делать одно резервное копирование журнала. Это поддерживает модель полного восстановления, делает работу журнала очень сложной и ничего не покупает. Поэтому, если вы хотите восстановить на определенный момент времени, чаще выполняйте резервное копирование журналов со скоростью, удовлетворяющей допустимым потерям данных. Если вы не хотите терять данные более 15 минут, запускайте резервное копирование журнала каждые 15 минут.

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

Точка времени восстановления не требуется

1. Конвертировать базу данных в SIMPLEвосстановление. Выполните контрольную точку для записи транзакций на диск.
2. Выровняйте бревно.
3. Измените размер журнала до соответствующего размера.

Я также рекомендую установить фиксированную величину прироста и неограниченный прирост (чтобы лучше управлять журналом). Обратите внимание, что фиксированный объем роста очень зависит от суммы, я бы рекомендовал изначально использовать 1-2 ГБ в зависимости от того, какой рост может ожидать журнал. В идеале, ваш журнал не будет сильно расти, поэтому это не должно сильно повлиять. Если ваш журнал регулярно растет, возможно, вам придется пересмотреть свой размер.

Выполнено с использованием:

ALTER DATABASE [foo] 
SET RECOVERY SIMPLE;

CHECKPOINT;

DBCC SHRINKFILE (foo_log,0);

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

--Optional if you want the database in full recovery mode 
--for point in time recovery going forward
ALTER DATABASE [foo] 
SET RECOVERY FULL;

Необходим момент восстановления

Самым большим зависанием будет то, что вы не сможете сжать файл журнала после текущего активного VLF-сегмента. Чтобы увидеть это, вы можете использовать DBCC LOGINFOв контексте базы данных. Любой сегмент с состоянием = 2 активен. Чтобы очистить активные сегменты, вам нужно будет выполнить резервное копирование журнала транзакций, когда в этом сегменте в настоящий момент нет активных транзакций. Ваши шаги:

1. Запустите резервное копирование журнала транзакций.
2. Сожмите свой файл. (Идеально сгладить, но если ваша база данных активна, это будет трудно сделать).
3. Повторяйте шаги 1 и 2 до тех пор, пока размер вашего журнала не станет подходящим, в идеале как можно меньшим.
4. Измените размер журнала до соответствующего размера.

Выполнено с использованием:

BACKUP LOG [foo] TO DISK='<Location of t-log backup>';

DBCC SHRINKFILE (foo_log,0);

--Repeat the above until your log file is small "enough"

ALTER DATABASE [foo]
MODIFY FILE (NAME=foo_log,SIZE=8000MB,MAXSIZE=UNLIMITED,FILEGROWTH=1000MB);

Некоторые дополнительные ресурсы, чтобы понять, что здесь происходит:

• Модели восстановления SQL Server

• Рекомендации Кимберли Триппа

• Контрольные точки базы данных

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

USE [DBName]
GO
DBCC SHRINKFILE (N'LogName' , SizeInMg)
GO

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

В дополнение к ответу Аарона о простом режиме вы можете запланировать 2 (или более) разностных резервного копирования в день, таким образом уменьшая окно потери данных вашей базы данных, сохраняя режим SIMPLE.