Почему не рекомендуется уменьшать журнал транзакций?
Все зависит от того, что вы имеете в виду под вопросом.
Вообще говоря, вам не нужно регулярно сжимать журнал транзакций.
Однако иногда это необходимо для его дефрагментации или для восстановления пространства после неконтролируемой транзакции.
Фрагментация
Этот код покажет вам внутреннюю структуру вашего журнала транзакций.
-- get list of VLFs
use AdventureWorks2008R2
go
dbcc loginfo
go
Вы хотите, чтобы все ваши VLF имели одинаковый размер. Если у вас есть процентный или очень маленький рост, вы получите фрагментированный журнал транзакций.
Кроме того, не слишком мало и не слишком много. См. Эту статью: http://www.sqlskills.com/blogs/kimberly/post/Transaction-Log-VLFs-too-many-or-too-few.aspx
Итак, у вас есть сотни или тысячи VLF? Все они разных размеров? Если это так, ваш журнал транзакций фрагментирован.
Исправляем это
При сжатии файла данных он фрагментируется. При сжатии журнала транзакций он дефрагментируется.
Запустите этот код еще раз:
-- get list of VLFs
use AdventureWorks2008R2
go
dbcc loginfo
go
Строка со статусом 2 - это активный VLF. Вероятно, это где-то посередине, мы хотим это в начале. Вы не сможете сжать журнал за пределами местоположения активного VLF.
Выполните задание резервного копирования журнала несколько раз. Затем снова запустите приведенный выше код. Продолжайте делать это, пока активный VLF не окажется в начале журнала транзакций или около него.
Сокращение его
Запустите этот код, чтобы сжать файл журнала.
- сжать файл, уменьшив количество VLF, тем самым дефрагментируя журнал транзакций dbcc shrinkfile ('AdventureWorks2008R2_Log', 1) go
Затем вернитесь и запустите приведенный выше код, чтобы проверить свои VLF. Вы должны увидеть уменьшение количества VLF.
Возможно, вам придется повторить процедуру резервного копирования / сжатия журнала несколько раз.
Размер его
После того, как ваша система проработает несколько бизнес-циклов, у вас должно появиться хорошее представление о ее естественном размере. Таким образом, вы измените его размер после сжатия / дефрагментации.
Сначала установите рост:
-- manually set the growth
use master
go
alter database AdventureWorks2008R2
modify file (name = 'AdventureWorks2008R2_Log', filegrowth = 512000kb)
go
Затем задайте размер:
-- manually set the log size
use master
go
alter database AdventureWorks2008R2
modify file (name = 'AdventureWorks2008R2_log', size = 4096000kb)
go
Ваши цифры, конечно, будут другими. Во-первых, если ваш журнал будет большим, например 32G, не устанавливайте его сразу. Вместо этого увеличьте его до 8G, затем до 16G, 24G, 32G.
Еще одна вещь: избегайте кратных 4G, чтобы избежать ошибки 4G. Ссылка здесь: http://www.sqlskills.com/BLOGS/PAUL/post/Bug-log-file-growth-broken-for-multiples-of-4GB.aspx
Поэтому я использую 4000 МБ или 8000 МБ и т. Д.
Autogrow и MaxSize
Хотя вы хотите вручную изменять размер файлов, оставьте включенным Autogrow, чтобы вас не поймал мошеннический процесс.
Обычно я не рекомендую устанавливать MaxSize, если у вас нет нескольких журналов транзакций, использующих один и тот же LUN, или если у вас есть база данных, которая регулярно выполняет сумасшедшие запросы, заполняющие диск.
Почему должен ты? При нормальных обстоятельствах он все равно будет расти снова до следующей резервной копии. Кроме того, он фрагментирует файл, что плохо сказывается на производительности. ЛУЧШИЕ практики говорят, что не следует использовать автоматическое выращивание, что автоматически означает, что не следует измельчать материал, так как он требует роста.
Уменьшение журнала не так страшно, как сжатие файла данных. Делайте это только в том случае, если база данных находится в простой модели восстановления и файл слишком сильно вырос после определенной операции до значения, которое, как вы знаете, больше не будет расти. Вы можете уменьшить его до заданного значения, чтобы он не выделял пространство снова при следующей транзакции, что приведет к снижению производительности. Не делайте этого регулярно.
Если база данных находится в состоянии «Полная», вам следует регулярно делать резервные копии журналов.
Если вы используете резервные копии журнала транзакций для баз данных в модели ПОЛНОГО восстановления, вы будете держать журнал транзакций под контролем, и вам не нужно будет его сжимать. Вы найдете особые случаи, когда вам нужно это делать, но никогда на регулярной основе.