Главная » SQL, Базы данных » ВОССТАНОВЛЕНИЕ НОСИТЕЛЕЙ

0

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

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

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

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

полностью отменены (фактически просто утрачены).

Таким образом, процедура восстановления носителей подразумевает наличие в  системе утилиты копирования/восстановления (или выгрузки/загрузки). Функция копирования этой утилиты используется для создания резервной копии в установленные моменты. Такие копии могут сохраняться либо на ленте, либо на других устройствах архивирования. Совсем не обязательно, чтобы они создавались на устройствах хранения с прямым доступом. Функция восстановления утилиты используется в случае отказа носителя для воссоздания базы данных с требуемой резервной копии.

15.2.          ДВУХФАЗНАЯ ФИКСАЦИЯ

Примечание. При первом чтении этот раздел можно пропустить.

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

может взаимодействовать с несколькими независимыми диспетчерами ресурсов, каждый из которых распоряжается собственным набором восстанавливаемых ресурсов и поддерживает собственный журнал восстановления8. Например, допустим, что транзакция, выполняемая на мэйнфрейме IBM, модифицирует как базу данных СУБД IMS, так и базу данных СУБД DB2 (подобные транзакции применяются на практике довольно часто). Если транзакция завершается успешно, то все выполненные ею обновления, как в базе данных СУБД IMS, так и в базе данных СУБД DB2, должны быть зафиксированы. В противном случае для всех внесенных обновлений должен быть выполнен откат. Иначе говоря, недопустима ситуация, когда обновления информации в базе данных СУБД IMS зафиксированы, а для обновлений информации в базе данных СУБД DB2 выполнен откат, или наоборот. Суть в том, что в подобном случае транзакция перестанет быть неразрывной (выполняемой по принципу "все или ничего").

Отсюда следует, что для транзакции не имеет смысла выполнять, например, оператор COMMIT в СУБД IMS и оператор ROLLBACK В СУБД DB2. Даже если один и тот же оператор будет выдан для обеих СУБД, в системе все равно может произойти аварийный останов

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

между завершением этих двух операций, и полученные результаты окажутся неудовлетворительными. Вместо этого транзакция должна выдать одну  "глобальную", или общесистемную, команду COMMIT (или ROLLBACK). Выполнением таких глобальных операций фиксации или отката управляет системный компонент, называемый координатором. Его задача состоит в обеспечении того, что оба диспетчера ресурсов (т.е. СУБД IMS и СУБД DB2 в данном примере) согласованно выполнят фиксацию или откат тех обновлений, за которые они ответственны. Более того, он должен обеспечивать такую гарантию даже в том случае, если отказ системы произошел до завершения всего  процесса. Все это достигается за счет использования протокола двухфазной фиксации.

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

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

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

2.  Фиксация. Вторая фаза наступает после того, как координатор получит соответ ствующие ответы от всех участников транзакций. Сначала он принудительно выгружает записи о завершаемой транзакции в собственный физический журнал регистрации, регистрируя свое решение относительно этой транзакции. Если все поступившие ответы были положительными, координатор принимает реше ние глобально зафиксировать данную транзакцию. Если же поступил хотя бы один отрицательный ответ, то для транзакции будет выполнен глобальный откат. Затем координатор каким-либо способом информирует каждого из участников транзакции о своем решении, и каждый участник, согласно поступившей инструк ции, должен локально зафиксировать транзакцию или выполнить ее откат. Обрати те внимание на то, что каждый участник должен делать то, что ему указал коорди натор в ходе выполнения второй фазы; в этом и состоит суть данного протокола.

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

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

запись не будет обнаружена, предполагается, что было принято решение об откате данной транзакции и, следовательно, процесс так или иначе завершится,     Примечание. Следует подчеркнуть, что если координатор и участники выполняют свою работу на различных  компьютерах,  что  типично  для  распределенной  системы  (глава  21),  то ошибка в работе координатора может  привести к тому, что некий участник достаточно долго  будет  ожидать  поступления  сведений  о  принятом  координатором  решении.  В течение всего времени ожидания любое из обновлений, произведенное транзакцией в базе данных  этого участника, должно быть скрыто от других транзакций (иначе говоря, эти обновления должны быть заблокированы, о чем речь пойдет в следующей главе). Отметим, что диспетчер передачи данных (Data Communications Manager), или  сокращенно DCдиспетчер  (см.  главу  2),  также  может  рассматриваться  как   диспетчер  ресурсов  в описанном  выше  смысле.  Это  означает,  что  сообщения  можно  считать  такими  же восстанавливаемыми ресурсами, как и саму базу данных, а диспетчер передачи данных должен быть способен участвовать в процессе двухфазной фиксации. Для дальнейшего изучения этого вопроса, а также общей идеи двухфазной фиксации обратитесь к [15.12].

15.3.            ТОЧКИ СОХРАНЕНИЯ (ОТСТУПЛЕНИЕ ОТ ОСНОВНОЙ ТЕМЫ)

Выше было описано, что при обычных условиях транзакции не могут быть вложены одна в другую. Но иногда возникает необходимость предусмотреть разбиение транзакций на меньшие субтранзакции. Такая задача может быть решена, но только частично, поскольку предусмотрена лишь возможность устанавливать в процессе выполнения транзакции промежуточные точки  сохранения и в дальнейшем выполнять откат к заранее установленной точке сохранения (если это потребуется), чтобы не возобновлять всю работу по выполнению транзакции с самого начала. Механизм создания точек сохранения, действующий по указанному принципу, фактически был включен в самые первые версии некоторых систем, в том числе Ingres (в коммерческий программный продукт, а не прототип) и System R. Кроме того, это средство было введено в стандарт SQL в 1999 году. Но следует отметить, что операция установки точки сохранения не является аналогичной операции COMMIT; обновления, внесенные в ходе транзакции, все еще остаются невидимыми для других транзакций до тех  пор, пока не будет успешно выполнена операция COMMIT в текущей транзакции. Дополнительные сведения по этой теме приведены в разделе 15.8.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии