Оглавление

Введение

1 Общие принципы восстановления

2 Журнализация и буферизация

2.1 Индивидуальный откат транзакции

2.2 Восстановление после мягкого сбоя

3 Восстановление после жесткого сбоя

Заключение

Список источников

Введение

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

Общие принципы восстановления.

Общими принципами восстановления являются следующие:

• результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных (т. е. должно поддерживаться свойство долговечности (durability) транзакций);
• результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных (в противном случае состояние базы данных могло бы оказаться не целостным).

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

1. Индивидуальный откат транзакции. Тривиальной ситуацией отката транзакции является ее явное завершение оператором ROLLBACK. Возможны также ситуации, когда откат транзакции инициируется системой. Примерами могут быть возникновение исключительной ситуации в прикладной программе (например, деление на ноль) или выбор транзакции в качестве жертвы при разрушении синхронизационного тупика. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.
2. Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой). Такая ситуация может возникнуть при аварийном выключении электрического питания, при возникновении неустранимого сбоя процессора (например, срабатывании контроля основной памяти) и т.д. Ситуация характеризуется потерей той части базы данных, которая к моменту сбоя содержалась в буферах оперативной памяти СУБД.
3. Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой). Эта ситуация при достаточно высокой надежности современных устройств внешней памяти может возникать сравнительно редко, но, тем не менее, СУБД должна быть в состоянии восстановить базу данных даже и в этом случае. Основой восстановления является архивная копия и журнал изменений базы данных.

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

Возможны два основных варианта ведения журнальной информации:

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

Будем рассматриваться только второй вариант.

1. Журнализация и буферизация

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

Поэтому основным принципом согласованной политики выталкивания буфера журнала и буферов страниц базы данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) — «пиши сначала в журнал», и состоит в том, что если требуется вытолкнуть во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи о его изменении.

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

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

Индивидуальный откат транзакции

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

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

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

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

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

Индивидуальный откат незафиксированной транзакции выполняется следующим образом:

1.Выбирается очередная запись из списка данной транзакции.

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

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

4.При успешном завершении отката в журнал заносится запись о конце транзакции. С точки зрения журнала такая транзакция является зафиксированной.

Восстановление после мягкого сбоя

К числу основных проблем восстановление после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо. Несмотря на применение протокола WAL, после мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует объекту до изменения, часть — после изменения. К такому состоянию объекта не применимы операции логического уровня.

Определение 1. Состояние внешней памяти базы данных называется физически согласованным, если наборы страниц всех объектов согласованы, т. е. соответствуют состоянию объекта либо после его изменения, либо до изменения.

Будем считать, что в журнале отмечаются точки физической согласованности (контрольные точки, time of physical consistency — tpc) базы данных — моменты времени, в которые во внешней памяти содержатся согласованные результаты операций, завершившихся до соответствующего момента времени, и отсутствуют результаты операций, которые не завершились, а буфер журнала вытолкнут во внешнюю память.

рис.1. Возможные состояния транзакций к моменту мягкого сбоя

Тогда к моменту мягкого сбоя возможны только состояния транзакций, указанные на рис.

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

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

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

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

Действительно, во внешней памяти базы данных полностью отсутствуют результаты операцийT3, которые были выполнены после момента tppc. С другой стороны, во внешней памяти гарантированно присутствуют результаты операций T3, которые были выполнены до момента tppc. Следовательно, обратное выполнение (по смыслу и хронологии) операций T3 корректно и приведет к согласованному состоянию базы данных. (Поскольку транзакция T3 не завершилась к моменту мягкого сбоя tfs, при восстановлении необходимо устранить все последствия ее выполнения.)

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

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

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

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

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

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

Это достаточно сильно упрощает процедуру восстановления после мягкого сбоя. Система вообще не должна предпринимать никаких действий по отношению к изменениям транзакций типа Т₅ — этих изменений нет на внешней памяти. При восстановлении достаточно выполнить обратные изменения транзакций типа Т₃, повторно выполнить изменения транзакций типа Т₂. Кроме того, нужно просто повторить изменения транзакций типа Т₄. Естественно, что начинать действия по журналу следует с записи о последней контрольной точке.

Следует отметить, что на самом деле теневой механизм используется не для упрощения процедуры восстановления после мягкого сбоя, а в связи с тем, что восстановление БД можно начинать только от ее физически согласованного состояния. Дело в том, что в журнал помещается информация об изменении объектов БД, а не страниц. Например, в журнале может находиться информация о модификации кортежа в виде триплета . Реально же при выполнении операции модификации изменяются несколько страниц: исходная страница; возможно, страница замены, если кортеж не поместился в исходную страницу; страницы индексов. И так происходит при выполнении любой операции изменения БД. Поскольку буфера страниц выталкиваются во внешнюю память по отдельности, то к моменту мягкого сбоя во внешней памяти может возникнуть набор физически рассогласованных страниц, не соответствующий никакой журнализуемой операции. При таком состоянии внешней памяти восстановление по журналу невозможно.

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

Восстановление после жесткого сбоя

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

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

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

Как создавать архивную копию? Самый простой способ — архивировать базу данных при переполнении журнала. В журнале вводится так называемая «желтая зона», при достижении которой образование новых транзакций временно блокируется. Когда все транзакции закончатся, и следовательно, база данных придет в согласованное состояние, можно производить ее архивацию, после чего начинать заполнять журнал заново.

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

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

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

Заключение

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

Список источников

1. [Электронный ресурс] https://studref.com/690818/informatika/vosstanovlenie_informatsii_bazah_dannyh
2. [Электронный ресурс] https://studfile.net/preview/6131926/page:33/
3. [Электронный ресурс] http://www.interface.ru/home.asp?artId=22199