от Mike Aubert

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

• Почему важно выполнять резервное копирование?
• Типы резервного копирования баз данных.
• Модели восстановления баз данных.
• Создание резервной копии.

Почему важно выполнять резервное копирование?

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

Почему бы просто не использовать конфигурацию дисков RAID, которая обеспечивает создание зеркала с целью защиты данных? Массивы RAID являются только первой ступенью в деле обеспечения защиты данных от потери. В зависимости от конфигурации массива RAID, один или даже несколько жестких дисков должны выйти из строя, прежде чем произойдет безвозвратная потеря данных. Кроме того, использование дисков «горячей» замены и горячего резерва может быть использовано для того, чтобы сервер продолжал работать без отключения даже в случае выхода из строя жесткого диска. Ключевая вещь, которую вы должны знать, это то, что массивы RAID могут защитить ваши данные в случае выхода из строя жестких дисков… А что случится, если будет пожар или какое-либо стихийное бедствие? Что вы будете делать, если файлы вашей базы данных окажутся повреждены в результате ошибки программного обеспечения или аппаратного сбоя? Или что будет, если пользователь удалит данные, которые вдруг потребуются в дальнейшем? Конфигурация RAID не сможет помочь вам в этих случаях.

Помните – вы можете всегда заменить сервер, но данные этого сервера восстановить чрезвычайно трудно, иногда просто невозможно.

Типы резервного копирования баз данных

Сервер SQL поддерживает три вида резервного копирования: Полное (Full), Разностное или Дифференциальное (Differential) и копирование журнала (Log). В дополнение к трем основным видам резервного копирования, которые работают со всей базой данных в целом, есть также несколько дополнительных типов резервного копирования, которые используются для копирования одного файла или группы файлов.

Полное резервное копирование – создает полную резервную копию всех экстентов базы данных. Если вы будете восстанавливать базу данных, используя для этого полную резервную копию, потребуется только самый последний созданный вами экземпляр. Однако, полное резервное копирование – самый медленный тип резервного копирования.

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

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

Следует заметить, что резервное копирование обычно осуществляется при работающей (online) базе данных. Этот процесс называется «размытое “fuzzy” резервное копирование», потому что он выполняется на протяжении некоторого отрезка времени. Если в процессе резервного копирования экстентов базы данных происходят какие-либо изменения, процесс копирования безусловно продолжается. Для поддержания целостности, полное и разностное резервное копирование фиксирует ту часть файла журнала транзакций, которая соответствует времени от начала и до конца резервного копирования.

Сервер SQL может выполнять резервное копирование в файл, расположенный на вашем жестком диске, на сетевом диске, на устройстве с магнитной лентой или в именованном канале.

Модели восстановления баз данных

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

Каждая база данных, запущенная на сервере SQL может придерживаться одной из трех моделей восстановления: Полной (Full), Регистрации пакетных операций (Bulk_Logged – к сожалению, перевода названия этой модели пока нет, поэтому название условно- бесплатное :), и Простой (Simple).

В случае модели полного восстановления, каждое изменение, сделанное в базе данных заносится в журнал. Все операторы UPDATE, DELENT и INSERT вносятся в журнал. Кроме того, известные пакетные операторы, такие как BULK INSERT, которые используются для того, чтобы проделать много изменений за короткий отрезок времени, также заносятся в журнал полностью (т.е. каждая отдельная строка, добавленная при помощи оператора BULK INSERT будет зафиксирована в журнале).

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

Если модель полного восстановления отслеживает все изменения, сделанные в базе данных и позволяет нам восстанавливать все транзакции к любому моменту времени, почему бы нам не использовать эту модель всегда? Так как все операторы должны при этом фиксироваться полностью, вы можете получить в итоге достаточно здоровенный файл журнала. Кроме того, такие команды как BULK INSERT будут замедлять работу сервера, так как все выполняемые ими изменения должны вноситься в журнал.

Модель регистрации пакетных операций (bulk_logged) достаточно похожа на модель полного восстановления с некоторые добавлениями и преимуществами. Как и в полной модели восстановления, в модели регистрации пакетных операций также фиксируются все операторы UPDATE, DELETE и INSERT. Однако, для определенных команд, в данная модель фиксирует лишь то, что операция имела место. Это верно для таких команд как BULK INSERT, bcp, CREATE INDEX, SELECT INTO, WRITETEXT и UPDATETEXT. Модель регистрации пакетных операций похожа на модель полного восстановления тем, что не использует повторно (не перезаписывает) пространство журнала до тех пор, пока не будет произведено резервное копирование всех транзакций.

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

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

И последний тип модели восстановления – это простая модель восстановления. В отличие от полной и bulk_logged модели восстановления, простая модель восстановления не использует резервное копирование журнала транзакций. В данной модели журналы транзакций часто усекаются (усечение – это процесс удаления старых транзакций из журнала) автоматически. Модель простого восстановления может использовать полное и разностное резервное копирование.

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

Для изменения модели восстановления для базы данных, в Диспетчере Предприятия (Enterprise Manager) нужно щелкнуть правой кнопкой мыши на значке базы данных, выбрать из появившегося меню Properties и затем перейти на вкладку Options. Вы также можете использовать оператор ALTER DATABASE для изменения модели восстановления.

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

Осуществление резервного копирования

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

Для того чтобы осуществить резервное копирования при помощи Диспетчера Предприятия, щелкните правой кнопкой мыши на значке базы данных, выберите в появившемся меню All Tasks (все задачи) и в этом подменю Backup Database (Резервное копирование базы данных).

Также вы можете использовать мастер Create Database Backup Wizard, выбрав в меню Tools Диспетчера Предприятия Wizard…, и затем Backup Wizard.

Третий способ проведения резервного копирования вашей базы данных осуществляется при помощи оператора BACKUP. Для того, чтобы узнать больше об этом операторе, посмотрите справочную систему сервера SQL – Book online.

Мы поговорим больше о резервном копировании на следующей неделе, но если вам очень не терпится, можете пока посмотреть следующую ссылку: http://msdn.microsoft.com/library/en-us/adminsql/ad_bkprst_9zcj.asp

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

Mike Aubert, MCSE, MCDBA,  MCSD.