Спасение утопающих – дело рук, а не ног

Фленов Михаил aka Horrific

Спецвыпуск: Хакер, номер #052, стр. 052-078-2

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

2. Full - полное резервирование. Самая мощная модель, при которой можно создавать промежуточные копии, например, резервировать журнал транзакций. Мощность модели заключается и в том, что базу можно восстановить в ее состоянии на любой момент времени. Например, если данные были разрушены в какой-то момент времени, то мы всего лишь восстанавливаем данные на момент за пять минут до трагического события - и все данные на родине. При этом журнал при резервировании не очищается и растет до тех пор, пока не будет явно зарезервирован, поэтому подготовься к хранению лишних данных на винчестере. У меня есть базы, в которых журнал за месяц вырастает так, что становиться больше файла данных. Кроме этого, база становится чувствительной к целостности журнала, и при ее нарушении восстановление последних изменений становится проблематичным.

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

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

Простое резервирование

Теперь поговорим о том, когда и что резервировать. Если ты выбрал для себя простую модель, то при создании резервной копии сможешь выбрать создание полной резервной копии (Database complete) или дифференцированной (Database differential).

Если выбрать Database complete, то создастся полная копия всех страниц данных базы. Если база занимает пару сотен мегабайт, то на простейшем сервере эта операция не отнимет много времени. А если размер достигает нескольких гигабайт? Если попытаться резервировать во время работы пользователей, то производительность резко упадет и от пользователей полетят жалобы на вечные тормоза. В этом случае резервные копии нужно создавать только в нерабочее время. Я рекомендую это делать после окончания рабочего дня, а лучше ночью: практика показывает, что в большинстве коммерческих контор понятия рабочего дня не существует и народ может работать до 24:00, пока работает метро и двигаются автобусы :).

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