SQL101: Изменение модели восстановления

Примечание от переводчика: цифрой 101 в американских колледжах обычно обозначается вводный курс, дающий базовые знания о предметной области.

SQLskills запускает новую инициативу по размещению записей с базовыми знаниями, мы назвали ее SQL101. Мы будем писать о вещах, которые, как мы часто видим, делаются неправильно, технологиях, которые используются неверно, и о многих недопониманиях, которые приводят к серьезным проблемам. Если вы хотите найти все записи в этой серии, проверьте ссылку SQLskills.com/help/SQL101 ^[1] (английский).

Одна из вещей, которая может подстерегать вас при администрировании — это эффект от временного переключения из полной модели восстановления на другую. В этой статье я кратко опишу три модели восстановления и проблемы, которые могут возникнуть при переключении из полной модели в простую и из полной в модель с неполным протоколированием (bulk-logged).

Модели восстановления

Есть три модели восстановления:

• Полная модель восстановления (используется по умолчанию и чаще всего)
  • Все изменения в базе полностью журналируются. Это не означает, что каждое изменение имеет отдельную запись в журнале, поскольку некоторые операции пишутся с меньшим количеством записей в журнале, но тем не менее журналируется полный эффект от операции (например, операция TRUNCATE TABLE — смотрите здесь полное объяснение ^[2] (английский)).
  • Журнал транзакций не будет очищаться (т.е. его части не станут доступными для переиспользования) до тех пор, как не будет сделана резервная копия журнала транзакций(смотрите здесь полное объяснение ^[3] (английский)).
  • Все опции восстановления доступны, когда база данных в полной модели восстановления (и была в ней с момента создания последней резервной копии).

• Модель восстановления с неполным протоколированием
  • Некоторые изменения (такие как перестроение индекса или пакетная загрузка, но НЕ стандартные INSERT/UPDATE/DELETE) могут минимально журналироваться, что снижает количество записей в журнале и журнал транзакций не становится слишком большим за время выполнения этих операций. Обратите внимание, что это не изменяет размер последующих резервных копий журнала транзакций. Для получения полных инструкций, как сделать ваши операции минимально журналируемыми, смотрите документ «Data Loading Performance Guide» ^[4] (английский), который описывает все возможные условия, которые должны быть соблюдены.
  • Журнал транзакций не будет очищаться (т.е. его части не станут доступными для переиспользования) до тех пор, как не будет сделана резервная копия журнала транзакций (абсолютно так же, как и при полной модели восстановления).
  • Используя модель восстановления с неполным протоколированием, вы теряете часть опций по восстановлению (восстановление на момент времени и резервная копия заключительного фрагмента) в обмен на повышение производительности, связанное с минимально журналируемыми операциями.

• Простая модель восстановления
  • Некоторые изменения могут минимально журналироваться (абсолютно так же, как и при модели восстановления с неполным протоколированием).
  • Журнал транзакций не будет очищаться до выполнения операции создания контрольной точки (CHECKPOINT) — обычно она выполняется автоматически.
  • Создание резервных копий журнала транзакций невозможно, поэтому у вас остается самое ограниченное число опций по восстановлению.

Большинство людей использует полную модель восстановления, чтобы иметь возможность создавать резервные копии журнала транзакций и позволить себе все возможные опции восстановления. Главная вещь, которую вы должны помнить, когда ваша база использует полную модель восстановления или модель с неполным протоколированием — вы должны периодически создавать резервные копии журнала транзакций или журнал транзакций будет расти бесконечно.

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

Переключение в простую модель восстановления

Часто я слышу от людей, что они переключаются в простую модель восстановления чтобы избежать роста журнала транзакций при выполнении пакетной загрузки или перестроения индексов, тогда как то, что им действительно нужно — это модель с неполным протоколированием. Также есть устойчивые мифы о том, что какие то регулярные операции *требуют*, чтобы модель восстановления была простой — это просто (ха ха) неправда.

Переключение в простую модель восстановления разрывает цепь резервных копий журнала транзакций, требуя создания полной или разностной резервной копии перед дальнейшим созданием резервных копий журнала транзакций.

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

• Полная резервная копия после переключения в простую модель восстановления, разностные резервные копии после этой полной (если вы используете разностные резервные копии) и любые резервные копии журнала транзакций с тех пор, как вы переключились обратно из простой модели; или
• Самая последняя полная резервная копия перед переключением в простую модель восстановления плюс последняя разностная копия после переключения назад из простой плюс любые резервные копии журнала транзакций

Если эта самая последняя полная резервная копия (перед или после переключения в простую модель восстановления) повреждена, вы не можете восстановиться. Вы не можете взять предыдущую полную резервную копию, потому что она позволит вам восстановиться только до момента переключения в простую модель восстановления, но не после. Хорошо, я думаю, вы можете так сделать, но вы потеряете всю работу с момента переключения в простую модель восстановления.

Переключение в простую модель восстановления — это не то, что вы делаете автоматически или регулярно. Единственный момент, когда вы можете временно это сделать, это когда ваш журнал транзакций переполнился и у вас нет ни единой возможности очистить его (например, вы не можете сделать его резервную копию или добавить еще один файл журнала), кроме как переключиться в простую модель восстановления и принудительно вызвать операцию создания контрольной точки. В этом случае вы предпринимаете радикальные меры, чтобы позволить работать с базой, и полностью осведомлены о тех ограниченных возможностях для восстановления, которые у вас теперь есть.

До тех пор, пока вы не попали в эту аварийную ситуацию, вы или решаете использовать простую модель восстановления на постоянной основе, или не должны переключаться на нее никогда.

Переключение в модель восстановления с неполным протоколированием

Переключение к неполному протоколированию в процессе загрузки или обслуживания индексов приемлемо, чтобы избежать роста журнала транзакций. На самом деле, переключение туда и обратно между полной моделью восстановления и моделью с неполным протоколированием никаким образом не влияет на цепь резервных копий журнала транзакций. И такое переключение не влияет на доставку журналов (log shipping) или репликацию, но вы не можете переключаться из полной модели восстановления когда используете зеркалирование базы данных или группы доступности AlwaysOn, поскольку они требуют полной модели восстановления.

Тем не менее, использование модели восстановления с неполным протоколированием может вызвать проблемы для восстановления при сбоях, так что даже если вы хотите использовать такую модель восстановления из-за ее особенностей, вы можете отказаться от ее использования чтобы избежать рисков потери части возможностей по восстановлению.

Проблема 1: резервная копия журнала транзакций, которая содержит минимально журналируемую операцию, не может использоваться в восстановлении на момент времени. Это значит, что время, которое вы указываете в пункте WITH STOPAT в команде по восстановлению не может быть временем, которое принадлежит к такой резервной копии. Вы можете использовать такую резервную копию как часть цепочки восстановления и остановиться на любом времени после нее (если только это время не относится к другой резервной копии, которая также содержит минимально журналируемые операции, конечно), но не во время, принадлежащее этой резервной копии.

Проблема 2: Если вам необходимо выполнить резервную копию заключительного фрагмента, чтобы захватить все записи журнала транзакций, созданные с момента последней запланированной резервной копии журнала транзакций, при этом файлы данных недоступны или повреждены, и записи журнала транзакций, резервную копию которых необходимо сделать, содержат минимально журналируемые операции, то при создании такой резервной копии вы получите ошибку в версиях до SQL Server 2008 R2, и начиная с версии SQL Server 2008 R2 вы получите успешно созданную резервную копию, которая повредит базу данных, если будет восстановлена.

Поэтому, если вы собираетесь использовать модель с неполным протоколированием, чтобы сохранить место в журнале транзакций в момент больших операций, вам необходимо убедиться, что а) нет никакой вероятности, что вы захотите восстановиться на момент времени между последней и следующей за ней резервной копией журнала транзакций; и б) в базе не произойдет никаких изменений, которые вы не сможете повторить в случае, если произойдет сбой и вы не сможете сделать корректную резервную копию заключительного фрагмента.

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

Краткое изложение

Для каждой базы данных, за которую вы ответственны, убедитесь, что вы понимаете следствия изменения модели восстановления, поскольку такое изменение может привести к проблемам восстановления при сбоях.

Автор: Алексей Бородин

Источник ^[5]