Уменьшение размера файла журнала на самом деле должно быть зарезервировано для сценариев, в которых произошел неожиданный рост, который, как вы ожидаете, не произойдет снова. Если размер файла журнала снова увеличится до того же размера, то временное его сжатие достигается не очень сильно. Теперь, в зависимости от целей восстановления вашей базы данных, это те действия, которые вы должны предпринять.
Сначала сделайте полную резервную копию
Никогда не вносите никаких изменений в вашу базу данных, не убедившись, что вы можете восстановить ее, если что-то пойдет не так.
Если вы заботитесь о восстановлении на момент времени
(И под восстановлением на момент времени я имею в виду, что вы заботитесь о возможности восстановления чего-либо, кроме полной или дифференциальной резервной копии.)
Предположительно, ваша база данных находится в режиме восстановления FULL. Если нет, то убедитесь, что это:
ALTER DATABASE testdb SET RECOVERY FULL;
Даже если вы регулярно выполняете полное резервное копирование, файл журнала будет увеличиваться и увеличиваться до тех пор, пока вы не выполните резервное копирование log - это для вашей защиты, а не для ненужного расходования места на диске. Вы должны выполнять эти резервные копии журнала довольно часто, в соответствии с вашими целями восстановления. Например, если у вас есть бизнес-правило, которое гласит, что вы можете позволить себе потерять не более 15 минут данных в случае аварии, у вас должно быть задание, которое будет резервировать журнал каждые 15 минут. Вот скрипт, который будет генерировать имена файлов с метками времени на основе текущего времени (но вы также можете делать это с планами обслуживания и т. Д., Только не выбирайте какие-либо параметры сжатия в планах обслуживания, они ужасны).
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
Обратите внимание, что \\backup_share\ должен находиться на другом компьютере, который представляет другое базовое устройство хранения. Резервное копирование их на одну и ту же машину (или на другую машину, которая использует те же базовые диски, или другую виртуальную машину, расположенную на том же физическом хосте), на самом деле не поможет вам, поскольку, если машина взорвется, вы потеряете базу данных. и его резервные копии. В зависимости от вашей сетевой инфраструктуры может иметь больше смысла делать резервные копии локально, а затем передавать их в другое место за кулисами; в любом случае вы хотите как можно быстрее удалить их с основного компьютера базы данных.
Теперь, когда у вас запущены регулярные резервные копии журналов, разумно будет сжать файл журнала до чего-то более разумного, чем то, на что он был создан. Это означает , а не означает, что нужно запускать SHRINKFILE снова и снова, пока файл журнала не станет размером 1 МБ - даже если вы часто выполняете резервное копирование журнала, все равно необходимо учитывать сумму любых одновременных транзакций, которые могут произойти , События автоматического увеличения файла журнала являются дорогостоящими, поскольку SQL Server должен обнулять файлы (в отличие от файлов данных, когда включена мгновенная инициализация файла), и пользовательские транзакции должны ждать, пока это произойдет. Вы хотите выполнять эту процедуру «расти-сжимать-расти-сжимать» как можно меньше, и вы, конечно же, не хотите, чтобы ваши пользователи платили за нее.
Обратите внимание, что вам может потребоваться выполнить резервное копирование журнала дважды, прежде чем станет возможным сокращение (спасибо, Роберт).
Итак, вам нужно найти практичный размер для вашего файла журнала. Никто здесь не может сказать вам, что это такое, не зная намного больше о вашей системе, но если вы часто сокращали файл журнала, и он снова рос, хороший водяной знак, вероятно, на 10-50% выше, чем самый большой, на котором он был , Допустим, это составляет 200 МБ, и вы хотите, чтобы все последующие события автоматического увеличения составляли 50 МБ, затем вы можете настроить размер файла журнала следующим образом:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
Обратите внимание, что если размер файла журнала в настоящее время> 200 МБ, вам может потребоваться сначала запустить его:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
Если вас не волнует восстановление на момент времени
Если это тестовая база данных, и вы не заботитесь о восстановлении на определенный момент времени, то вам следует убедиться, что ваша база данных находится в режиме SIMPLE восстановления.
ALTER DATABASE testdb SET RECOVERY SIMPLE;
Перевод базы данных в режим восстановления SIMPLE гарантирует, что SQL Server повторно использует части файла журнала (по существу, постепенно выводя из строя неактивные транзакции) вместо того, чтобы расти, чтобы вести запись всех транзакций ( как FULL восстановление происходит до тех пор, пока вы не создадите резервную копию журнала). События CHECKPOINT помогут управлять журналом и следить за тем, чтобы он не увеличивался, если вы не генерируете большую активность t-log между CHECKPOINT с.
Далее, вы должны быть абсолютно уверены, что этот рост журнала действительно был вызван ненормальным событием (скажем, ежегодной весенней уборкой или восстановлением ваших самых больших показателей), а не из-за обычного ежедневного использования. Если вы сократите файл журнала до смехотворно небольшого размера, а SQL Server просто придется снова увеличить его, чтобы он соответствовал вашей обычной деятельности, что вы получили? Удалось ли вам использовать то дисковое пространство, которое вы освободили, только временно? Если вам нужно немедленное исправление, вы можете запустить следующее:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO
В противном случае установите соответствующий размер и скорость роста. Согласно примеру в случае восстановления на момент времени, вы можете использовать тот же код и логику, чтобы определить, какой размер файла является подходящим, и установить приемлемые параметры автоматического роста.
Некоторые вещи, которые вы не хотите делать
Создайте резервную копию журнала с параметром TRUNCATE_ONLY, а затем SHRINKFILE. С одной стороны, эта опция TRUNCATE_ONLY устарела и больше не доступна в текущих версиях SQL Server. Во-вторых, если вы используете модель восстановления FULL, это разрушит цепочку журналов и потребует новую полную резервную копию.
Отключение базы данных, удаление файла журнала и повторное присоединение . Я не могу подчеркнуть, насколько это может быть опасно. Ваша база данных может не восстановиться, она может появиться как подозрительная, вам, возможно, придется вернуться к резервной копии (если она у вас есть) и т. Д. И т. Д.
Использовать опцию «Сжать базу данных» . DBCC SHRINKDATABASE и вариант плана обслуживания, позволяющий сделать то же самое, - плохие идеи, особенно если вам действительно нужно только решить проблему журнала. Выберите файл, который хотите настроить, и отрегулируйте его независимо, используя DBCC SHRINKFILE или ALTER DATABASE ... MODIFY FILE (примеры выше).
Сократите файл журнала до 1 МБ . Это выглядит заманчиво, потому что, эй, SQL Server позволит мне делать это в определенных сценариях и смотреть на все свободное место! Если ваша база данных предназначена только для чтения (и это так, вы должны пометить ее как таковую, используя ALTER DATABASE), это просто приведет к множеству ненужных событий роста, поскольку журнал должен учитывать текущие транзакции независимо от модели восстановления. Какой смысл временно освобождать это пространство, просто чтобы SQL Server мог вернуть его медленно и мучительно?
Создать второй файл журнала . Это даст временное облегчение накопителю, который заполнил ваш диск, но это все равно, что пытаться починить проколотое легкое лейкопластырем. Вы должны работать с проблемным файлом журнала напрямую, а не просто добавлять еще одну потенциальную проблему. Помимо перенаправления некоторой активности журнала транзакций на другой диск, второй файл журнала действительно ничего не делает для вас (в отличие от второго файла данных), поскольку одновременно может использоваться только один из этих файлов. Пол Рэндал также объясняет, почему несколько файлов журналов могут кусать вас позже .
Будьте активны
Вместо того, чтобы сжимать ваш файл журнала до некоторого небольшого количества и позволить ему постоянно автоматически расти с небольшой скоростью, установите его на некоторый достаточно большой размер (тот, который будет соответствовать сумме вашего наибольшего набора одновременных транзакций) и установите разумный параметр автоматического увеличения в качестве запасного варианта, чтобы он не увеличивался в несколько раз для удовлетворения отдельных транзакций, и чтобы он был относительно редким для роста в обычных бизнес-операциях.
Наихудшие возможные настройки: 1 МБ или 10%. Как ни странно, это настройки по умолчанию для SQL Server (на которые я жаловался и просил изменений безрезультатно ) - 1 МБ для файлов данных и 10% для файлов журналов. Первое слишком мало в наше время, а второе каждый раз приводит к более длинным и продолжительным событиям (скажем, размер файла журнала составляет 500 МБ, первый рост - 50 МБ, следующий - 55 МБ, следующий - 60,5 МБ и т. д. и т. д. - и при медленном вводе / выводе, поверьте мне, вы действительно заметите эту кривую).
Дополнительная литература
Пожалуйста, не останавливайтесь здесь; в то время как большая часть рекомендаций, которые вы видите в отношении сокращения файлов журналов, по своей сути плоха и даже потенциально губительна, есть люди, которые больше заботятся о целостности данных, чем освобождают дисковое пространство.
Пост в блоге, который я написал в 2009 году, когда я увидел несколько постов «Вот как сжать файл журнала», * .
Сообщение в блоге, написанное Брентом Озаром четыре года назад и указывающее на несколько ресурсов, в ответ на статью в журнале SQL Server Magazine, в которой не была опубликована .
Сообщение в блоге Пола Рэндала, объясняющее, почему обслуживание t-log важно и , почему вы не должны сжимать файлы данных, либо .
У Майка Уолша есть отличный ответ, охватывающий также некоторые из этих аспектов, в том числе причины, по которым вы не сможете сразу сжать файл журнала .