Методическое пособие 522

Продолжение табл. 6.14

Т19 имеет временную отметку (Т19), Т20 – (Т20), Т21 – (Т21) (Т19) <(Т20) <(Т21)

*- в момент времени t8 операция записи в Т20 нарушает первое правило записи, приведенное в описании протокола с использованием временных отметок. Поэтому она отменяется и вновь запускается в момент времени t14.

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

Оптимистические технологии

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

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

191

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

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

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

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

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

192

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

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

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

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

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

проверки:

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

Уровень детализации блокируемых элементов данных

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

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

Вся БД

Отдельный файл

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

193

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

Отдельное поле

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

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

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

194

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

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

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

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

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

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

195

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

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

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

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

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

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

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

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

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

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

Отказ носителей информации;

Ошибка прикладных программ;

196

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

Небрежное или легкомысленное обращение

персонала;

Диверсии и преднамеренное разрушение или уничтожение данных, оборудования или ПО.

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

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

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

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

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

197

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

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

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

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

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

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

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

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

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

199

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

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

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

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

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

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

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

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

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

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

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

200