Полная копия

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

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

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

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

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

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

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

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

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

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

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