авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 13 | 14 || 16 | 17 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 15 ] --

Каждое из приведенных средств имеет свои недостатки и преимущества. На пример, технологии RAID (Redundant Array of Independent Disks) обеспечивают работоспособность системы в случае небольших сбоев в функционировании дисковой системы, но при выходе из строя всего компьютера на помощь прихо дит резервный сервер или кластер. Когда же все серверы повреждены, и нет возможности восстановить данные ни с одного из них, то остается лишь обра титься к резервной копии.

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

Замечание } ( Технологии дублирования, зеркального отображения и чередования с контролем четности, предназначенные для обеспечения отказоустойчивости дисковых масси вов RAID, будут рассмотрены в разд. "Технология RAID" главы 16.

Эта глава полностью посвящена рассмотрению работы с подсистемой резерв ного копирования.

Введение в резервное копирование Резервное копирование (back up) является одним из самых надежных способов защиты данных от потери. Технологии RAID обеспечивают функционирование системы при выходе из строя одного из жестких дисков или даже дискового контроллера. Но они бессильны в случае выхода из строя оперативной памяти, центрального процессора или сетевой карты. В этом случае пользователи не смогут получить с сервера данные. Решением проблемы будет использование резервного сервера или кластера. Но предположим, что информация на всех серверах была уничтожена. Чтобы иметь возможность восстановить данные, не обходимо иметь полную их копию. Такая копия данных называется резервной (backup), и ни пользователи, ни система не имеют к ней доступа. Отдельно не обходимо отметить, что резервная копия имеет значительно меньший размер по сравнению с исходной базой данных. Часто процесс создания резервной копии также называют архивированием.

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

(" Замечание ^ Часто архивирование используется для переноса баз данных между серверами SQL Server 2000. База данных архивируется на исходном сервере на какой-нибудь носи тель, который затем рассылается на другие серверы. На удаленном сервере адми нистратор восстанавливает базу данных и может успешно с ней работать. Однако при выполнении подобного переноса следует учесть, что база данных может быть восстановлена только на SQL Server 2000, имеющем те же параметры кодовой страницы, порядка сортировки и сопоставления Unicode, что и переносимая база данных. В противном случае SQL Server 2000 выдаст соответствующее сообщение о невозможности восстановления БД.

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

Кроме того, если при создании резервной копии пользователи продолжают ра ботать с данными, то к моменту завершения резервирования уже скопирован ные данные могут быть изменены, что способно привести к нарушению целост ности информации. Во избежание подобных проблем SQL Server автоматически отслеживает изменения в уже скопированных данных и обновля ет их. Однако если резервирование длится слишком долго, то пользователи не смогут полноценно работать с данными. Необходимо каким-либо образом со кратить время архивирования, гарантируя при этом полноту резервной копии.

SQL Server 2000 поддерживает различные типы резервного копирования, позво ляя администратору очень гибко управлять данным процессом. Существует:

П полная копия;

П разностная копия;

П копия журнала транзакций;

П резервное копирование файлов и групп файлов.

Каждый из упомянутых типов будет подробно рассмотрен в следующих разделах.

С~ Замечание ^ Необходимо сразу отметить, что создаваемые средствами SQL Server 2000 резерв ные копии не упаковываются в полной мере. Хотя после архивирования базы дан ных и будет получен единственный файл, его можно дополнительно уплотнить про фессиональным архиватором, таким как, например ARJ, RAR или ZIP. С помощью подобных утилит архивы SQL Server 2000 могут быть сжаты еще примерно в 10 раз.

Полная копия Полная копия базы данных (database backup) является стандартным типом резерв ного копирования. Этот тип резервирования предполагает полное копирование 18 За*. 528 Часть III. Администрирование всей информации, имеющейся в базе данных. В качестве приемника данных может выступать либо обычный файл, либо специальное устройство резервного копирования, такое как стример, магнитооптический или ZIP-диск.

Замечание Работа с приемниками данных будет рассмотрена отдельно далее в этой главе.

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

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

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

Как уже говорилось, SQL Server 2000 автоматически отслеживает изменения в уже скопированных данных и обновляет их в архиве. В результате к моменту завершения резервного копирования состояние данных в архиве будет соответ Глава 13. Резервное копирование ствовать информации в исходной базе данных. Это гарантирует целостность и достоверность данных.

(~ Замечание ) При архивировании полной копии данных SQL Server 2000 не выполняет усечение (truncate) журнала транзакций. Со временем журнал транзакций может перепол ниться, и работоспособность системы будет нарушена. Администратор должен либо вручную выполнять усечение с помощью команды BACKUP LOG С использованием опции TRUNCATE_ONLY, либо возложить эту обязанность на систему. В последнем случае для базы данных необходимо установить свойство Truncate log on checkpoint. Это можно сделать как с помощью Enterprise Manager, открыв окно свойств базы данных, так и с помощью хранимой процедуры sp_dfcoption.

Существует ряд операций, которые не могут выполняться одновременно с про цессом создания резервной копии. Приведем список этих операций:

П создание и удаление файлов базы данных;

П создание индексов;

• выполнение операций, нерегистрируемых в журнале транзакций;

• автоматическое или ручное уменьшение (shrinking) базы данных или ее файлов.

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

Разностная копия Разностное, или дифференциальное резервное копирование (differential database backup) было разработано с целью уменьшения времени, необходимого для по лучения копии базы данных. В основе дифференциальной копии лежит отсле живание изменений, вносимых пользователями в базу данных. Создание диф ференциальной копии состоит из двух этапов:

• создание полной копии данных;

П создание собственно дифференциальной копии.

Полная копия базы данных является отправной точкой, начиная с которой сис тема может отслеживать изменения. Изменения отслеживаются на уровне стра ниц. Каждая страница имеет флаг архивирования, который сбрасывается при создании полной копии и устанавливается, если данные на странице были из менены. Это можно сравнить с атрибутом архивирования для файлов. При соз дании резервной копии 1 атрибут снимается, но если файл изменяется, то систе ма автоматически устанавливает его. Программа резервного копирования ищет все файлы с установленным атрибутом архивирования и копирует их. Анало Не путайте с программами архивации данных типа ARJ, RAR или ZIP. — Ред.

18» • 530 Часть III. Администрирование гично ведет себя и подсистема резервного копирования SQL Server 2000. Однако необходимо отметить, что флаг архивирования для страниц данных снимается только при создании полной копии данных. Это означает, что при создании последовательно нескольких дифференциальных копий каждая следующая будет полностью включать страницы, которые были включены в предыдущую копию плюс все страницы, измененные со времени создания предыдущей копии. По этому актуальна только самая последняя дифференциальная копия. Достаточно применить ее после восстановления полной резервной копии, чтобы целиком восстановить систему.

Замечание Как и в случае с полным копированием, SQL Server 2000 не выполняет усечения журнала транзакций.

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

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

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

Решением подобных проблем является применение резервного копирования жур нала транзакций (transaction log backup). Этот тип резервного копирования по зволяет сохранять информацию обо всех транзакциях, выполненных в базе дан Глава 13. Резервное копирование ных. В итоге резервная копия содержит непрерывную цепочку изменений, ко торые претерпели данные со времени последнего архивирования. Такая цепочка позволяет восстановить систему в состоянии, в котором она была в любой мо мент времени, и этот момент отображен в резервной копии. При восстановле нии резервной копии журнала транзакций SQL Server 2000 последовательно вы полняет все изменения, выполненные пользователями в базе данных.

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

Замечание Необходимо следить за соответствием времени создания полной и разностной ко пии и времени создания копии журнала транзакций. Если журнал транзакций содер жит информацию обо всех изменениях данных, начиная с 10 часов утра, а разност ная копия была создана в 8 часов утра, то восстановление системы может закончиться неудачей. Действительно, за те два часа, которые не отражены ни в одной резервной копии, база данных могла претерпеть значительные изменения.

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

Если вы планируете применять резервное копирование журнала транзакций, необходимо следить за тем, чтобы в нем отображалась информация обо всех транзакциях, выполненных в базе данных, и чтобы эта информация была не прерывной. При этом нельзя устанавливать для базы свойство t r u n c. log on chkpt (Truncate transaction log on checkpoint). При установке этой опции SQL Server 2000 периодически удаляет из журнала транзакций информацию об уже завершенных (неактивных) транзакциях. Данная операция называется усечением (truncate). Усечение приведет к тому, что информация о транзакциях окажется потерянной, и будет нарушена непрерывность цепочки изменений, отображае мой в резервной копии журнала транзакций.

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

При резервном копировании журнала транзакций SQL Server 2000 автоматиче ски выполняет усечение журнала транзакций после завершения создания архи ва. То есть размер журнала транзакций будет автоматически поддерживаться на 532 Часть III. Администрирование нормальном уровне. Еще раз заметим, что ни пользователь, ни SQL Server не должны выполнять усечения журнала транзакций. Иначе целостность ин формации об изменениях в базе данных будет нарушена. Операция усечения должна выполняться только после завершения создания резервной копии жур нала транзакций. Следующий архив будет содержать только те транзакции, ко торые были выполнены после завершения создания последней резервной копии журнала транзакций.

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

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

При создании резервной копии журнала транзакций SQL Server 2000 включает в архив только те транзакции, которые были завершены к моменту окончания создания резервной копии. Если транзакция была завершена на 99% к моменту создания архива, то она все равно не будет включена в резервную копию. Одна ко при выполнении усечения журнала транзакций эта транзакция не будет уда лена из журнала и при следующем архивировании журнала транзакций будет включена в архив.

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

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

Резервное копирование файлов и групп файлов Это последний из типов резервного копирование SQL Server 2000. Как уже было сказано, база данных состоит из одного или более файлов данных и одного или более файлов журнала транзакций. То есть любая база данных состоит минимум Глава 13. Резервное копирование из двух файлов. Ни полное, ни резервное копирование не позволяют архивиро вать только часть данных, например, только данные без индексов или только столбцы типа image, t e x t и ntext. Резервная копия журнала транзакций ото бражает лишь операции изменения данных.

SQL Server 2000 позволяет выполнять частичное архивирование данных. Для этого администратор должен использовать копирование файлов или групп фай лов. Такой подход позволяет контролировать диапазон архивируемых данных вплоть до конкретного столбца таблицы. В основе этого подхода лежит возмож ность привязывания таблицы или даже отдельного столбца к конкретному фай лу или группе файлов. Все данные, принадлежащие столбцу, будут размещаться только в указанном файле или группе файлов. Обычно к файлу или группе фай лов привязываются либо таблицы целиком, либо столбцы с типом данных im age, text и ntext, требующие значительных ресурсов для их обработки.

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

( Замечание ^) Для гарантии неизменности справочных данных все содержащие их таблицы можно прикрепить к группе файлов и установить ее в режим только для чтения (read only).

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

534 Часть III. Администрирование В некоторых случаях создание полной копии базы данных невозможно, т. к. необ ходимо обеспечить практически круглосуточную работу сервера семь дней в неде лю. У администратора имеется в распоряжении всего два-три часа в сутки. С по мощью архивирования файлов или группы файлов администратор может разбить архивирование большой базы данных на несколько менее "тяжелых" операций, занимающих меньше времени. Создание резервной копии всей базы данных мож но разбить на несколько операций архивирования отдельных файлов базы данных.

В этом случае архивирование базы данных может растянуться на несколько суток.

В принципе этот процесс может быть непрерывным. По завершении архивирова ния последнего файла, SQL Server 2000 может начать все заново.

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

Архивирование отдельных файлов или групп файлов предоставляет администра тору дополнительные возможности по восстановлению работоспособности сис темы в случае аппаратного сбоя. Если база данных размещена на множестве дисков, то в случае повреждения одного из них для восстановления системы достаточно будет установить новый жесткий диск и восстановить только файлы, которые находились на поврежденном диске. Не нужно будет восстанавливать всю базу данных.

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

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

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

Естественно, администратор хочет иметь резервную копию самых свежих данных.

Это желание легко удовлетворить при работе с небольшими базами данных — достаточно с требуемой периодичностью создавать полные копии базы данных.

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

Глава 13. Резервное копирование 1. Создается полная резервная копия. Обычно данная операция выполняется раз в неделю на выходных. В другие дни создание полной резервной копии не возможно, т. к. этот процесс может занять существенную часть рабочего дня.

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

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

3. Создается копия журнала транзакций. Это последний этап. Данный процесс требует минимального количества системных ресурсов по сравнению с дру гими типами резервного копирования. Архивирование журнала транзакций можно выполнять гораздо чаще, чем создание разностной копии. При необ ходимости создание резервной копии журнала транзакций можно осуществ лять каждые час-два или чаще. При выборе частоты архивирования следует учесть, что в сумме объем копируемой информации будет один и тот же, не зависимо от того, один раз выполняется архивирование, или десять. Чем ча ще создается резервная копия, тем меньше потерь понесет ваша организация в случае сбоя системы. Однако помимо затрат на сам процесс архивирования имеются и побочные затраты на блокирование, копирование и т. д.

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

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

Выбор носителя Важным моментом планирования процесса резервного копирования является выбор носителя, на котором будет храниться резервная копия. Настоятельно рекомендуется не хранить резервную копию на одном диске с исходными дан ными, т. к. при повреждении аппаратной части вы можете лишиться и рабочих данных, и резервной копии. Хранение архива вместе с данными допустимо 536 Часть III. Администрирование только в том случае, если вы уверены в аппаратной части и опасаетесь повреж дений данных, вызванных действиями пользователей. Пользователи не могут повредить резервную копию.

В качестве носителя информации для системы резервного копирования могут использоваться следующие средства:

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

Стримеры различаются по форматам используемых лент. К формату ленты относятся характеристики ее ширины, ширины корпуса (3,5" и 5,25") и дли ны ленты. Все эти параметры вместе с архитектурой самого стримера влияют на объем данных, которые можно хранить на одной ленте. Преимуществом использования стримера является большой объем данных, который можно записать на ленту. Однако существенный недостаток заключается в относи тельно медленной скорости записи и чтения данных. SQL Server 2000 позво ляет записывать данные только на стример, подключенный к локальному компьютеру. Это означает, что если в вашей организации имеется множество серверов SQL Server 2000, и лишь на одном из них установлен стример, то вы сможете обратиться к стримеру только с него. SQL Server 2000 использует для лент тот же формат, что и утилита Windows NT Backup. Это означает, что резервные копии SQL Server 2000 могут храниться совместно с системными архивами Windows NT и пользовательскими резервными копиями. SQL Server 2000 может одновременно работать с несколькими стримерами. Эта особенность может быть использована при архивировании больших баз дан ных, не помещающихся на одной ленте, или для ускорения операции резер вирования. Однако ничто не мешает выполнять архивирование с помощью одного стримера — необходимо лишь менять ленты по мере их заполнения.

( Замечание ) При обновлении SQL Server предыдущих версий мастер Upgrade Wizard использует специальный формат, который не совместим с форматом утилиты Backup и, следо вательно, форматом резервных копий SQL Server 2000.

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

без дополнительных утилит. Таким диском может являться и обычный жест кий диск, и гибкий диск, и ZIP-диск, и даже магнитооптический диск. В по следнее время получают распространение диски DVD. Накопители этого ти па также могут выступать в качестве носителя резервной копии. Архив SQL Server 2000 представляет собой обычный файл операционной системы, с ко торым могут выполняться те же операции, что и при работе с другими фай лами: копирование, переименование, удаление, перемещение и т. д. Кроме того, если на диске, выбранном в качестве носителя при выполнении архи вирования, используется файловая система NTFS, то необходимо убедиться, что права доступа сконфигурированы правильно. Пользователю, под учетной Глава 13. Резервное копирование записью которого работает SQL Server 2000, необходимо присвоить соответ ствующие права в каталоге, в который будет записываться архив. В против ном случае операция архивирования закончится неудачей.

• Сетевой ресурс. В качестве носителя можно также использовать сетевой диск.

Данный вариант часто используется, если в организации установлено множе ство SQL Server 2000. Каждый из них ;

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

Замечш-uie Архивирование баз данных SQL Server 2000 на сетевой ресурс невозможно, если службы SQL Server 2000 запускаются под локальной учетной записью (системы или пользователя). Обращение к сетевым ресурсам возможно только тогда, когда служ бы запускаются под учетной записью пользователя домена.

О Именованные каналы. Это последний из типов носителей, применяемых сис темой резервного копирования. В принципе, при работе с любым из пере численных выше типов носителей SQL Server 2000 также использует имено ванные каналы. Работа с именованными каналами (named pipes) в "чистом" виде необходима, если вы хотите использовать свое собственное приложение для обработки архивов SQL Server 2000. Именованные каналы предоставляют механизм обмена информацией между приложениями. SQL Server "закачивает" данные в канал, а ваше приложение получает их из него. Даль нейшие операции, выполняемые с полученными данными, зависят от вашей фантазии.

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

Как уже было сказано, не рекомендуется хранить резервные копии вместе с ос новными данными. Особенно важно это замечание при использовании в каче стве носителя локального жесткого диска. По умолчанию SQL Server 2000 со храняет резервные копии в каталоге \Program Files\Microsoft SQL Server\Mssql\Backup, тогда как файлы баз данных по умолчанию хранятся в ка талоге \Program Files\Microsoft SQL Server\Mssql\Data. Если вы используете па раметры по умолчанию, то при выходе жесткого диска из строя вы потеряете и сами данные, и резервные копии.

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

Если вы все же по некоторым соображениям хотите хранить резервные копии на 538 Часть III. Администрирование жестком диске, то следует размещать их на удаленном компьютере. В случае унич тожения одного компьютера, например, в результате пожара, взрыва или наводне ния, останется возможность восстановить данные с другого компьютера.

При хранении данных на магнитной ленте или переносном диске (например, дискете, ZIP-диске, DVD-диске и т. д.), необходимо хранить их в защищенном от повреждения месте, например в сейфе.

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

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

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

Резервное копирование системных баз данных Когда мы говорили о резервном копировании, речь, прежде всего, шла о поль зовательских базах данных. Но не стоит забывать и о системной информации, без которой работа SQL Server 2000 будет невозможной. Наиболее критическим местом являются системные базы данных Master и Msdb. Первая из них содер жит всю системную информацию о работе SQL Server 2000. Повреждение этой базы данных приведет как минимум к неправильной работе сервера, а как мак симум — к невозможности запуска.

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

Наиболее важной для пользователя информацией, хранимой в базе данных Master, являются сведения об учетных записях, которым предоставлен доступ к SQL Server 2000, и информация о системных и пользовательских базах данных.

Вся информация о пользовательских объектах баз данных, таблицах, хранимых процедурах и т. д. хранится в пользовательских базах данных. При повреждении или даже потере базы данных Master эта информация остается.

Глава 13. Резервное копирование Замечание Рекомендуется выполнять архивирование базы данных Master каждый раз после выполнения важных операций: добавления учетных записей, создания или удаления баз данных, изменения настроек SQL Server 2000 и т. д.

Системная база данных Msdb содержит информацию подсистемы автоматизации SQL Server 2000, используемую службой SQLServerAgent. К указанной информа ции относятся данные об операторах, оповещениях и заданиях. Повреждение базы данных Msdb является гораздо менее серьезной проблемой, чем потеря ба зы данных Master, однако если вы активно используете подсистему автоматиза ции, то и это нежелательно. Если же подсистема автоматизации не используется и агент SQLServerAgent не запускается, то архивированием базы данных Msdb можно пренебречь. Базу данных Msdb можно архивировать, как обычную поль зовательскую базу данных.

С Замечание ^ Для системной базы данных Master разрешается создание только полных резерв ных копий. То есть создание резервных копий журнала транзакций и разностных ре зервных копий не допускается. Для базы данных Msdb позволительно создание не только полной, но и разностной резервной копии. Однако архивирование журнала транзакций не разрешается.

Мы не рассмотрели еще две системных базы данных — Model и Tempdb. Первая из них используется как шаблон при создании новой базы данных. Особой необхо димости в ее архивировании нет. Вторая же предназначена для хранения всех временных объектов, создаваемых пользователями. Архивирование этой базы дан ных бессмысленно, т. к. база данных Tempdb создается заново каждый раз, когда стартует SQL Server 2000. При останове сервера происходит автоматическое унич тожение всех временных объектов и удаление самой базы данных Tempdb.

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

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

Как уже говорилось, база данных Master является фундаментом работы SQL Server 2000. В ней содержится вся системная информация, необходимая для функционирования SQL Server 2000 — начиная от размещения пользовательских баз данных и учетных записей пользователей и заканчивая информацией о про цессорах и объеме оперативной памяти, доступных серверу и т. д. Повреждение этой информации может привести к тому, что служба MSSQLServer не запустит ся, и стандартные инструменты восстановления архивов SQL Server 2000 ока 540 Часть III. Администрирование жутся не доступны. Однако рассмотрим сначала ситуацию, когда все же удалось запустить SQL Server 2000, и администратор может воспользоваться стандарт ными инструментами. В указанном случае обычно теряется информация о поль зовательских базах данных или учетных записях пользователей, но остается вся системная информация.

В этой ситуации для восстановления базы данных Master применяется резерв ная копия, полученная с помощью средств самого SQL Server 2000. Админист ратор должен запустить SQL Server 2000 в однопользовательском режиме (single user mode), чтобы никто кроме самого администратора "не мог работать с серве ром и блокировать данные. Кроме того, перед запуском сервера в однопользова тельском режиме следует удостовериться, что никакие службы, кроме службы MSSQLServer, не запускаются. В противном случае администратор не сможет работать с сервером. Это происходит потому, что с SQL Server 2000 разрешено устанавливать только одно соединение, и это соединение будет использовано дополнительной службой.

Замечание Для запуска SQL Server 2000 в однопользовательском режиме нужно выполнить ко манду s q l s e r v r. e x e -т. Предварительно необходимо остановить сервер, если он был запущен.

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

Мы рассмотрели методику восстановления базы данных Master средствами SQL Server 2000. Однако в некоторых случаях запуск сервера может быть невозможен, т. к. хранящаяся в базе данных Master информация является некорректной или вообще отсутствует. В подобной ситуации можно прибегнуть к одному из двух способов: запустить утилиту rebuildm.exe или восстановить базу данных Master как обычный файл операционной системы.

Утилита rebuildm.exe восстанавливает базу данных Master, распаковывая ее с инсталляционного набора SQL Server 2000 и внося в нее необходимую инфор мацию. Файл с шаблоном базы данных Master копируется в процессе установки на жесткий диск и может быть распакован в любой момент с помощью указан ной утилиты. Однако у такого подхода есть значительный минус — теряется любая информация, которая была наработана. База данных Master будет нахо диться в том же состоянии, что и сразу после установки SQL Server 2000. Адми нистратор должен будет восстанавливать все изменения вручную. Поэтому ис пользование утилиты rebuildm.exe является крайним случаем, когда все другие возможности исчерпаны, и все что остается администратору — это добиться за Глава 13. Резервное копирование ;

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

Последний способ восстановления базы данных Master — это копирование ее файлов. Любая база данных представляет собой набор как минимум двух файлов.

Администратор может продублировать базу данных как набор файлов и при необ ходимости восстановить ее, скопировав эти файлы обратно. Также файлы базы данных могут быть архивированы как обычные файлы операционной системы с помощью утилиты Windows NT Backup. Однако при выполнении подобных опе раций следует предварительно остановить службу MSSQLServer. Когда эта служба запущена, сервер блокирует файлы базы данных от любого использования други ми процессами, так что попытки пользователя открыть файл закончатся неудачей.

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

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

Присоединение (attach) базы данных — это процесс создания в таблице sysdatabases базы данных Master новой строки с описанием базы данных. Каж дая БД описывается единственной строкой, в которой указывается имя и разме щение только главного, или первичного файла (primary file) базы данных. Описание всех остальных файлов, включая файлы журнала транзакций, хранится в первич ном файле базы данных. Если положение этих файлов изменилось, то в процессе присоединения обновляется соответствующая информация в первичном файле.

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

В этом случае из таблицы sysdatabases базы данных Master просто удаляется соответствующая строка, и SQL Server 2000 теряет информацию о существовании соответствующей БД. Файлы отсоединенной базы данных могут быть скопирова ны на компакт-диски и разосланы в филиалы компании, где "местные" админист раторы выполнят присоединение и смогут нормально работать.

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

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

Для присоединения базы данных предназначена хранимая процедура s p a t t a c h d b со следующим синтаксисом:

sp_attach_db [§dbname =] 'dbname', [Sfilenamel =] ' f i l e n a m e j i ' [,...16] Рассмотрим использование аргументов этой хранимой процедуры.

П [gdbname =] 'dbname' Указывает имя, которое будет присвоено присоединяемой базе данных.

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

• [Sfilenamel =] 'filename_n' [,...16] Позволяет указать имена файлов БД. Если база данных не перемешалась, и все ее файлы находятся в тех же каталогах, что и до отсоединения, то доста точно указать имя и местоположение только главного файла (с расширением mdf). Если же база данных была перенесена в другой каталог или на другой диск, или же была скопирована с другого компьютера, то необходимо указать имена и местоположение всех файлов базы данных. Имена файлов должны от деляться запятыми. Как видно из синтаксиса, можно указать до 16 файлов ба зы данных.

J ( Замечание Указание файлов журнала транзакций не обязательно. Присоединяя базу данных, администратор может определить только файлы данных. В этом случае SQL Server 2000 автоматически создаст новый журнал транзакций с единственным фай лом. Имя этого файла будет dbnamejog.ldf.

Для отсоединения баз данных служит хранимая процедура sp_detach_db, имеющая представленный ниже синтаксис:

sp_detach_db [Sdbname =] 'dbname' [, [Sskipchecks =] 'skipchecks'] С помощью аргумента ' dbname' указывается имя базы данных, которую необхо димо отсоединить. Аргумент 'skipchecks 1 определяет, будет ли выполняться обновление статистики или нет. По умолчанию этому аргументу присвоено зна чение NULL. Если пользователь указывает значение TRUE, TO выполнение коман ды UPDATE STATISTICS пропускается. Когда же указывается значение FALSE, TO команда UPDATE STATISTICS выполняется.

Ограничения при выполнении архивирования При разработке механизмов резервного копирования программисты Microsoft исходили, прежде всего, из требования, что архивирование должно выполняться в процессе обычной работы сервера. Пользователи должны иметь возможность Глава 13. Резервное копирование работать с данными в то время, когда выполняется архивирование системы. Но при этом все же рекомендуется, чтобы дублирование выполнялось в периоды наименьшей активности пользователей, т. к. этот процесс требует существенных системных ресурсов. Тем не менее, все изменения, сделанные пользователями за время создания резервной копии, будут включены в архив. Однако включа ются только те изменения, которые были закончены к концу процесса создания резервной копии, т. е. была завершена транзакция, в которой выполнялись со ответствующие изменения.

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

П создание или удаление базы данных;

• создание индексов;

• сжатие базы данных;

• выполнение операций, не фиксируемых в журнале транзакций.

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

Архивирование с использованием Transact-SQL SQL Server 2000 предлагает несколько способов создания архивов баз данных, журнала транзакций, файлов или групп файлов:

• Использование Enterprise Manager • Использование Backup Wizard П Возможности Transact-SQL Замечание Помимо перечисленных методов создания резервных копий баз данных архивиро вание может выполнятьсяТЙк часть плана сопровождения баз данных. Для создания такого плана необходимо воспользоваться мастером Database Maintenance Plan Wizard. Работа с этим мастером была рассмотрена в разд. "Использование Data base Maintenance Plan Wizard" главы 12.


При выполнении архивирования средствами Transact-SQL служит команда BACKUP. С ее помощью можно выполнять создание полной и разностной резерв 544 Часть III. Администрирование.

ной копий базы данных, копии журнала транзакций и копий файлов или групп файлов. Мы рассмотрим создание резервных копий как с использованием ука занной команды, так и с помощью Enterprise Manager и мастера. Однако снача ла выясним, как организуется резервное копирование средствами Transact-SQL.

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

BACKUP DATABASE {database_name I @database_name_var} TO backup_device [,... n ] [WITH [BLOCKSIZE = { b l o c k s i z e I @ b l o c k s i z e _ v a r i a b l e } ] [ [, ] DESCRIPTION = { t e x t | @ t e x t _ v a r i a b l e } ] [[,] DIFFERENTIAL] [ [, ] EXPIREDATE = ( d a t e | 0date_var} I RETAINDAYS = {days I @days_var}] [ [, ] FORMAT I NOFORMAT] [ [, ] {INIT | NOINIT}] [ [, ] MEDIADESCRIPTION = {text I @ t e x t _ v a r i a b l e } ] [ [, ] MEDIANAME = {media_name I @media_name_variable}] [ [, ] [NAME = {backup_set_name I @backup_set_name_var}] [ [, ] {NOSKIP I SKIP}] [ [, ] {NOUNLOAD | UNLOAD)] [ [, ] [RESTART] [ [, ] STATS [= p e r c e n t a g e ] ] ] Рассмотрим подробно назначение каждого из аргументов команды.

О database_name I @database_name_var Указывает имя базы данных, которую необходимо архивировать. Имя базы данных может быть задано непосредственно (databasename) или с помощью переменной (@database_name_var). Строка с именем базы данных может иметь любой символьный тип данных, кроме типов ntext или t e x t.

П backup_device [,...n] Эта конструкция определяет носитель, на который должна быть сохранена полученная резервная копия. Ее синтаксис таков:

backup_device : : = { {backup_device_name | @backupdevicename_var} I, " •. •... i Глава 13. Резервное копирование {DISK I TAPE I PIPE) = {'temp_backup_device' I @temp_backup_device_var} } Аргументы backup_device_name I @backup_device_name_var указывают логическое имя устройства резервного копирования, которое было ему при своено при конфигурировании в SQL Server 2000 с помощью хранимой про цедуры sp_addumpdevice. Имя устройства может быть указано как непосред ственно, так и с помощью переменной. В качестве устройства резервного копирования может выступать как физическое устройство (стример, ZIP диск или жесткий диск), так и каналы. Помимо использования уже скон фигурированного устройства, можно выполнить архивирование на временное устройство резервного копирования (temporary backup device). В этом случае подсистема резервного копирования автоматически создает новое устройство перед началом архивирования и удаляет его по завершении создания резерв ной копии.

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

Временные устройства часто п р и м е н я ю т с я, когда в качестве носителя высту пает каталог ж е с т к о г о диска. П р и работе со с т р и м е р а м и практикуется и с пользование п о с т о я н н ы х устройств. А р г у м е н т ы D I S K I TAPE I P I P E задают тип в р е м е н н о г о устройства резервного к о п и р о в а н и я. И м я устройства о п р е деляется С ПОМОЩЬЮ аргументов 'tempj3ackup_device' И @temp_backup_device_var. Первый из них используется, когда имя устрой ства указано как строковая константа, второй же — когда имя устройства за дается с помощью переменной.

( Замечание ^ При выборе в качестве носителя магнитной ленты рекомендуется использовать па раметр WITH FORMAT, если нет уверенности, что лента, на которую выполняется архивирование, имеет формат Microsoft Tape Format (MTF). В этом случае перед за писью данных будет выполнено предварительное форматирование ленты в кор ректном формате. При попытке записи архива на ленту с форматом, отличным от Microsoft Tape Format, будет выдана соответствующая ошибка.

) ( Замечание Как видно из синтаксиса команды, SQL Server 2000 допускает архивирование сразу на несколько устройств. Это утверждение верно как в отношении ленточных накопи телей (стримеров), так и именованных каналов и дисков. Однако все используемые устройства должны быть одного типа. То есть не допускается одновременное архи вирование, например, на ленту и на жесткий диск.

546 Часть III. Администрирование d BLOCKSIZE = {blocksize I @blocksize_variable} С помощью этого аргумента указывается размер в байтах, который будет иметь блок данных. Однако значение данного параметра учитывается только при работе с лентой, когда запись на нее выполняется с указанием ключа FORMAT. Однако при записи на компакт-диск необходимо всегда устанавли вать размер блока, равный 2048 байт. Если в качестве носителя используется жесткий диск, то конкретный размер блока выбирается автоматически в за висимости от типа жесткого диска. При работе с именованными каналами размер блока равен 65 536 байт. В обоих случаях размер блока, указанный с помощью аргумента BLOCKSIZE, игнорируется.

• DESCRIPTION = ( t e x t I @text_variable} Позволяет создать описание создаваемого архива. Текст описания размером до 255 символов сохраняется вместе с архивом, создаваемым на конкретном устройстве резервного копирования. Описание применяется чисто в инфор мативных целях, помогая администратору понять, что за данные хранятся в архиве. На ход выполнения резервного копирования описание не влияет.

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

• EXPIREDATE = {date | @date_var} Данный аргумент определяет время актуальности архива. После наступления указанной даты архив считается устаревшим и может быть перезаписан. Но до истечения срока система не даст перезаписать архив. Дата конца актуаль ности архива может быть указана с помощью текстовой строки (date), со держащей дату в правильном формате, или с помощью переменной (@date_var), имеющей ТИП данных smalldatetime ИЛИ datetime. Аргумент EXPIREDATE не используется при работе с именованными каналами, а учиты вается лишь при записи архива на ленту или диск.

• RETAINDAYS = {days I @days_var} В отличие от предыдущего аргумента этот определяет актуальность носителя не конкретной датой, а количеством дней, которое должно пройти со време ни создания архива. До истечения указанного срока SQL Server 2000 не по зволит переписать архив. Однако опция RETAINDAYS учитывается только при использовании опции INIT И игнорируется при задании опции SKIP.

С~ Замечание ^ Если не приведены ни опция EXPIREDATE, НИ ОПЦИЯ RETAINDAYS, TO при создании архива устанавливается срок актуальности, определенный на уровне сервера. Из Глава 13. Резервное копирование менить значение этой опции можно с помощью хранимой процедуры s p _ c o n f i g u r e с применением параметра media r e t e n t i o n.

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

• NOFORMAT В отличие от предыдущего данный параметр явно указывает, что сущест вующие заголовки не должны перезаписываться. Однако при использовании опции I N I T параметр NOFORMAT игнорируется.

• INIT Параметр определяет, что резервная копия SQL Server 2000 должна быть первым файлом на диске или ленте. При указании этой опции любые дан ные на носителе будут перезаписаны. Однако перезапись не происходит, ес ли на устройстве не истек срок актуальности архивов, установленный при его создании с помощью опций EXPIREDATE И RETAINDAYS.

( Замечание ^ Проверка актуальности пропускается, если при вызове команды BACKUP указана оп ция SKIP.

NOINIT Аргумент имеет действие, обратное аргументу I N I T. TO есть архив будет до бавлен к существующему набору файлов.

MEDIADESCRIPTION = ( t e x t | @text_variable) Указывает описание для всего набора носителей резервных копий. Не нужно путать с параметром DESCRIPTION, С ПОМОЩЬЮ которого присваивается опи сание для архива, создаваемого на конкретном устройстве. Длина описания не должна превышать 255 символов и может указываться непосредственно в виде строковой константы или с помощью переменной любого текстового типа, исключая t e x t и ntext.

MEDIANAME = {media_name I @media_name_variable} Этот аргумент предназначен для указания имени носителя, на котором была создана резервная копия. Если имя носителя не определено, то будет под ставлено имя, которое использовалось ранее. Имя носителя может быть длиной до 128 символов.

NAME = {backup_set_name I @backup_set_name_var} Имя архива. Длина имени ограничивается 128 символами. Если имя не ука зывается, то будет использовано пустое имя.


Часть III. Администрирование П SKIP..-,.•.

При задании этой опции пропускается проверка актуальности архива и име ни, которая обычно производится при выполнении команды BACKUP. Указа ние опции SKIP позволяет перезаписывать архивы, которые еще актуальны.

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

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

П NOUNLOAD Действие опции противоположно предыдущей опции — автоматическая вы грузка ленты из устройства резервного копирования не выполняется.

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

П STATS [= percentage] Аргумент позволяет указать (в процентах) дискретность шкалы индикатора процесса архивирования. По умолчанию пользователь получает сообщение по завершении каждых 10% процесса.

В качестве примера рассмотрим создание полной резервной копии базы данных pubs. Резервная копия будет создана на локальном диске и сохранена в файле pubs.bak:

BACKUP DATABASE pubs TO DISK = 'c:\pubs.bak' После выполнения команды будет возвращена следующая информация:

Processed 176 pages for database ' p u b s ', f i l e 'pubs' on f i l e 1.

Processed 1 pages for database ' p u b s ', f i l e 'pubs_log' on f i l e 1.

BACKUP DATABASE s u c c e s s f u l l y processed 177 pages in 0.549 seconds (2. MB/sec).

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

Глава 13. Резервное копирование В приведенном выше примере резервная копия была создана на локальном диске.

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

sp_addumpdevice [@devtype =] 'device_type', ['Ologicalname =] ' logical_name', [Sphysicalname =] 'physical_name' [, { [@cntrltype =] controller_type | [Sdevstatus =] 'device_status' }} Мы не будем подробно рассматривать синтаксис указанной хранимой процеду ры, но приведем пример ее использования для создания логического устройства резервного копирования:

EXEC sp_addurapdevice 'DISK', 'pubs_dev', 'C:\SQLBack\pubs_bak.dat' После выполнения указанного кода будет создано логическое устройство ре зервного копирования с именем pubsdev, которое физически представлено файлом pubs_bak.dat, расположенным в каталоге SQLBack локального диска С:.

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

BACKUP DATABASE pubs TO pubs_dev Создание копий файлов и групп файлов Как и любой тип архивирования, создание резервной копии файлов и групп файлов выполняется с помощью команды BACKUP. При этом используется сле дующий синтаксис этой команды:

BACKUP DATABASE {database_name I @database_name_var} file_or_filegroup [,...n] TO backup_device [,...n] [WITH [BLOCKSIZE = {blocksize I @blocksize_variable}] [[,] DESCRIPTION = {text I @text_variable}] [[,] EXPIREDATE = {date I @date_var) I RETAINDAYS = {days I @days_var}] [[,] FORMAT I NOFORMAT] [[,] {INIT I NOINIT}] [[,] MEDIADESCRIPTION = {text I @text_variable}] [[,] MEDIANAME = {media_name I @media_name_variable}] [[,] [NAME = {backup_set_name | @backup_set_name_var}] [[,] {NOSKIP I SKIP}] [[,] {NOUNLOAD | UNLOAD}] [[,] [RESTART] [[,] STATS [«percentage]] ] 550 ' Часть III. Администрирование Перечислим только те аргументы, которые специфичны для рассматриваемого типа архивирования и не были указаны в предыдущем разделе. Единственным таким аргументом является конструкция f i l e _ o r _ f i l e g r o u p, задающая файл или группу файлов, которые необходимо архивировать. Эта конструкция имеет следующий синтаксис:

file_or_filegroup ::= { FILE = {logical_file_name | @logical_file_name_var} I FILEGROUP = {logical_filegroup_name I @logical_filegroup_name_varj } Рассмотрим назначение каждого из аргументов данной конструкции.

П FILE = {logical_file_name | 91ogical_file_name_var} Определяет логическое имя архивируемого файла базы данных. Не следует путать логическое имя файла, которое используется для ссылки на него в командах Transact-SQL, с физическим именем файла, которое он имеет в операционной системе. Имя файла может быть указано либо непосредствен но с помощью строковой константы, либо с помощью любой символьной переменной.

d F L G O P = {logical_filegroup_name I @logical_filegroup_name_var} IE R U В отличие от предыдущего аргумента, с помощью которого можно указать конкретный файл базы данных, аргумент FILEG'ROUP задает имя архивируе мой группы файлов.

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

Создание копии журнала транзакций Этот тип резервного копирования также выполняется с помощью команды BACKUP со следующим синтаксисом:

BACKUP L G {database_name I @database_name_var} O {[WITH {NO_LOG | TRUNCATE_ONLY}]} | {TO backup_device [,... n ] [WITH [BLOCKSIZE = { b l o c k s i z e I @ b l o c k s i z e _ v a r i a b l e } ] [ [, ] DESCRIPTION = { t e x t I @text_va"r i a b l e } ] [ [, ] EXPIREDATE = { d a t e | @date_var} I RETAINDAYS = {days I @days_var}] [ [, ] FORMAT I NOFORMAT] [ [, ] {INIT I NOINIT}]. Глава 13. Резервное копирование [ [, ] MEDIADESCRIPTION = { t e x t I @ t e x t _ v a r i a b l e } ] [ [, ] MEDIANAME = {media_name I 8 m e d i a _ n a m e _ v a r i a b l e } ] [ [, ] [NAME = {backup_set_name I @backup_set_name_var} ] [ [, ] NO_TRUNCATE] [ [, ] (NOSKIP ] SKIP}] [ [, ] (NOUNLOAD I UNLOAD}] [ [, ] [RESTART] [ [, ] STATS [= p e r c e n t a g e ] ] ] } Перейдем к параметрам, которые не были рассмотрены в предыдущих разделах.

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

• NO_TRUNCATE При создании резервной копии журнала транзакций с ключевым словом NOTRUNCATE SQL Server 2000 не выполняет усечение журнала транзакций.

Эта опция используется автоматически, если архивируется журнал транзак ций поврежденной базы данных или базы данных, подозреваемой в наличии поврежденных (suspect) данных. Также усечение журнала не происходит при архивировании не восстановленной (has not been recovered) базы данных.

Архивирование средствами Enterprise Manager Предыдущие разделы были посвящены рассмотрению создания резервных ко пий средствами Transact-SQL. Выполнение архивирования с помощью команды BACKUP требует определенного профессионализма и знания синтаксиса команды BACKUP. He каждый пользователь захочет без особых на то причин утруждать себя созданием копий с помощью команды BACKUP. Гораздо более удобным (с точки зрения наглядности и простоты) способом создания* резервной копии яв ляется применение графического интерфейса Enterprise Manager. В этом случае пользователю не нужно вникать в особенности использования команды BACKUP, а достаточно иметь небольшой навык работы с Enterprise Manager и знание ос нов резервного копирования.

Для создания резервной копии с помощью Enterprise Manager в первую очередь необходимо открыть окно SQL Server Backup (рис. 13.1), с помощью которого и выполняется создание резервных копий всех типов. Это окно можно открыть, выбрав в левой панели Enterprise Manager в контекстном меню базы данных ко манду All Tasks, а затем команду Backup Database. Напомним, что базы данных содержатся в папке Database корневого каталога сервера.

552 Часть III. Администрирование Рис. 13.1. Окно SQL Server Backup для базы данных pubs Как видно, окно SQL Server Backup содержит две вкладки. Первая из них имеет имя General и используется для задания общих свойств создаваемой резервной копии. Вторая вкладка — Options — предназначена для выполнения тонкой на стройки создаваемой резервной копии. Рассмотрим элементы управления, имеющиеся на вкладке General.

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

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

О Name. В этом поле указывается имя,.которое будет присвоено создаваемой резервной копии. Для одной и той же базы данных нельзя создавать два ар хива с одинаковыми именами. Однако для разных баз можно создавать архи вы с одинаковыми именами. При последующем восстановлении базы поль зователь будет выбирать нужную резервную копию именно по этому имени.

О Description. Поле предназначено для указания краткого комментария к соз даваемой резервной копии. Эта информация носит чисто вспомогательный характер.

О Backup. С помощью данного раскрывающегося списка необходимо выбрать тип резервной копии, которую требуется создать:

Глава 13. Резервное копирование • • Database - complete — будет создана полная копия базы данных;

Database - differential — будет создана разностная резервная копия;

• Transaction log — будет создана копия журнала транзакций;

• File and filegroup — выбирается для создания резервной копии одной или • более групп файлов или отдельных файлов. При установке переключателя в рассматриваемое положение необходимо указать, какие файлы или группы файлов должны быть архивированы. Для этого предназначено ок но Specify Filegroups and Files, открыть которое можно с помощью кнопки, расположенной справа от переключателя. В окне Specify Filegroups d Files перечислены все определенные в базе данных группы файлов, а также входящие в них файлы. Устанавливая флажок в колонке Backup, вы тем самым предписываете включить соответствующий файл или группу файлов в процесс архивирования.

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

Таре — данные будут сохранены на физическое устройство резервного • копирования, причем в качестве такого устройства может выступать не только лента (стример), но и дисковод ZIP, магнитооптический диск или устройство резервного копирования любого другого типа. Если на ком пьютере, на котором установлен SQL Server 2000, не определено ни од ного устройства резервного копирования, то переключатель Backup to бу дет неактивен и всегда установлен в положение Disk;

• Disk — в этом случае данные будут сохранены на одном из локальных дисков в обычном файле.

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

Для только что установленного SQL Server 2000 список не содержит ни од ного устройства. Создание нового устройства выполняется с помощью окна Select Backup Destination (рис. 13.2), открыть которое можно с помощью кнопки Add. При установке переключателя в положение File name новое уст ройство физически будет представлять собой файл на локальном диске. Это эквивалентно выполнению команды BACKUP С синтаксисом то DISK = 'file_name'. To есть создаваемое устройство резервного копирования не яв ляется таковым в полной мере. Пользователь должен будет ввести имя и путь к файлу, в который будет сохраняться резервная копия.

Если же переключатель установить в положение Backup device, то будет соз дано полноценное новое устройство. (Организация подобных устройств мо жет быть также выполнена и с помощью системной хранимой процедуры sp_addumpdevice.) Пользователь должен будет выбрать в раскрывающемся списке имя одного из имеющихся устройств резервного копирования. Если Часть III. Администрирование такового устройства не имеется, то его можно тут же создать, выбрав в спи ске значение New Backup Device. В ответ откроется окно Backup Device Properties - New Device, с помощью которого и необходимо определить соз даваемое устройство резервного копирования.

Рис. 13.2. Окно Select Backup Destination Замечание Нажав кнопку View Contents, можно просмотреть, какие данные имеются на вы бранном устройстве резервного копирования.

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

• Append to media — новые данные будут добавляться к имеющимся. По добный подход обычно используется при работе с физическими устройст вами резервного копирования, например, с лентой;

Overwrite existing media — новая резервная копия будет записана поверх • имеющихся данных. Обычно применяется, когда резервная копия сохра няется в обычный файл. Таким образом, файл со старой резервной копи ей удалится, а вместо него будет создан файл с новым архивом.

Помимо описанных элементов, на вкладке имеется флажок Schedule. Его уста новка предписывает выполнять резервное копирование не единожды, сразу же после завершения работы с окном SQL Server Backup (т. е. после нажатия кнопки ОК), а периодически. Для этого создается соответствующее задание для службы SQLServerAgent, которое и будет осуществлять резервное копирование.

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

Именно в это время и предлагается выполнять создание резервных копий по умолчанию. Время запуска выводится в текстовом поле, расположенном правее флажка Schedule. Вы можете определить любое другое время по своему усмот рению. Изменение времени запуска задания осуществляется с помощью окна Глава 13. Резервное копирование Edit Schedule (рис. 13.3), открыть которое можно с помощью кнопки ^ J, раз мещенной справа от поля Schedule.

Рис. 13.3. Окно Edit Schedule Переключатель Schedule type позволяет установить тип расписания:

• Start automatically when SQL Server Agent starts. В этом случае запуск задания будет выполняться только в момент запуска службы SQLServerAgent, напри мер, при перезагрузке сервера. Данный тип расписаний используется в ос новном для заданий, проверяющих целостность данных перед началом рабо ты пользователей.

• Start whenever the CPU(s) become idle. В указанном случае выполнение зада ния начинается в момент простоя центрального процессора. Это позволяет запускать задания в моменты наименьшей активности пользователей, напри мер, ночью или в обеденный перерыв. Рассматриваемый тип запуска задания может быть использован для перестроения индексов, обновления полнотек стовых каталогов, создания резервных копий и выполнения других подобных операций.

• One time. При выборе этого типа задание будет запущено лишь один раз.

Когда переключатель установлен в данное положение, становятся доступны ми поля:

• On date — дата запуска задания;

• At time — время запуска задания.

П Recurring. Этот тип расписания используется для периодического запуска задания в строго определенное время. В нижней части окна указывается ин формация о времени запуска. По умолчанию задание запускается каждое воскресенье в 0:00:00. Для изменения данного значения необходимо нажать кнопку Change. В открывшемся диалоговом окне Edit Recurring Job Schedule Часть III. Администрирование можно устанавливать произвольную дату и время запуска задания, а также его периодичность. Кроме того, можно установить конечную дату.

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

Рис. 13.4. Окно SQL Server Backup, вкладка Options На вкладке имеются следующие элементы управления:

• Verify backup upon completion. После завершения создания резервной копии будет выполнена ее проверка.

П Eject tape after backup. Флажок доступен только при архивировании на ленту, т. к. предписывает автоматически извлечь ленту из устройства резервного копирования.

• Remove inactive entries from transactional log. Предписывает по завершении архивирования освободить неактивную часть журнала транзакций для по вторного использования.

• Check media set name and backup set expiration. Когда этот флажок установлен, выполняется проверка на то, не осуществляется ли попытка перезаписать ре Глава 13, Резервное копирование зервную копию, срок хранения которой еще не истек. Если такая попытка об наруживается, то пользователю выдается сообщение об ошибке и предлагается изменить параметры сохранения резервной копии. По умолчанию флажок ус тановлен. Если его сбросить, то будет разрешена перезапись любых архивов.

О Media set name. В этом поле указывается имя набора носителей, на котором будет сохранена создаваемая резервная копия. Указанный набор должен быть предварительно создан. При попытке записи архива на другой набор носите лей будет выдано сообщение об ошибке.

• Backup sell will expire. С помощью этого переключателя можно определить, когда должен закончиться срок хранения резервной копии. После истечения срока хранения резервная копия может быть перезаписана без всяких огра ничений:

• After — при установке переключателя в это положение пользователь дол жен будет указать количество дней, по истечении которых окончится срок хранения резервной копии;

• On — в этом случае необходимо будет явно указать дату, после наступле ния которой будет разрешено перезаписывать архив.

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



Pages:     | 1 |   ...   | 13 | 14 || 16 | 17 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.