Учебное пособие 800353

необходимых ей элементов данных и помещает их в локальные переменные. Любые обновления применяются только к локальной копии данных, но не к информации, сохраняемой в самой БД.

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

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

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

200

1.Все транзакции М с более старыми временными отметками должны быть уже завершены до начала выполнения транзакции Т:

конец (М) = начало (Т)

2.Если транзакция Т стартовала до завершения какой-либо из транзакций М, то

а) множество элементов данных, записанных стартовавшей ранее транзакцией, не должно включать ни одного из элементов данных, прочитанных данной транзакцией;

б) фаза записи стартовавшей ранее транзакции должна быть завершена до прихода текущей транзакции в фазу проверки:

начало (Т)<конец (М)<проверка (Т)

Уровень детализации блокируемых элементов данных Уровень детализации – это размер элементов данных, выбранных в качестве защищаемой единицы для протокола

управления параллельностью.

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

Вся БД Отдельный файл

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

Отдельная запись Отдельное поле

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

201

достичь нескольких компромиссов, что следует учитывать при выборе размера элемента данных в системе.

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

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

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

202

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

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

Для сокращения объемов поисков, необходимых для выявления блокировок, СУБД может использовать иную стратегию выполнения блокировки, называемую

многоуровневой блокировкой. В ней используется новый тип блокировки – блокировка намерения. Когда блокируется любой из узлов схемы, блокировка намерения устанавливается на все узлы – предки данного узла.

Блокировка намерений может быть либо разделяемой – для чтения, - любо эксклюзивной – для записи. Разделяемая блокировка намерения конфликтует только с эксклюзивной блокировкой, тогда как эксклюзивная блокировка намерения конфликтует как с разделяемой, так и с эксклюзивной блокировкой.

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

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

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

Ни один узел не может быть освобожден, пока не будут освобождены все его потомки.

203

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

6.5 Восстановление данных

Восстановление данных – это процесс возвращения базы данных в корректное состояние, утраченное в результате сбоя или отказа.

Концепцию восстановления данных можно представить как службу СУБД, гарантирующую надежное сохранение БД в согласованном состоянии даже при наличии в системе отказов. Как подобная служба может быть организована?

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

Существует множество различных типов отказов, которые могут влиять не только на содержимое ОЗУ, но и вторичной памяти:

Аварийное прекращение работы, вызванное ошибкой оборудования или программного обеспечения, приведшей к разрушению содержимого ОЗУ;

Отказ носителей информации; Ошибка прикладных программ;

Стихийные бедствия – пожары, отказы в сети электропитания;

Небрежное или легкомысленное обращение персонала; Диверсии и преднамеренное разрушение или

уничтожение данных, оборудования или ПО.

Какова бы ни была причина отказа, может быть два принципиально разных следствия – утрата содержимого ОЗУ и утрата копии БД на дисках.

204

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

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

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

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

глобальный откат.

Функции восстановления

Типичная СУБД должна предоставлять такие функции восстановления как:

205

механизм резервного копирования, предназначенного для периодического создания копий БД;

средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в БД изменения;

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

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

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

– например, на магнитных лентах.

Файл журнала. Для фиксации хода выполнения транзакций в БД СУБД использует специальный файл, который называется журналом. В него может помещаться след. информация:

записи о транзакциях, включающие:

-идентификатор транзакции;

-тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмены или фиксации транзакции);

-идентификатор элемента данных, вовлеченного в операцию обработки БД,

-копию элемента данных до операции;

-копию элемента данных после операции;

206

- служебную информацию файла журнала, включающую указатели на предыдущую и последующую записи журнала для этой транзакции;

записи контрольных точек.

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

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

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

Создание контрольных точек.

Контрольная точка – это момент синхронизации между базой данных и журналом регистрации транзакций. Все

207

буфера системы принудительно записываются во вторичную память системы.

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

Запись всех имеющихся в ОЗУ записей журнала во вторичную память;

Запись всех модифицированных блоков в буфера БД во вторичную память;

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

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

Методы восстановления

Тип процедуры, которая будет использоваться для восстановления БД, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта:

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

208

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

Метод восстановления с использованием отложенного обновления

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

При запуске транзакции в журнал помещается запись

Начало транзакции.

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

209