Заметки о Windows и других программных продуктах Microsoft...

Особенности настройки DPM 2012 для бэкапа MS SQL

Особенности настройки DPM 2012 для бэкапа MS SQL

Для управления виртуальными машинами в производственной среде я использую 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% из занимаемого лог-файлом места и можно сжать его до приемлемого размера.

размер лога после бэкапа

 

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

 
 
Комментарии

Privet,
U sebia v srede ispolzujem DPM dlia backupirovanija SQL baz dannyh. S odnoj iz baz estj problemy s logom. Problema zakliuchaetsia v tom cto dazhe posle incremental backup’a kotoryj proishodit kazhdyje 4 chasa. Log vseravno ne truncate’titsia. V nachale u bazy stojal recovery mode — simple kotoryj byl pomenian na full i posle etogo baza zanovo byla dobavlena v protection gruppu na DPM tolko togda nachalisj delatsia incremental backup’y, no vot log pochemu to prodolzhaet rosti ne pokazyvaja obsolutno svobondnogo mesta. Mozhet estj kakie nibudj mysli po etomu povody?

Так не отвечу, надо смотреть. Для начала стоит заглянуть в логи DPM и SQL-серверов на предмет ошибок.

Андрей, нужно после изменения режима базы SQL с SIMPLE на FULL в DPM зайти в группу защиты и удалить, и заново добавить измененные базы данных SQL. Тогда DPM поймет, что произошли изменения и будет выполнять синхронизацию с усечением логов.

Также рекомендую к прочтению
DPM–SQL transaction logs do not truncate — http://jeffwouters.nl/index.php/2012/03/dpmsql-transaction-logs-do-not-truncate/

acidborn60

Обычно не усекается лог даже после нескольких бэкапов лога из-за того, что есть открытая транзакция. Можно посмотреть dbcc opentran.
Но в целом шринк не совсем хорошая опция, потом будете тратить ресурсы на автоприрост. В довесок, исходя из настройки автоприроста, ещё и доп. фрагментацию можно поймать. Лучше бэкапьте журнал, а Бд не шринкуйте.