- •Конспект лекций не официальный, возможны ошибки! Еремеев н.Б.
- •Распределенная база данных
- •Пример транзакции
- •Пример рбд
- •Прямые и косвенные соединения
- •Объекты: схемы и именования в рбд
- •Удаленные и распределенные предложения
- •Прозрачность в системе рбд
- •Архитектура рбд Oracle
- •Прозрачность в рбд. Прозрачность местоположения.
- •Прозрачность транзакций.
- •Прозрачность дублирования.
- •Разрешение имен в рбд
- •Снимки.
- •Двухфазный commit.
- •Фаза подготовки.
- •Фаза подтверждения
- •Создание точки подтверждения.
- •Проектирование распределенных приложений.
- •Уникальность имен.
- •Последовательности в распределенных транзакциях.
- •Обработка ошибок в удаленных процедурах.
- •Разрешение проблем распределенных транзакций
- •Снимки. Управление ими.
- •Спецификация определяющего запроса снимка (as ...).
- •Порядок создания снимков и их журналов:
- •Альтернативы снимкам.
- •Дублирование таблиц с помощью триггеров:
- •Создание триггера
- •Управление снимками
- •Создание снимков
- •Установление параметров памяти для снимков.
- •Конфигурирование автоматических обновлений
- •Ручное обновление снимков.
- •Связь между декларативными ограничениями и снимками.
- •Управление журналами снимков.
- •Внутренняя реализация журнала снимка.
- •Удаление журнала снимков.
- •Управление распределенными бд администратором.
- •Принципы простроения глобального имени бд:
- •Безопасность бд.
- •Характеристики и квоты различных табличных пространств.
- •Ресурсные лимиты и профили пользователей.
- •Лицензирование.
- •Привилегии и роли.
- •Защита таблиц.
- •Защита обзоров:
- •Усиление защиты таблиц через обзоры:
- •Защита процедур.
- •Табличные пространства и файлы данных Файлы данных
- •Табличное пространство
- •Объекты табличного пространства
- •Блок данных
- •Экстенты
- •Сегменты
- •Копирование и восстановление баз данных
- •Рекомендации по копированию баз данных.
- •Стратегии копирования Стратегии копирования в режиме no archive log
- •Стратегии копирования в режиме archive log
- •Процедуры копирования.
- •Процедура полного копирования базы данных
- •Восстановление
- •Опции предложений Audit и NoAudit.
- •Дополнительные опции по аудиту предложений:
- •Включение аудита
- •Выключение аудита.
- •Контролирование роста и размера аудиторского журнала.
- •Защита аудиторского журнала
- •Аудит с помощью триггеров
- •Поддержка национальных языков.
- •Лингвистическая сортировка.
- •Перекрытие стандартных умолчаний.
- •Форматы чисел и дат.
- •Объекты в Oracle.
- •Атрибуты
- •Сравнение объектов
- •Синтаксис объявления типов
- •Объявление и инициализация объектов
- •Вызов методов
- •Хранение объектов в бд
- •Использование оператора select
- •Вставка объектов
- •Обновление объектов
- •Удаление объектов
Создание точки подтверждения.
Сила точки подтверждения – это некоторое число, которое назначается при запуске экземпляра Oracle. Администратор сети в праве ее назначить сам. Чем больше значение ее, тем больше возможность, что этот узел будет точкой подтверждения.
При определении стороны точки подтверждения применяются следующие правила:
только читаемый узел (к которому были направлены предложения SELECT) не может быть назначен как сторона точки подтверждения, какой бы силой он не обладал
если все узлы, к которым непосредственно обращается глобальный координатор, имеют одинаковую силу, то Oracle назначает один из узлов стороной точки подтверждения
если распределенная транзакция заканчивается откатом, то точка подтверждения вообще не назначается; вместо этого глобальный координатор отсылает всем команду откатить транзакцию
Пример транзакции на двух узлах:
INSERT INTO orders ...
UPDATE investory@warehouse...
Глобальный координатор должен определить точку подтверждения. Когда он это сделал, то он посылает решение о подготовке всем непосредственно адресуемым узлам в дереве сессии, включая узел, являющийся стороной точки подтверждения. Каждый узел пытаться подготовиться к выполнению транзакции.
Если опрос всех узлов был положительным, то глобальный координатор просит подтвердить транзакцию от стороны точки подтверждения. Она подтверждает транзакцию локально и регистрирует этот факт в своем локальном журнале повторений. Окончательный результат транзакции на всех узлах дерева сессии определен.
Затем следует этап подтверждения транзакции на всех остальных узлах. Сторона точки подтверждения извещает глобального координатора о том, что транзакция подтверждена. При этом она запоминает, что она подтвердила транзакцию до тех пор, пока глобальный координатор не известит ее о том, что транзакция подтверждена для всех действующих в ней узлах. Каждый узел подтверждает транзакцию и записывает данные об этом в журнал, освобождая при этом блокировки ресурсов. После того, как все адресуемые узлы подтвердят транзакцию, глобальный координатор сообщает об этом точке подтверждения. Получив такое сообщение, сторона точки подтверждения удаляет из журнала информацию об этой транзакции.
Виды сбоев, возникающие при завершении транзакции:
сбой машины
сбой сети
сбой программного обеспечения
сбой локальной инстанции
Для разрешения проблем со сбоями используется фоновый процесс RECO. Данный процесс автоматически разрешает сбой распределенной транзакции. Через экспоненциально увеличивающиеся интервалы времени этот процесс на узле пытается восстановить локальную порцию сомнительной распределенной транзакции. При этом автоматически удаляются записи из таблицы «висящих» транзакций.
Таблица висящих транзакций. Она есть в каждой БД Oracle. Это специальная таблица, хранящая информацию о распределенных транзакциях при прохождении ими двухфазного COMMIT. Эта таблица опрашивается через словарный обзор DBA_2PC_PENDING (к нему можно применить SELECT). Этот обзор может быть находиться в следующих состояниях (смотри поле этого обзора STATE) :
collecting – применяется только к глобальным и локальным координаторам; означает, что в данный момент узел находится в процессе сбора информации от других серверов БД;
prepared – узел подготовился и возможно уже сообщил это своему локальному координатору, но еще не получил приказ подтвердить транзакцию; узел удерживает все локальные блокировки данных, необходимые для подтверждения данных;
committed – узел любого типа подтвердил транзакцию, но другие узлы возможно еще не сделали этого, т.е. транзакция висит на других узлах;
forced commit – висящая транзакция может быть подвергнута принудительному подтверждению по усмотрению администратора БД; это означает, что транзакция подтверждена вручную на локальном узле администратора БД;
forced abort – висящая транзакция может быть подвергнута принудительному откату по усмотрению администратора БД, т.е. эта транзакция отменена на локальном узле администратора БД.
Поле DBA_2PC_PENDING.MIXED, называемое флагом смешанного исхода, используется в следующих случаях:
если администратор отменил транзакцию, хотя она была подтверждена, то флаг примет значение true и транзакция будет повреждена;
…..
Информация в таблице висящих транзакций используется фоновым процессом RECO для определения окончательного состояния сомнительных транзакций, или ее может использовать администратор для управления транзакциями в ручном режиме.
Завершенная транзакция означает автоматическое удаление записи о ней процессом RECO, а если поле MIXED будет равно true, то запись остается до момента удаления ее самим администратором.
