Статья
04/01/2012

Создание резервных копий журналов транзакций

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

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

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

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

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

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

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

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

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

Время	Событие
8:00 утра	Резервное копирование базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Резервное копирование базы данных.
20:00	Резервное копирование журнала транзакций.

Резервная копия журналов транзакций, созданная в 20:00, содержит записи журнала транзакций с 16:00 до 20:00. В этом же временном диапазоне, а именно в 18:00, была создана полная резервная копия базы данных. Последовательность резервных копий журнала транзакций продолжается непрерывно от момента создания начальной полной резервной копии в 8:00 и до создания последней резервной копии журнала транзакций в 20:00.

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

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

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