Методы распределения данных, конечно, очень важны, однако сердцем современных распределенных СУБД является протокол двухфазной фиксации изменений. Этот протокол управляет выполнением транзакций, изменяющих данные нескольких узлов. Основная идея двухфазной фиксации заключается в том, что транзакция должна быть либо успешно выполнена во всех узлах, либо не выполнена ни в одном; ситуация, при которой транзакция, изменяющая данные в нескольких узлах, выполняется в одних узлах и не выполняется в других, абсолютно недопустима.
Все рассматриваемые СУБД поддерживают выполнение двухфазного протокола фиксации изменений. ВIngres, Informix и Oracle7 для указания точки фиксации достаточно выполнить одну команду (один оператор в программе).
Очень мощный и сложный алгоритм реализации протокола двухфазной фиксации изменений реализован в Oracle 7. он состоит из следующих этапов.
1. Запускается распределенная транзакция, включающая команду COMMIT.
2. Подготовка:
· родительский узел обращается к каждому из своих дочерних узлов с просьбой “пообещать”, что они зафиксируют или откатят свою часть изменений только после получения соответствующей инструкции;
· после того как все дочерние узлы готовы к работе, родительский узел записывает в журнал информацию о транзакции и устанавливает специальный флаг в состояние, говорящие о готовности узла к работе;
· узел сообщает своему родительскому узлу о том, что он готов к работе;
· узел не может завершить транзакцию до тех пор, пока не получит на это разрешение от родительского узла.
3. Фиксация:
· узел записывает в журнал информацию о том, что он фиксирует сделанные изменения (или откатывает их, если были ошибки на этапе подготовки);
· узел дает команду своим дочерним узлам выполнить фиксацию изменений (или откатить изменения);
· узел информирует свой родительский узел о том, что фиксация выполнена (или был произведен откат);
· после того как все узлы зафиксировали или откатили изменения, снимается блокировка ресурсов.
Фиксация изменений выполняется в каждом узле независимо, поэтому узел не должен ждать окончания фиксации в других узлах. Этот механизм можно использовать для защиты обновлений, выполняемых на большой машине, от обновлений, выполняемых на связанных с ней ПК. Важно отметить, что при распределенном обновлении в качестве узлов фиксации могут использоваться и базы данных других СУБД, в том числе более ранних версий Oracle. При этом двухфазная фиксация также будет гарантирована.
Многие специалисты считают, что большинству пользователей нужна не полномасштабная распределенная БД, а возможность копировать данные в множество узлов под контролем единого центрального узла, однако при этом система в течение некоторого времени будет находиться в рассогласованном состоянии; о других недостатках такого подхода уже говорилось выше (в связи с системой организации словарей и каталогов данных в СУБД Ingres).
Важной характеристикой распределенной БД являются методы, используемые в ней для обеспечения ссылочной целостности данных, т.е. согласованности между данными основной таблицы и таблиц, связанных с ней. Ссылочная целостность может поддерживаться либо с помощью триггеров, либо с помощью декларативных ограничений целостности.
Триггеры обычно применяются для обработки данных, необходимой в конкретной прикладной программе; триггер представляет собой просто часть соответствующей программы и пишется на языке программирования СУБД. Примером может служить триггер обеспечения связи между основной таблицей и связанной с ней рабочей при выработке данных. Такой триггер при переходе от одной записи основной таблицы к другой очищает буфер, хранящий старые записи рабочей таблицы, и производит выборку записей рабочей таблицы, связанных с новой записью основной. Триггеры поддерживаются во всех рассматриваемых СУБД, кроме Informix.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.