Тема_10 (1122364), страница 5
Текст из файла (страница 5)
Базы данных66ЖурнализВосстановление после мягкого сбоя (27)Восстановление физической согласованности базы данных (18)Журнализация постраничных изменений (10)Потенциальное переполнение логического журнала регулируетсяследующим образомНа пути к достижению максимально возможного размера журналаустанавливаются «желтая» и «красная» зоныКогда записи в журнал достигают «желтой» зоны,oЕсли все существующие транзакции завершаются до достижения«красной» зоны,oавтоматически выполняется архивация базы данных или логическогожурналаЕсли какие-то транзакции не успевают завершиться до достижения«красной» зоны журнала,ooвыдается предупреждение администратору базы данных и прекращаетсяобразование новых транзакцийвыполняется их аварийный откат,после чего производится архивация базы данных или журналаЕстественно, размер «желтой» и «красной» зон логическогожурнала должен устанавливаться администратором базы данных сучетом максимально допустимого числа одновременносуществующих транзакций и их возможной протяженности17.12.2009С.Д.Кузнецов.
Базы данных67ЖурнализВосстановление после мягкого сбоя (28)Восстановление физической согласованности базы данных (19)Журнализация постраничных изменений (11)В отличие от этого, физический журнал существуетсравнительно недолгое время интервал времени между соседними операциями установкиточки физической согласованности базы данныхи, как правило, занимает существенно меньшее дисковоепространство, чем логический журналПри выполнении операции установки точки физическойсогласованности выполняются следующие действия: прекращают инициироваться новые логические операции после завершения всех выполняемых логических операцийпроисходит выталкивание во внешнюю память всехмодифицированных страниц буферного пула17.12.2009С.Д.Кузнецов.
Базы данных68ЖурнализВосстановление после мягкого сбоя (29)Восстановление физической согласованности базы данных (20)Журнализация постраничных изменений (12)формируется и выталкивается во внешнюю память логическогожурнала специальная запись о точке физически согласованногосостоянияв случае успешного предыдущего действияooПредпоследняя операция является атомарнойразрешается инициация новых логических операций,и физический журнал пишется зановоЭто опять же запись одного блока на дискЕсли она успешно выполняется,то при следующем восстановлении после мягкого сбоя будетиспользоваться новая точка физически согласованного состояния,иначе ситуация воспринимается как мягкий сбой с восстановлениемлогически согласованного состояния базы данных от предыдущей точкифизически согласованного состоянияoс оповещением об этом администратора базы данных17.12.2009С.Д.Кузнецов.
Базы данных69ЖурнализВосстановление базы данных после жесткого сбоя (1)Понятно, что для восстановления последнегосогласованного состояния базы данных послежесткого сбоя журнала изменений базы данныхявно недостаточноСамый простой способ восстановленияосновывается на использованииВосстановление начинается с обратногокопированиялогического журнала иархивной копии базы данныхна исправный носительбазы данных из архивной копии17.12.2009С.Д.Кузнецов. Базы данных70ЖурнализВосстановление базы данных после жесткого сбоя (2)Затем для всех закончившихся транзакцийвыполняется redo,Более точно, происходит следующее:т.е.
операции повторно выполняются в прямом смыслепо журналу в прямом направлении выполняются всеоперациидля транзакций, которые не закончились к моментусбоя, выполняется откатОчевидно, что после этого будет полученохронологически последнее до момента жесткого сбоялогически согласованное состояние базы данных17.12.2009С.Д.Кузнецов.
Базы данных71ЖурнализВосстановление базы данных после жесткого сбоя (3)При некоторой дисциплине выполнения логических операцийнад базой данных при восстановлении базы данных послежесткого сбоя можно просто последовательно повторновыполнять операции в соответствии с журнальнымизаписями, не обращая внимание на то, в каких транзакциях онивыполнялись до жесткого сбояВ частности, если сериализация транзакций основываетсяна блокировках объектов, то эта дисциплина заключается втом, что при выполнении операции в штатном режиме нужно сначала дождаться удовлетворения блокировки изменяемогообъекта, затем поместить запись в буфер логического журнала, и только после этого реально выполнять операцию17.12.2009С.Д.Кузнецов.
Базы данных72ЖурнализВосстановление базы данных после жесткого сбоя (4)На самом деле, поскольку жесткий сбой несопровождается утратой буферовоперативной памяти,можно восстановить базу данных до такогоуровня,oчтобы можно было продолжить даже выполнениенезавершенных транзакцийНо обычно это не делается, потому чтовосстановление после жесткого сбоя – этодостаточно длительный процесс17.12.2009С.Д.Кузнецов. Базы данных73ЖурнализВосстановление базы данных после жесткого сбоя (5)Хотя к ведению журнала предъявляютсяособые требования по части надежности,в принципе возможна и его утратаТогда единственным способомвосстановления базы данных являетсявозврат к архивной копииКонечно, в этом случае не удастсяполучить последнее согласованноесостояние базы данных,но это лучше, чем ничего17.12.2009С.Д.Кузнецов.
Базы данных74ЖурнализВосстановление базы данных после жесткого сбоя (6)Последний вопрос, который здесь следует обсудить, касаетсяпроизводства архивных копий базы данных и/или журналаСамый простой способ состоит в архивировании базы данных появному указанию администратора или при переполнении журналаНо можно выполнять архивацию базы данных реже, чемпереполняется журналВместо базы данных можно архивировать сам журналВ пределе для полного восстановления базы данных послежесткого сбоя достаточно иметьисходную архивную копию базы данных,последовательность архивных копий журналови последний логический журналМожет показаться, что восстановление базы данных на основетаких архивных источников будет занимать недопустимо большоевремя,однако здесь возможна значительная оптимизация17.12.2009С.Д.Кузнецов. Базы данных75ЖурнализВосстановление базы данных после жесткого сбоя (7)Во-первых, архивированный логический журнал можно сжиматьДля этого для каждого объекта базы данных нужноНа следующем слайде показан процесс сжатияпоследовательности журнальных записей, соответствующихпоследовательности операций над кортежем, у которогонайти последовательность журнальных записей, относящихся к этомуобъекту, в хронологическом порядкеи заменить их одной записью, соответствующей операции надобъектом, результат которой эквивалентен результатупоследовательного выполнения журнализованных операций изпостроенной последовательностиtid = kи имеются четыре целочисленных поляЕсли хронологически последней в последовательности являетсязапись, соответствующая операции DELETE, то после сжатия этойпоследовательности она станет пусто17.12.2009С.Д.Кузнецов.
Базы данных76ЖурнализВосстановление базы данных после жесткого сбоя (8)Процесс сжатия последовательности журнальных записей17.12.2009С.Д.Кузнецов. Базы данных77ЖурнализВосстановление базы данных после жесткого сбоя (9)Во-вторых, точно таким же образом можно совместно сжать двахронологически последовательных полных или сжатых журналаТаким образом, для восстановления после жесткого сбоя можновоспользоватьсяСнова могут возникнуть сомнения относительно сложности ипродолжительности процесса сжатия журналаНо здесь следует заметить, что эта работа может выполняться наотдельном компьютере в режиме offlineКроме того, если имеетсяисходной архивной копией,одним сжатым архивным журналоми последним логическим журналомархивная копия базы данных,сжатый архивный журнали набор еще не сжатых архивных журналов,то этого уже достаточно для восстановления, так что срокизавершения процесса полного сжатия не являются критическими17.12.2009С.Д.Кузнецов.
Базы данных78ЖурнализЗаключениеВ этой лекции рассматривались основныепринципы и алгоритмы подсистем СУБД,предназначенных дляуправления буферами основной памяти,журнализации ивосстановления базы данных после различныхсбоевИзложение велось без техническихдеталей, таких как возможные структурыданных журналов17.12.2009С.Д.Кузнецов. Базы данных79Журнализ.