14.5. Восстановление носителей

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

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

² Следует иметь в виду, что описываемая здесь процедура восстановления системы очень упроще- на. В частности, здесь показано, что сначала выполняются операции отмены, а затем — операции по- вторного выполнения Первые системы действительно так работали, но современные системы по со- ображениям производительности обычно работают несколько иначе (см. [4.17], [4.19]).

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

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

14.6. Двухфазная фиксация

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

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

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

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

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

Теперь, что бы ни случилось, менеджер ресурсов будет иметь постоянную запись о работе, выполненной им в процессе обработки данной транзакции, а значит, в случае необходимости сможет зафиксировать выполненные обновления или от- менить их. Если принудительная разгрузка прошла успешно, менеджер ресурсов отвечает координатору, что все "ОК". В противном случае он посылает противо- положное сообщение — "Not OK".

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

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

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

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