Для управління віртуальними машинами в виробничому середовищі я використовую Virtual Machine Manager, причому розгорнутий в відмовостійкої конфігурації. Тому я трохи здивувався, коли в один прекрасний момент VMM виявився недоступний. Причину вдалося з'ясувати досить швидко - на диску, де розташовувалася база даних VMM, закінчилося місце.В результаті база впала, а разом з нею став недоступний і VMM. Як виявилося, місце зайняв розрісся до непристойних розмірів лог транзакцій, що досить дивно, адже база регулярно бекапіть за допомогою DPM 2012.

А тепер невеликий відступ для тих, хто (як і ки) не дуже близько знайомий з MS SQL.

Двигун MS SQL Database Engine ділить кожен фізичний лог-файл на кілька віртуальних файлів журналу. Віртуальні журнали не мають фіксованого розміру, кількість їх на один фізичний файл також не обмежена і визначається динамічно. При створенні бази логічний журнал починається на початку фізичного файлу, а нові записи додаються в кінець логічного журналу, який у міру заповнення наближається до кінця фізичного файлу.

Список транзакцій є перезаписуваними файлами. Для того, щоб забезпечити можливість перезапису, необхідно попередньо очистити віртуальні журнали, що знаходяться на початку файлу. Процедура ця називається Truncate (усічення) і виробляється або при досягненні контрольної точки (в простій моделі відновлення), або після створення резервної копії журналу (в моделі повного відновлення).Усічення звільняє ті віртуальні журнали, всі записи яких знаходяться перед мінімальним номером відновлення (MinLSN) і позначає їх як неактивні. MinLSN є реєстраційним номером найстарішою записи, яка необхідна для успішного відкату бази даних.

Якщо усічення проводиться досить часто, то в журналі завжди залишається місце для нових записів, і при досягненні логічним журналом кінця фізичного файлу нові записи знову починають записуватися в початок фізичного файлу.

Таким чином, при регулярному резервному копіюванні займане журналом місце повинно регулярно звільнятися для повторного використання. При відсутності ж регулярного бекапа для моделі повного відновлення можливі два варіанти:

• Якщо для лог-файлу не встановлено обмеження на максимальний розмір, то він продовжить збільшуватися до тих пір, поки залишається вільне місце на диску;
• Якщо ж розмір його обмежений, то після досягнення максимального розміру буде видана помилка.

І ще один важливий момент. Операція truncate хоча і перекладається як усічення, не змінює розмір фізичного файлу. Для того, щоб зменшити розмір файлу, використовується операція Shrink (стиснення), яка зменшує фізичний розмір лог-файлу за рахунок видалення неактивних віртуальних файлів журналу.Оскільки при стисненні лог-файлу видаляються тільки неактивні (тобто не містять логічного журналу) віртуальні файли журналу, то стиснення неможливо до тих пір, поки процедура усічення НЕ позначить один або кілька логічних журналів як неактивні.

перейдемо до DPM.

Під час налаштування резервного копіювання у властивостях групи є можливість вибрати тип бекапа - повний (Full Express Backup) або інкрементальний (Incremental backup).За замовчуванням відзначений пункт «Just before a recovery point». Це означає, що буде робитися тільки повний бекап, інкрементальний бекап при цьому не створюється.

А тепер увага. SQL виробляє усічення балки кожен раз при синхронізації DPM, тобто при інкрементальних резервних копій. При створенні повного бекапа усічення не проводиться і лог продовжує безперешкодно рости.Щоб лог усікається, необхідно в поле «Synchronization frequency» вибрати пункт «Every» і вказати режим відліку часу (періодичність створення інкрементальних копій).

Щоб не бути голослівним, наведу приклад. Ось так виглядав лог до настройки синхронізації, як бачите він займав майже 70Гб, з яких було вільно 0%.

А ось так ситуація змінилася після правильного налаштування і створення бекапа. Як бачите, тепер вільно 99% із займаного лог-файлом місця і можна стиснути його до прийнятного розміру.

Така ось історія. Сподіваюся, що ця стаття допоможе вам не наступити зайвий раз на ті ж граблі