Резервное копирование Microsoft SQL Server

Отказы системы

У вас могут возникнуть сомнения в необходимости резервного копирования, если вы используете такие технологии, как службы кластеризации Microsoft Cluster Services и отказоустойчивые дисковые подсистемы RAID. Тем не менее резервное копирование необходимо. Возможны различные случаи отказов вашей системы, а упомянутые системы поддержки отказоустойчивости и восстановления в случае отказов позволяют продолжить нормальную работу вашей системы не для всех случаев отказов. В этом разделе мы рассмотрим некоторые из потенциальных причин отказов и способы восстановления после этих отказов.

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

Отказы оборудования

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

Отказы программного обеспечения

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

Человеческие ошибки

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

Журнальное протоколирование в SQL Server

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

Журнал транзакций

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

Поток откладываемой записи (Lazywriter Thread)

Изменения, вносимые в базу данных, сначала вносятся в данные, которые находятся в кэше SQL Server. То, что изменения вносятся сначала в кэш, требуется в первую очередь для повышения производительности, поскольку ожидание при операциях ввода-вывода занимает много времени. Эти изменения записываются в конечном итоге на диск, но этот процесс выполняется в фоновом режиме и не виден пользователю. Поскольку модифицированные страницы хранятся в кэше, то может пройти существенный период времени, прежде чем эти страницы (их еще называют ожидающими, черновыми страницами – dirty pages) будут записаны соответствующим потоком (подпроцессом) SQL Server. Этот поток называют потоком откладываемой записи ("ленивым" потоком Этот поток использует LRU-список записи страниц, где первой в очереди записи на диск находится наиболее давно обрабатывавшаяся страница и последней является только что обрабатывавшаяся страница. Страница, которая постоянно модифицируется (и, тем самым, все время перемещается в конец этого списка), вообще может быть не записана этим потоком на диск. Подобные вещи могут увеличивать время воспроизведения, поскольку для применения изменений к таким данным потребуется прочитать много журнальных записей. Например, в большой системе с объемом RAM-памяти более 1 Гб и большим числом изменений в базе данных воспроизведение может занять несколько часов. – lazywriter thread).

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

Последовательная запись в журнал

Журнал транзакций содержит "историю транзакций", поэтому операции ввода-вывода для журнала транзакций – это в основном операции записи, которые обычно выполняются последовательно. В случае отката транзакций происходит чтение журнала транзакций, что приводит к нарушению последовательного характера операций ввода-вывода. Поскольку откаты происходят довольно редко (так как аварии системы случаются редко и пользователи не слишком часто отменяют транзакции), ввод-вывод для журнала транзакций имеет достаточно устойчивый характер. Вы можете существенно повысить производительность операций ввода-вывода, поместив журнал транзакций на его собственный диск или матрицу RAID (см. лекции 4 и 5). В силу исключительной важности журнала транзакций для воспроизведения базы данных вам следует защитить его с помощью дисковой матрицы RAID.

Размер журнала транзакций

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

Воспроизведение с помощью журнала транзакций

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

Свойства журнала транзакций

Журнал транзакций значительно изменился после версии Microsoft SQL Server 6.5. Журнал транзакций SQL Server 2000 имеет те же характеристики, что и в Microsoft SQL Server 7. Это следующие характеристики.

Непротоколируемые операции

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

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

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

Чтобы активизировать непротоколируемые массовые операции с определенной базой данных, вы должны задать для работы этой базы данных режим воспроизведения BULK_LOGGED. Кроме этого режима, можно также задавать режимы воспроизведения FULL и SIMPLE. Эти режимы задаются с помощью команды ALTER DATABASE, как это показано здесь для базы данных Northwind:

ALTER DATABASE Northwind
SET RECOVERY BULK_LOGGED

ALTER DATABASE Northwind
SET RECOVERY FULL

ALTER DATABASE Northwind
SET RECOVERY SIMPLE

При использовании режима BULK_LOGGED массовые операции, описанные в следующих разделах (за некоторыми исключениями, которые тоже описываются в следующих разделах), не протоколируются в журнале, а все остальные операции протоколируются. Если выбран режим воспроизведения FULL, то протоколируются все операции. А в случае режима SIMPLE данные можно восстанавливать только из последней резервной копии.

SELECT INTO

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

BULK COPY и программа BCP

Чтобы операции BULK COPY и BCP можно было выполнять как непротоколируемые операции, они должны отвечать следующим требованиям.

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

CREATE INDEX

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

Текстовые операции

К текстовым операциям, которые можно выполнять как непротоколируемые операции, относятся WRITETEXT и UPDATETEXT. Чтобы активизировать выполнение этих операций без протоколирования, вам нужно просто использовать описанный выше режим BULK_LOGGED.

Контрольные точки

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

Контрольные точки создаются в результате запуска оператора CHECKPOINT, при отключении SQL Server с помощью оператора SHUTDOWN или с помощью Service Control Manager, а также при автоматическом запуске операции контрольной точки из SQL Server.

Операции контрольной точки

В процессе создания контрольной точки выполняется ряд следующих операций.

Конфигурирование интервала между контрольными точками

Интервал между контрольными точками определяется параметром конфигурирования SQL Server recovery interval. Этот параметр задается для всей системы SQL Server, а не для каждой базы данных, но контрольные точки создаются по отдельным базам данных. Этот параметр указывает, сколько минут потребует SQL Server для воспроизведения каждой базы данных в случае отказа системы. Значение 0 указывает, что интервал будет определять SQL Server (обычно он меньше 1 минуты). Для систем с большим объемом памяти, где выполняется очень много операций вставки и обновления, это принятое по умолчанию значение может приводить к созданию излишнего числа контрольных точек. В этом случае вы можете задать для этого параметра более высокое значение. Если ваши пользователи готовы ждать достаточно долго в случае отказа системы (например, 30 минут), производительность транзакций вашей системы будет выше. Значение этого параметра зависит от допустимости простоев в вашей компании и возможной частоты отказов системы.

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

Вы можете изменять значения параметра recovery interval двумя способами: используя Enterprise Manager или с помощью Transact-SQL (T-SQL). Чтобы задать параметр recovery interval из Enterprise Manager, в левой панели щелкните правой кнопкой мыши на имени сервера, для которого хотите задать этот параметр, и выберите из контекстного меню пункт Properties (Свойства), чтобы появилось окно SQL Server Properties (Свойства SQL Server). Щелкните на вкладке Database Settings (Параметры базы данных) (рис. 32.1), и задайте нужный вам интервал (в минутах) в поле-счетчике Recovery Interval (Интервал воспроизведения).

Чтобы задать значение recovery interval с помощью T-SQL, используйте хранимую процедуру sp_configure, как это показано ниже:

sp_configure "recovery interval", 1
GO

Вы увидите следующее сообщение:

DBCC execution completed. If DBCC printed error messages,
contact your system administrator. 
Configuration option changed. Run the RECONFIGURE statement  
to install.
(Работа DBCC завершена. Если DBCC вывел сообщения об ошибках,
обратитесь к вашему системному администратору.
Параметр конфигурирования изменен. Для реализации выполните оператор RECONFIGURE.)

Изменение не будет реализовано, если вы не запустите команду RECONFIGURE. Если вы уверены в правильности изменения, введите следующий оператор T-SQL:

RECONFIGURE 
GO

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

Чтобы убедиться, что внесенное вами значение действует, используйте следующий оператор T-SQL:

sp_configure "recovery interval" 
GO

Результаты будут выведены в следующей форме:

name                              	     minimum 	maximum 	config_value 	run_value
------------------------------------------------------------------------------------------------
 recovery interval (min)                	0         32767            1               1

Это показывает, что значение параметра recovery interval действительно было задано.

Методы резервного копирования

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

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

Полное резервное копирование

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

Разностное резервное копирование

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

Резервное копирование журнала транзакций

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

Резервное копирование группы файлов

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

Резервное копирование файла данных

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

Выполнение резервного копирования

Вы можете выполнять резервное копирование с помощью Enterprise Manager, команд T-SQL или мастера создания резервной копии базы данных Create Database Backup Wizard. Во многих случаях проще всего использовать Create Database Backup Wizard, но Enterprise Manager также несложно использовать. С другой стороны, команды T-SQL можно помещать в сценарии SQL, которые можно многократно повторять. Вам следует использовать метод, наиболее отвечающий вашим требованиям.

Сами операции резервного копирования можно направлять на физическое устройство или логическое устройство. Физическое устройство – это компонент оборудования, такой как ленточное или дисковое устройство. Операционная система присваивает физическим устройствам имена, и для доступа к этим устройствам вы должны использовать эти имена. Поскольку эти заранее назначенные имена бывает трудно запомнить, вам может потребоваться создание для физического устройства алиаса (определенного пользователем альтернативного имени). Такой алиас называют логическим устройством. Это логическое устройство существует только в рамках SQL Server, и его можно использовать только для резервного копирования в SQL Server, чтобы ссылаться на него как на логическое устройство резервного копирования.Если вы хотите выполнять резервное копирование данных на логическое устройство, то должны создать это устройство заранее. Прежде чем перейти к методам выполнения резервного копирования, мы рассмотрим, как создается логическое устройство резервного копирования. Мы будем использовать для примеров этого раздела логическое устройство резервного копирования. (Для получения сведений о добавлении к системе физических устройств обратитесь к вашему системному администратору.)

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

Вы можете создавать логические устройства резервного копирования, используя Enterprise Manager или T-SQL. В этом разделе мы рассмотрим оба метода. Использование нескольких устройств резервного копирования может повысить производительность. (Рекомендации по производительности резервного копирования см. в разделе "Улучшение характеристик резервного копирования" далее.)

Создание устройств резервного копирования с помощью Enterprise Manager

Чтобы создать устройство резервного копирования с помощью Enterprise Manager, выполните следующие шаги.

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

Создание устройств резервного копирования с помощью T-SQL

Для создания устройства резервного копирования с помощью T-SQL используйте хранимую процедуру sp_addumpdevice. Она имеет следующий синтаксис:

sp_addumpdevice тип_устройства, логическое_имя, физическое_имя

Значением параметра тип_устройства может быть disk для дискового устройства, tape для ленточного устройства или pipe для подсоединения программного обеспечения сторонних форм к системе резервного копирования. Параметр логическое_имя – это имя, которое вы присваиваете данному устройству; это имя используется для ссылки на устройство в операторах BACKUP и RESTORE. Параметр физическое_имя – это имя, присвоенное системой устройству или файлу.

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

sp_addumpdevice 'disk', 'Backup_dev_2',  
'C:\MSSQL2K\BACKUP\Backup_dev_2.BAK'

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

Чтобы создать резервную копию вашей базы данных на удаленной системе, вы должны сначала создать устройство резервного копирования с помощью системной хранимой процедуры sp_addumpdevice. Вы не можете создать устройство резервного копирования на удаленном сервере с помощью Enterprise Manager. Чтобы задать удаленную систему, вы должны указать в качестве физического имени полное UNC-имя, как это показано в следующем примере:

sp_addumpdevice 'disk', 'netbackup1',
'\\ptc4\c$\backup\netbackup1.bck'

Создав это устройство резервного копирования, вы можете копировать на него данные с помощью Enterprise Manager или команд T-SQL.

Резервное копирование данных через несколько сетей

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

sp_addumpdevice 'disk', 'netbackup1',
'\\100.100.100.1\c$\backup\netbackup1.bck'
sp_addumpdevice 'disk', 'netbackup2',
'\\100.100.200.1\c$\backup\netbackup2.bck'

Создав эти устройства резервного копирования, вы можете копировать на них данные с помощью Enterprise Manager или операторов T-SQL.

Резервное копирование с помощью Enterprise Manager

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

Выполнение резервного копирования

Для выполнения резервного копирования с помощью Enterprise Manager выполните следующие шаги.

Вызовите утилиту SQL Server Backup с помощью одного из следующих методов.

Раскройте папку сервера в левой панели Enterprise Manager и затем раскройте папку Management. Щелкните правой кнопкой мыши на Backup и выберите из контекстного меню пункт Backup A Database (Резервное копирование базы данных).

Раскройте папку сервера в левой панели Enterprise Manager, щелкните правой кнопкой мыши на Database, укажите в контекстном меню пункт All Tasks (Все задачи) и затем выберите команду Backup Database.

Раскройте папку сервера в левой панели Enterprise Manager и затем щелкните на папке Databases. В правой панели щелкните правой кнопкой мыши на базе данных, укажите в контекстном меню пункт All Tasks (Все задачи) и затем выберите команду Backup Database.

Появится диалоговое окно SQL Server Backup (рис. 32.3).

(рис 32.3) Вкладка General диалогового окна SQL Server Backup

Введите имя расписания в текстовом поле Name. Имена расписаний позволяют вам создавать несколько расписаний, например, отдельное расписание для каждого резервного копирования.

В секции Schedule type (Тип расписания) вы можете выбрать один из следующих типов расписания (в порядке кнопок выбора): автоматически при запуске SQL Server Agent, когда не будет занят ЦП, запускать резервное копирование один раз или повторять его. Если у вас выбран однократный запуск резервного копирования, то вы используете всплывающий календарь On date (Дата) для выбора даты резервного копирования и поле-счетчик At time (Время) для выбора времени.

Чтобы задать расписание для периодически повторяющегося резервного копирования, щелкните на кнопке выбора Recurring (Периодически) и щелкните на кнопке Change (Изменить).

Появится диалоговое окно Edit Recurring Job Schedule (Редактировать расписание повторяющихся заданий) (рис. 32.6). Это диалоговое окно предоставляет вам разнообразные гибкие возможности по созданию расписания. Используя вариант Daily (Ежедневно), Weekly (Еженедельно) или Monthly (Ежемесячно), вы можете указывать частоту и срок действия соответствующего задания.

(рис 32.6) Диалоговое окно Edit Recurring Job Schedule (Редактировать расписание повторяющихся заданий)

Управление резервным копированием

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

В левой панели Enterprise Manager раскройте папку сервера, раскройте папку Management, раскройте папку SQL Server Agent и щелкните на Jobs (Задания). Запланированные задания будут представлены в списке правой панели Enterprise Manager (рис. 32.8).

Чтобы удалить задание, щелкните правой кнопкой мыши на имени этого задания и выберите из контекстного меню пункт Delete (Удалить).(рис 32.8) Задания, представленные в окне Enterprise Manager

Для просмотра или модифицирования задания щелкните правой кнопкой мыши на имени этого задания и выберите из контекстного меню пункт Properties (Свойства), чтобы появилось окно свойств задания Properties. Внесите свои изменения, щелкните на кнопке Apply (Применить) и затем щелкните на кнопке OK.

Резервное копирование с помощью операторов T-SQL

Использование операторов T-SQL для резервного копирования базы данных может оказаться поначалу чуть сложнее, чем использование Enterprise Manager. Но если вы относитесь к тем администраторам, которые предпочитают автоматизировать операции с помощью сценариев, этот метод будет для вас удобнее. Кроме того, оператор T-SQL BACKUP дает несколько больше возможностей, чем программа резервного копирования в Enterprise Manager. В этом разделе мы рассмотрим синтаксис и параметры оператора BACKUP. На самом деле существуют два оператора резервного копирования; выбор используемого оператора зависит от типа резервного копирования, которое вам нужно выполнить. Это следующие операторы:

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

Выполнение резервного копирования

Оператор BACKUP для полного резервного копирования базы данных имеет следующий синтаксис:

BACKUP DATABASE имя_базы_данных
TO устройство_резервного_копирования
[ WITH необязательные параметры ]

Для этого оператора обязательными параметрами являются только имя базы данных и имя устройства резервного копирования. (Примеры операторов BACKUP можно найти во врезке "Использование оператора BACKUP" далее.)

Оператор для резервного копирования файла или группы файлов имеет следующий синтаксис:

BACKUP DATABASE имя_базы_данных
имя_файла или имя_группы_файлов [,...n]
TO устройство_резервного_копирования
[ WITH необязательные параметры ]

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

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

BACKUP LOG имя_базы_данных
{
[ WITH \ NO_LOG | TRUNCATE_ONLY )]
}
|
{
TO устройство_резервного_копирования
}
[ WITH необязательные параметры ]

Для этого оператора обязательными параметрами являются только имя базы данных и параметр WITH NO_LOG или WITH TRUNCATE_ONLY либо имя устройства резервного копирования. Вы можете затем добавлять любые нужные вам параметры. Параметры NO_LOG и TRUNCATE ONLY является синонимами; оба указывают усечение журнала без создания его резервной копии.

Во всех трех указанных командах резервного копирования имя_базы_данных представляет базу данных, для которой будет создана резервная копия. Устройство_ резервного_копирования – это имя логического устройства резервного копирования или имя физического устройства. Если указано физическое устройство, то имени устройства должен предшествовать текст DISK =, TAPE = или PIPE = (в зависимости от типа устройства). Вы можете задать одно устройство или набор разделенных запятыми устройств, как это показано в следующих двух примерах:

Backup_dev_1, Backup_dev_2, Backup_dev_3

TAPE = '\\.\Tape0', TAPE = '\\.\Tape1', TAPE = '\\.\Tape2'

Необязательные параметры

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

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

Использование оператора BACKUP

В этом разделе мы рассмотрим пару примеров использования оператора T-SQL BACKUP. Следующий оператор используется для резервного копирования файлов данных базы данных Example:

BACKUP DATABASE Example 
TO Backup_Dev_1, Backup_Dev_2 
WITH 
DESCRIPTION = "DB backup of example", 
STATS = 5 
GO

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

Если вы будете проверять этот пример на небольшой базе данных, такой как Northwind, то вы не увидите сообщений с приращением по 5 процентов. Это будут приращения, например, в 7 процентов, 16 процентов и т.д. Дело в том, что программа резервного копирования читает и записывает за один раз более 5 процентов от объема всех данных такой базы данных. Для наборов данных большего размера за один раз будет записываться меньше 5 процентов данных и поэтому сообщения будут появляться ожидаемым образом.

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

BACKUP LOG Example 
TO Backup_Dev_3, Backup_Dev_4 
WITH 
DESCRIPTION = "DB backup of example", 
STATS = 25 
GO

Здесь устройства резервного копирования – это Backup_Dev_3 и Backup_Dev_4, а сообщения о состоянии будут выводиться с интервалом в 25 процентов. В результирующем наборе будет представлен процент выполненных операций, а также результаты резервного копирования. Будет указано количество скопированных страниц, сколько времени длится резервное копирование и какова скорость (Мб/с).

Управление резервным копированием

Поскольку оператор T-SQL BACKUP не выполняется под управлением Enterprise Manager и, тем самым, не выполняется под управлением SQL Server Agent, вы не можете задать расписание этого задания в операторе BACKUP . Но вы можете задать расписание для оператора T-SQL BACKUP с помощью средств планирования заданий в SQL Server. После того как составлено расписание для задания, им можно управлять точно так же, как и заданиями резервного копирования в Enterprise Manager.

Резервное копирование с помощью мастера Create Database Backup Wizard

Теперь обратимся к третьему методу выполнения резервного копирования: использование мастера Create Database Backup Wizard.

Выполнение резервного копирования

Для резервного копирования с помощью мастера Create Database Backup Wizard выполните следующие шаги.

В окне Enterprise Manager щелкните на базе данных, для которой хотите создать резервную копию, и затем выберите из меню Tools пункт Wizards (Мастера), чтобы появилось диалоговое окно Select Wizard (Выбор мастера). В диалоговом окне Select Wizard раскройте папку Management, выберите Backup Wizard (Мастер резервного копирования) и затем щелкните на кнопке OK. Появится начальное окно мастера Create Database Backup Wizard (рис 32.9(рис 32.9) Начальное окно мастера Create Database Backup Wizard

Щелкните на кнопке Next, чтобы появилось окно Select Database to Backup (Выбор баз данных для резервного копирования) (рис 32.10(рис 32.11) Окно Select Database to Backup (Выбор баз данных для резервного копирования)(рис 32.10) Окно Type Name and Description for Backup (Ввод имени и описания для резервной копии)

Щелкните на кнопке Next, чтобы появилось окно Type Name and Description for Backup (Ввод имени и описания для резервной копии) (рис. 32.11). Здесь вы задаете имя и описание для набора резервной копии путем ввода нужного имени в текстовом поле Name и описания в текстовом поле Description. Хорошее описание поможет вам в будущем, когда у вас будет много резервных копий.

Щелкните на кнопке Next, чтобы появилось окно Select Type of Backup (Выбор типа резервного копирования) (рис 32.12(рис 32.12) Окно Select Type of Backup

Щелкните на кнопке Next, чтобы появилось окно Select Backup Destination and Action (Выбор местоположения резервной копии и действия) (рис 32.13(рис 32.13) Окно Select Backup Destination and Action (Выбор местоположения резервной копии и действия)Примечание. К сожалению, мастер Create Database Backup Wizard позволяет вам выбрать только одно устройство резервного копирования, что может резко повлиять на производительность резервного копирования. (Cм. раздел "Улучшение характеристик резервного копирования" далее.) По этой причине использование Enterprise Manager может оказаться предпочтительнее мастера Create Database Backup Wizard.

Щелкните на кнопке Next, чтобы появилось окно Backup Verification аnd Scheduling (Проверка резервной копии и создание расписания) (рис. 32.14). Здесь вы можете задать проверку меток носителей и дат окончания срока действия. (См. раздел "Резервное копирование с помощью Enterprise Manager".) Вы можете также запланировать резервное копирование на определенные моменты в будущем с помощью диалогового окна Edit Schedule, как это описано выше в этой лекции.

Щелкните на кнопке Next, чтобы появилось окно Completing the Create Database Backup Wizard (Завершение работы мастера создания резервной копии базы данных) (рис. 32.15). Проверьте информацию в текстовом поле и щелкните на кнопке Finish, чтобы запустить резервное копирование.

Управление резервным копированием

С помощью мастера Create Database Backup Wizard вы можете только выполнять резервное копирование или создавать задание на резервное копирование (которое запускается по расписанию). Создав задание, вы должны использовать для управления этим заданием Enterprise Manager или оператора T-SQL. (Об управлении заданиями см. раздел "Резервное копирование с помощью Enterprise Manager" выше в этой лекции.)

Слежение за резервным копированием

При выполнении резервного копирования (с помощью Enterprise Manager, T-SQL или мастера Create Database Backup Wizard) сохраняется запись об этом резервном копировании. Эта запись сохраняется в виде строки в таблице backupfile базы данных msdb. Во время восстановления данная информация используется, чтобы определить, когда было выполнено последнее резервное копирование для базы данных. Кроме того, сохраняется такая информация, как идентификатор набора резервной копии и имена файлов, сохраненных при резервном копировании. Поэтому важно выполнять периодическое резервное копирование системных баз данных, чтобы можно было при необходимости восстановить эту информацию.

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

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

Рекомендации по составлению расписания

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

Планирование операций резервного копирования

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

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

Улучшение характеристик резервного копирования

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

Повышение производительности резервного копирования

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

Дополнительные рекомендации

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

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

Заключение

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