Резервные копии и контрольные точки

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

Создание контрольной точки — это операция, приводящая базу данных на диске в состояние, согласованное со всеми зафиксированными тран-ями. Она включает в себя сброс на диск содержимого дисковых кэшей, чтобы информация на диске соответствовала текущему содержимому БД. Если происходит сбой СУБД, и при этом диск не поврежден, то БД на диске будет содержать все изменения, зафиксированные до создания контрольной точки. Но при этом не гарантируется, что зафиксированные после контрольной точки изменения также окажутся на диске.

При сбое СУБД для восстановления можно использовать резервные копии и контрольные точки. Если диск не поврежден, сервер БД может рестартовать из состояния, в котором он находился в момент создания последней контрольной точки. Если диск поврежден, то состояние можно восстановить до последней имеющейся в наличии резервной копии.

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

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

Журналы тран-ий

Каждая СУБД ведет несколько журнальных файлов, где записывается работа сервера. Журнал тран-ий — это файл, в который записываются операции всех тран-ий по мере их возникновения. Запись журнала тран-ий состоит из следующих элементов.

•Уникальный идентификатор тран-ии (ID), автоматически присваиваемый тран-ии при ее запуске.

•Название выполняемой операции.

•Объект, к которому относится операция, если таковой есть.

•Результат операции над объектом, если таковой имеется.

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