от Mike Aubert

 Добро пожаловать в статью восьмую моей серии «Изучи сервер Windows SQL 2000 за 15 минут в неделю». Несколько недель назад мы впервые обсуждали резервное копирование баз данных. На этой неделе мы предпримем короткий обзор моделей восстановления и вплотную подойдем к тому, как разработать собственный план аварийного восстановления. Статья этой недели включает в себя следующие темы:

• Обзор моделей восстановления;
• Создание плана аварийного восстановления.

Обзор моделей восстановления

Как вы, наверное, уже успели заметить по мере изучения нами сервера SQL, многие настройки и установки действуют не всегда так, как нам того хотелось бы. Другими словами, мы должны взвесить все за и против, прежде чем предпочесть выбор одной установки над другой. Хорошей иллюстрацией этой мысли может служить выбор модели восстановления из предыдущей статьи данной серии. Некоторые модели позволяют проводить быстрое резервное копирование и использовать для этого меньшее количество дискового пространства, но при этом они не смогут обеспечить все допустимые опции для других моделей восстановления. Так как модели восстановления являются важнейшей частью стратегии резервного копирования, я предприму короткий обзор трех моделей восстановления, доступных на сервере SQL 2000.

– Простая:

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

– Полная:

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

– Регистрация групповых операций (bulk_logged):

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

Создание плана аварийного восстановления

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

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

Когда мы ознакомились с журналом производительности (performance log), мы увидели, что использование сервера снижается в период времени с 2 до 3 часов во все дни, кроме воскресенья и в течение всего воскресенья.

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

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

И последний тип резервного копирования, который мы должны принять во внимание, это резервное копирование журнала транзакций. И снова, так как данные в этой базе данных чрезвычайно важны для компании, вы можете осуществлять резервное копирование журнала транзакций в течение всего дня несколько раз. Резервное копирование журнала транзакций обычно не требует много системных ресурсов, поэтому мы можем выполнять его без особого влияния на систему. В нашем сценарии мы будем осуществлять резервное копирование журнала транзакций каждые 30 минут.

На этой схеме приведен план нашего резервного копирования без учета резервного копирования журнала транзакций.

Этот план, конечно, не идеален – у него есть свои преимущества и недостатки. К его достоинствам относится то, что эта стратегия выполняет полное/дифференциальное резервное копирование во время наименьшей загрузки сервера. С другой стороны, если сбой произойдет ближе к вечеру, вам придется использовать при восстановлении множество резервных копий журнала транзакций. Кроме того, вы можете решить, что потеря данных, вносимых в течение 30 минут до следующего резервного копирования журнала, слишком дорогая цена – все зависит от того, чем вы готовы (или не готовы) рисковать.

Другая вещь, которую вы должны принимать во внимание – это то, что время выполнения резервного копирования может быть различным. Используйте наш сценарий только как пример, потому что дифференциальное резервное копирование будет копировать все данные, которые были изменены с момента последнего полного резервного копирования. Пятничное дифференциальное копирование возможно будет содержать больше измененных данных, чем выполненное в понедельник. Почему? Если вы изменяете одни и те же данные снова и снова, дифференциальная резервная копия будет оставаться того же размера, не зависимо от того, будете ли вы выполнять копирование сегодня или через две недели. С другой стороны, если вы изменяете/добавляете разные данные, размер дифференциальной копии будет продолжать расти, до тех пор, пока вы не предпримете полного резервного копирования.

Итак, можем ли мы улучшить нашу стратегию резервного копирования? При полном резервном копировании, занимающем 4 часа и большем количестве ресурсов сервера… не очень сильно. В моей следующей статье мы рассмотрим некоторые другие опции, которые помогут улучшить наш план, но сегодня мы исчерпали наш лимит времени.

Теперь, когда мы решили, как часто мы будем выполнять резервное копирование нашей базы данных, пришло время задуматься о том, где мы будем хранить наши резервные копии… и именно об этом мы будем говорить на следующей неделе во второй части статьи «Создание плана аварийного восстановления». И как всегда…если у вас возникнут какие-либо технические вопросы, пожалуйста, присылайте их на доску объявлений сайта 2000Trainers.com SQL message board. Нетехнические вопросы, комментарии и обратная связь – по адресу моей электронной почты. Я надеюсь, что вы найдете эти статьи полезными и был бы рад узнать ваше мнение о них.

Mike Aubert, MCSE, MCDBA,  MCSD.