Уменьшение Журнала транзакций?
NTFS резервирует 12,5% объема (он кажется, что это - примерно объем на 54 ГБ) для MFT, когда объем отформатирован (если Вы не переопределяете это поведение). Это предотвращает фрагментацию MFT. При 4%-м использовании Вашего MFT это кажется, что Вы не находитесь ни в какой опасности заставить NTFS выделять дополнительное место для MFT.
Если место, выделенное для MFT, будет израсходовано, то NTFS выделит дополнительное место для MFT. Функциональность "Дефрагментатора диска" в Windows XP и Сервере Windws, 2003 (по-видимому, также в более новых версиях Windows) может дефрагментировать MFT, таким образом, призрак фрагментации MFT, которая была большим соглашением в период времени NT 4.0, не является таким грандиозным предприятием сегодня.
В основном у Вас нет ничего для волнения о.
См. http://support.microsoft.com/kb/174619 для фона от Microsoft.
Почему должен Вы? При нормальных обстоятельствах это будет jsut вырастать снова снова так или иначе до th enext резервное копирование. Плюс он фрагментирует файл, который плох для производительности. Лучшие практики говорят для не использования, авторастут, который автоматически значит не для материала shring так, чтобы он потребовал роста.
При использовании резервных копирований журнала транзакций для баз данных в ПОЛНОЙ модели восстановления, Вы будете контролировать журнал транзакций и не должными быть уменьшать ее. Вы найдете особые случаи, что Вы укомплектовываете потребность сделать это, но никогда регулярно.
Уменьшение журнала не является столь же злым как уменьшение файла данных. Сделайте это, только если база данных находится в Простой модели восстановления, и файл вырос слишком много после определенной операции к значению Вы знаете, что это не вырастет снова. Можно уменьшить его к данному значению, таким образом, это не выделяет место снова при следующей транзакции, которая заставит производительность быть замедленной. Не делайте этого на регулярной основе.
Если база данных полностью, необходимо сделать журналы резервного копирования регулярно.
Все зависит от того, что вы имеете в виду под вопросом.
Вообще говоря, не следует » Нет необходимости регулярно сжимать журнал транзакций.
Однако иногда это необходимо для его дефрагментации или для восстановления пространства после неконтролируемой транзакции.
Фрагментация
Этот код покажет вам внутреннюю структуру вашего журнала транзакций.
-- 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 не окажется в начале или около начала журнала транзакций.
Shrinking It
Запустите этот код, чтобы сжать файл журнала.
- сжать файл, уменьшив количество 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.