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

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

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

Терминология резервного копирования

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

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

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

При восстановлении данных из резервной копии они копируются назад в базу данных. Не путайте восстановление (restore) с воспроизведением (регенерацией) (recovery): это две различные операции.

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

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

Воспроизведение

Воспроизведение (регенерация) (recovery) – это способность системы управления реляционной базой данных (СУРБД – RDBMS) уцелеть после аварии системы и воспроизвести выполненные транзакции. SQL Server не выполняет запись на диск после каждого изменения, вносимого в базу данных. Если бы это было так, то большая система (например, банковская) работала бы намного медленнее, поскольку в каждой транзакции приходилось бы ждать, пока не закончится очередная запись, создающая задержку в системе.

Именно задержки при записи изменений на диск приводят к тому, что база данных после отказа системы может остаться в запорченном состоянии из-за того, что некоторые изменения, внесенные в базу данных, могли быть не записаны на диск, а изменения, записанные на диск, могли быть не зафиксированы. Для поддержки целостности базы данных SQL Server протоколирует все изменения в журнале транзакций. (Журнал транзакций подробно описывается в разделе "Журнал транзакций" ниже в этой лекции.) При запуске SQL Server после отказа системы журнал транзакций используется для повторного исполнения (воспроизведения) транзакций, которые были фиксированы, но не записаны на диск, и отката (отмены результатов) транзакций, которые не были фиксированы на момент аварии системы. Такой подход гарантирует точность данных.

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

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

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

Примечание. Поскольку журнал транзакций является определяющим компонентом для воспроизведения транзакций в случае аварии, он должен всегда располагаться на томе RAID 1 (зеркальном томе). (О RAID [дисковые матрицы] см. "Конфигурирование и планирование подсистемы ввода-вывода" )

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

Примечание. Транзакция, откат которой выполняет SQL Server, идентична транзакции, которая заканчивается командой ROLLBACK. Эта транзакция аннулируется, и все соответствующие данные восстанавливаются к их исходному состоянию.

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