Введение в системы БД (542480), страница 139
Текст из файла (страница 139)
Иначе говоря, для любых отдельных транзакций Т1 и Т2 справедливо следующее утверждение: Т1 сможет увидеть результаты выполненных транзакцией Т2 обновлений только после завершения выполнения транзакции Т2, а транзакция Т2 сможет увидеть результаты выполненных транзакцией Т1 обновлений только после завершения выполнения транзакции Т1. Более подробно эта тема рассматривается в главе 15. И Долговечность. Если транзакция зафиксирована, выполненные ею обновления сохраняются в базе данных постоянно, даже если в следующий момент произойдет сбой системы. 14.4. Восстановление системы Система должна быть готова к восстановлению не только после локальных отказов, подобных возникновению условия переполнения при выполнении операции в пределах определенной транзакции, но и после глобальных нарушений, подобных отключению питания.
Локальное нарушение по определению влияет только на ту транзакцию, в которой оно, собственно говоря, и произошло. Подобные нарушения уже обсуждались выше, в разделах 14.2 и !4.3. Глобальное нарушение воздействует сразу на все транзакции, выполнявшиеся в момент его возникновения, и, следовательно, приводит к более значительным для системы последствиям.
Ниже кратко описывается, какие действия необходимо выполнить в процессе восстановления после глобального отказа системы. Существует две обширные категории глобальных нарушений. т Отказы системы (например, сбои в питании) воздействуют на все выполняющиеся в данный момент транзакции, но не нарушают физическое состояние базы данных. Отказ системы иногда также называют мягким отказам т Отказы носителей (например, поломка головки дискового накопителя), которые могут представлять угрозу для физического состояния всей базы данных или какой-либо ее части, способны воздействовать по крайней мере на те транзакции, которые используют поврежденную часть базы данных. Отказ носителя иногда также называют жестким отказом. В этом разделе будут рассмотрены отказы системы, а в разделе 14.5 — отказы носителей.
Критическим моментом в отказе системы является потеря содержимого основной (оперативной) памяти (в частности, буферов базы данных), Поскольку точное состояние любой выполнявшейся в момент отказа системы транзакции остается неизвестным, такая транзакция никогда не сможет быть успешно завершена. Поэтому при перезагрузке системы любая такая транзакция будет отменена (т.е. будет выполнен ее откат).
Более того, при перезагрузке системы, возможно, потребуется (как указывалось в разделе 14.3) повторно выполнить транзакции, которые успешно завершились до аварийного отказа, но выполненные ими обновления еще не были перенесены из буферов базы данных в физическую базу данных во вторичной памяти, 550 Часть 1К Управление транзакциями Возникает очевидный вопрос: "Как в процессе перезагрузки система узнает, какую транзакцию следует отменить, а какую выполнить повторно?". Ответ заключается в том, что система автоматически создает контрольные точки с некоторым наперед заданным интервалом (обычно, когда в журнале накапливается определенное число записей).
Создание контрольной точки означает: а) физическую перезапись ("принудительная разгрузка") содержимого рабочих буферов базы данных непосредственно в базу данных и б) физическое помещение в файл журнала специальной записи контрольной точки. На рис. 14.3 представлен пример выполнения транзакций до аварийного сбоя системы (время возрастает слева направо). Рис. 14.3. Пять возиожных вариантов выполнения транзакций К этому можно добавить следующие комментарии. И Отказ системы произошел в момент 1Т. И Ближайшая к моменту СТ контрольная точка была создана в момент сс. И Транзакция Т1 успешно завершена до момента 1с.
° Транзакция Т2 начата до момента ьс и успешно завершена после момента Сс, но до момента СТ. И Транзакция Т3 также начата до момента сс, но не завершена к моменту 11. И Транзакция Т4 начата после момента 1с и успешно завершена до момента 1Т. И Транзакция Т5 также начата после момента сс, но не завершена к моменту 1Т. Очевидно, что при перезагрузке системы транзакции типа ТЗ и Т5 должны быть отменены, а транзакции типа Т2 и Т4 — выполнены повторно. Заметьте, что транзакции типа Т1 вообще не участвуют в процессе перезагрузки, так как выполненные ими обновления были принудительно занесены в физическую базу данных в момент 1с как часть процедуры создании этой контрольной точки.
Обратите внимание также на то, что транзакции„ завершившиеся неудачно (т.е. для них был выполнен откат) до момента 11, также не будут принимать участия в процессе перезагрузки (подумайте, почему). Следовательно, во время перезагрузки система прежде всего идентифицирует все транзакции типа Т2 — Т5. При этом осуществляются следующие действия. 551 Глава 14. Восстановление !. Создается два списка транзакций; назовем их РОРО (отменить) и ВЕРО (выполнить повторно). В список РИРО заносятся все транзакции, упомянутые в последней из существующих записей контрольной точки, а список ВЕРО пока остается пустым.
2. В журнале регистрации поиск организуется с записи последней контрольной точки. 3. Если в журнале регистрации обнаружена запись ВЕ61И ТККИЯКОТ10И с указанием о начале выполнения некоторой транзакции Т, то эта транзакция добавляется в список РОРО. 4. Если в журнале регистрации обнаружена запись СОИИ1Т, свидетельствующая об окончании выполнения некоторой транзакции Т, эта транзакция добавляется в список КЕРО.
5. По достижении конца файла журнала регистрации списки РКРО и ВЕРО анализируются для выявления транзакций типа Т2 и Т4, помещенных в список КЕРО, и транзакций типа Т3 и Т5, оставшихся в списке РОРО. После это~о система просматривает журнал регистрации в обратном направлении, выполняя откат транзакций из списка РИРО, а затем вновь просматривает журнал в прямом направлении, повторно выполняя транзакции из списка КЕРОз. Зачечиние. Восстановление согласованного состояния базы данных посредством отмены выполненных операций иногда называется обратным восстановлением.
Аналогично восстановление согласованного состояния базы данных за счет повторного выполнения уже выполненных действий называется прямым восстановлениеч. И наконец„ когда такая восстановительная работа будет завершена, тогда (и только тогда) система будет готова к дальнейшей работе. 14.5. Восстановление носителей Заче юнне. Теча восстановления носителей предстиачяет собой нечто совершенно самостоятельное и не ичеюгцее отношения к тринзакцияч и восстановлению системы после сбоев. Они включени в дивное обсуждение только для завершенности всей картины. Как уже отмечалось в разделе )4.4, отказы носителей — это нарушения наподобие поломки головок дискового накопителя или отказа контроллера дисков, когда некоторая часть базы данных разрушается физически.
Восстановление после такого нарушения включает перезагрузку (или восстиновлеиие) базы данных с резервной копии (или данна) и последующее использование журнала регистрации (как его активной, так и архивной частей) для повторного выполнения всех транзакций, успешно завершенных в системе с момента создания данной резервной копии. При этом нет никакой необходимости отменять транзакции, которые выполнялись в момент отказа носителей, поскольку по определению все обновления, выполненные этими транзакциями, уже полностью отменены (фактически просто утрачены). Таким образом, процедура восстановления носителей подразумевает наличие в системе утилиты копированияувосспгагговлеггия. Функция копирования этой утилиты используется для создания резервной копии в установленные моменты.
(Такие копии могут " Следует ичеть в виду, члго описывае чан здес процедура восстановления системы очень упрощена. В часпгноспги, здесь показано, что сначала выполняются операции отчены, а затем — операции повторноео выполнения Первые системы действительно так работали, но свере.ченные системы по сообразсенинч пронзводнтегъностн обычно работают несколько иначе (см. (4 /77, (4 79 й 552 Часть ()'. Управление транзакциями сохраняться либо на ленте, либо на других устройствах архивирования.
Совсем необязательно, чтобы оии создавались на устройствах хранения с прямым доступом.) Функция восстановления утилиты используется в случае отказа носителя для воссоздания базы данных с требуемой резервной копии. 14.6. Двухфазная фиксация В этом разделе кратко рассматривается очень важное усовершенствование основной концепции фиксации/отката транзакций, а именно — протокол двухфазной фиксации.
Использование этого протокола оказывается важным всякий раз, когда определенная транзакция может взаимодействовать с несколькими независимыми менеджераии ресурсов, каждый из которых распоряжается собственным набором восстанавливаемых ресурсов и поддерживает собственный журнал регистрацииз. Например, пусть транзакция, выполняемая на мэйнфрейме 1ВМ, модифицирует как базу данных СУБД!МБ, так и базу данных СУБД РВ2 (между прочим, подобная транзакция вполне допустима). Если транзакция завершается успешно, то все выполненные ею обновления, как в базе данных СУБД !МБ, так и в базе данных СУБД РВ2, должны быть зафиксированы. В противном случае для всех внесенных обновлений должен быть выполнен откат. Иначе говоря, недопустима ситуация, когда обновления информации в базе данных СУБД 1МБ зафиксированы, а для обновлений информации в базе данных СУБД РВ2 выполнен откат, или наоборот.
Суть в том, что в подобном случае транзакция перестанет быть атомарной. Отсюда следует, что для транзакции не имеет смысла выполнять оператор СОММ1Т в СУБД !МБ и оператор КОЬЬВАСК в СУБД РВ2. Даже если один и тот же оператор будет выдан для обеих СУБД, система все равно может дать сбой между завершением этих двух операций и полученные результаты окажутся неудовлетворительными. Вместо этого транзакция должна выдать общесистемную команду СОММ1Т (нли КОЬЬВАСК). Выполнением таких глобальных операций фиксации или отката управляет системный компонент, называемый координатором.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
