metBD (1084482), страница 25

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 25)

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

(Т19)<(Т20)<(Т21)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вся БД

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

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

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

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

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

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

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

Иерархия уровней детализации.

Уровень 0 БД

Уровень 1 Файл

Уровень 2 Страница

Уровень 3 Запись

Уровень 4 Поле

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

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

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

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

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

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

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

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

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

• Вся БД

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

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

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

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

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

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

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

Иерархия уровней детализации.

Уровень 0 БД

Уровень 1 Файл

Уровень 2 Страница

Уровень 3 Запись

Уровень 4 Поле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристики

Список файлов книги