Методы управления транзакциями в XML-ориентированных СУБД

• Автор: Плешачков, Петр Олегович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Москва
• Количество страниц: 165 с. : ил.

Содержание
Введение

1 Управление транзакциями и технологии X

1.1 Обзор методов управления транзакциями в СУБД.

1.1.1 Методы обеспечения изоляции параллельных транзакций

1.1.2 Методы обеспечения атомарности и надежности транзакций.

1.2 Платформа X

1.2.1 Расширяемый язык разметки X

1.2.2 Язык запросов X.

1.2.3 Язык модификаций X.

1.3 ХМЬориснтироианиыс СУБД.

1.3.1 РСУБД с поддержкой X.
1.3.2 Прирожденные XСУБД
1.4 Выводы.
2 Существующие методы управления параллельными Xтранзакциями
2.1 Xтранзакцнн в реляционных СУБД
2.1.1 Блокировки в РСУБД для Xдокументов при использовании
отображения Xдокументов на отношения
2.1.2 Блокировки в РСУБД для Xдоку ментов при использовании типа X или метода
2.2 Xтрапзакции в прирожденных XСУБД.
2.2.1 Основные приложения XСУБД.
2.2.2 Обзор родственных работ по изоляции Xтранзакций.
2.3 Выводы.
3 Протокол изоляции Xтранзакций X
3.1 Введение.
3.2 Основные определения и обозначения
3.3 Семантические особенности языков ХСиегуХирсЫе. Об
3.3.1 Путевые выражения. СО
3.3.2 Запросы на ХСиегу
3.3.3 Операция вставки новых узлов .
3.3.4 Операция удалении узлов.
3.3.5 Операция переименования узлов.
3.4 ХОвЬблокпровки.
3.4.1 Структурные блокировки
3.4.2 Предикатные блокировки
3.4.3 Логические блокировки.
3.5 ХИвЬпланнровщик
3.0 Обоснование корректности протокола ХЭвЬ
3.7 Дополнительные оптимизации в ХБСЬ.
3.8 Примеры использования протокола ХБСЬ
3.9 Выводы
4 Управление ХМЪтранзакциями в реляционных СУБД
4.1 Многоуровневые модели транзакций и их применение для управления ХМЬ
транзакциями в РСУБД.
4.2 Применение ХИвЬ для изоляции транзакций в РСУБД.
4.2.1 Поддержка описывающей схемы в БХТМ .
4.3 Атомарность ХМЬтраизакций в двухуровневой модели.
4.4 Индивидуальные откаты транзакций п восстановление базы данных после сбоев
4.5 Повышение параллелизма внутри ХМЬтранзакций
4.0 Экспериментальная оценка семантического менеджера управления ХМЬ
транзакциями .
4.6.1 Экспериментальная установка
4.0.2 Эксперимент 1 накладные расходы.
4.0.3 Эксперимент 2 пропускная способность
4.6.4 Эксперимент 3 время отклика.
4.0.5 Эксперимент 4 время отклика транзакций при использовании
параллелизма внутри транзакций.
4.7 Выводы.
5 Управление транзакциями и прирожденных ХМЬСУБД
5.1 Требования к управлению транзакциями в прирожденных ХМЬСУБД
5.2 Снимки базы данных и их применение для изоляции читающих и изменяющих транзакций
5.3 Продвижение снимков
5.4 Отображение логических версии па физические версии.
5.5 Адресация версий и идентификация страниц из снимков базы данных
5.6 Изоляция Ти транзакций
5.6.1 Изоляция Тш транзакций на уровне блоков.
5.6.2 Изоляция Тю транзакций на основе протокола ХБвЬ.
5.7 Метод восстановления транзакций после мягких сбоев в системе.
5.7.1 Физический журнал.
5.7.2 Логический журнал.
5.7.3 Контрольные точки базы данных.
5.7.4 Индивидуальный откат транзакции.
5.7.5 Восстановление базы данных после сбоя.
5.8 Экспериментальная оценка методов управления ХМЬтраизакциями.
5.8.1 Эксперимент 1 пропускная способность.
5.8.2 Эксперимент 2 время отклика
5.9 Выводы.
Заключение
Список литературы


В зависимости от тина операции и уже обработанных запросов он определяет, выполнить ли операцию или же заблокировать транзакцию до того момента, когда конфликт будет разрешен. В 2PL операция записи конфликтует с любой операцией другой транзакции над тем же элементом данных. Операции чтения совместимы между собой. Когда 2Р1гплаиировщик получает запрос на операцию Рі(х), он проверяет, конфликтует ли данная операция хотя бы с одной из запланированных ранее. Если ист, то транзакция становится обладателем соответствующего захвата, и операция выполняется. Если да, то выполнение транзакции приостанавливается до тех пор, пока она не сможет получить доступ к требуемому элементу. Если планировщик захватил элемент х в каком-либо режиме доступа, то он не может отпустить захват как минимум до тех пор, пока физическая операция, соответствующая запросу не завершится. Если планировщик отпустил хотя бы один захват, принадлежащий транзакции 7}, то эта транзакция больше не может захватывать никаких объектов БД. Первые два правила защищают транзакции от совместного доступа к данным в конфликтующих режимах. Третье правило принято называть фазовым. От пего, кстати говоря, н происходит название протокола. Каждая транзакция логически разделяется на две фазы. Во время первой фазы она берет захваты на те объекты, которые ей требуются, а во время второй отпускает их по мере завершения работы с ними. Именно третье правило обеспечивает логическую корректность работы параллельных транзакций. Фактически, оно обеспечивает сериализуем ость допускаемых протоколом планов. Транзакции, обрабатываемые 2PL-планировщиком, сериализуются в порядке завершения. Иными словами, результат их работы эквивалентен последовательному выполнению в том порядке, в котором они завершились. Важным мастным случаем протокола 2PL является строгий двухфазный протокол синхронизации. Он отличается от 2PL только тем, что блокировки транзакциями могут сниматься только при фиксации транзакции. Как правило, строгий двухфазный протокол обозначают символом S2PL (Strict Two Phase Locking). Следующий рассматриваемый нами протокол сериализует транзакции по временной метке их старта. Согласно этому протоколу, каждая транзакция получает временную метку в момент старта. Подсистема управления транзакциями присваивает эту метку каждой последующей операции этой транзакции. Основным правилом работы планировщика, основанного на временных метках, является правило “временного упорядочивания” (Timestamp Ordering rule, ТО rule): Для каждой пары конфликтующих операций Р(х) и Qj(x) операция Р, выполняется раньше Qj тогда и только тогда когда временная метка Pi меньше временной метки Qj. Если для операции Qi(x) имеется операция Pj(x), уже выполненная на этот момент, такая, что временная метка Tj (здесь и далее мы будем использовать обозначение ts(Tj)) больше чем ts(Qi)j то для транзакции 7} должен быть выполнен откат, и затем она может быть запущена заново с новой временной меткой. В противном случае операция выполняется. Информация об этом запоминается во внутренних структурах планировщика, который должен учитывать этот факт при последующей работе (например, при обработке операции другой транзакции над этим элементом данных). Этот протокол очевидным образом допускает лишь сериализуемые планы. Однако на практике он фактически не используется из-за очень высокой степени откатов при сильной нагрузке. При этом важно отметить, что чаще всего это “воображаемые” конфликты. ТО-планировщикн слишком строги. Они накладывают слишком жесткие ограничения на порядок поступления операций, чтобы гарантировать ссриализусмость. В реальности многие из операций, вызывающих откат согласно ТО-правнлу, не нарушают сериализуемости генерируемого плана. Таким образом, протокол имеет скорее теоретический, чем практический интерес, в отличие от 2PL, который очень широко используется в индустрии. Однако различные гибридные протоколы (например миоговсрсиоиный протокол MVTO), использующие ТО-илаиировщик в качестве базы, широко используются на практике.