Алгоритм - Двухфазная фиксация изменений
Протокол двухфазной фиксации изменений управляет выполнением транзакций, изменяющих данные нескольких узлов. Основная идея двухфазной фиксации заключается в следующем: недопустима ситуация при которой транзакция, изменяющая данные в нескольких узлах, выполняется в одних узлах и не выполняется в других узлах. Транзакция должна быть либо успешно выполнена во всех узлах, либо не выполнена ни в одном узле.
Например, следующие СУБД поддерживают выполнение двухфазного протокола фиксации изменений:
- Informix On-Line фирмы Informix Software;
- Ingres Intelligent Database фирмы Ingres Corp;
- Oracle (version 7) фирмы Oracle Corp;
- Sybase System 10 фирмы Sybase Inc.
Правда Ingres, Informix и Oracle делают это несколько лучше, чем Sybase. Для указания точки фиксации в них достаточно выполнить 1 команду (один оператор в программе). У Sybase для реализации протокола двухфазной фиксации приходится в каждом приложении писать процедуру из нескольких операторов.
Реализация протокола двухфазной фиксации у Ingres, Informix и Oracle не требует большого труда от программиста. Однако она выполняется по жесткому, заранее заданному алгоритму. У Sybase алгоритм выполнения двухфазной фиксации можно адаптировать к конкретным условиям, но при этом придется заниматься программированием.
Очень мощный и сложный алгоритм реализации протокола двухфазной фиксации изменений реализован в 7 версии СУБД Oracle. Он состоит из следующих этапов:
- Запускается распределенная транзакция, включающая команду COMMIT;
- Этап подготовки:
а) узел-родитель обращается к каждому из своих узлов-детей с просьбой «дать обещание», что он зафиксирует или откатит свою часть изменений только после получения определенной команды;
б) после того, как все узлы-дети готовы к работе, узел-родитель записывает в журнал redolog информацию о транзакции и устанавливает специальный флаг в состояние, говорящее о готовности узла к работе;
в) узел сообщает своему узлу-родителю о том, что он готов к работе;
г) узел не может завершить транзакцию до тех пор, пока не получит на это разрешение от узла родителя.
- Этап фиксации
а) узел записывает в журнал redolog информацию о том, что он фиксирует сделанные изменения (или откатывает их, если были ошибки во время этапа подготовки);
б) узел дает команду своим узлам-детям выполнить фиксацию изменений (или откатить изменения);
в) узел информирует свой узел-родитель о том, что фиксация выполнена (или откачена);
г) после того, как все узлы зафиксировали или откатили изменения, снимается блокировка ресурсов.
Ключом к пониманию этого алгоритма является фраза «дать обещание», которая говорит о том, что некоторые совместные действия (фиксация или откат) будут выполнены в будущем. Фиксация изменений выполняется в каждом узле самостоятельно, поэтому узлы не должны ждать пока закончится фиксация в других узлах. Этот механизм можно использовать для защиты обновлений, выполняемых на большой машине, от обновлений, выполняемых на связанных с ней PC. Важно отметить, что при распределенном обновлении в качестве узлов фиксации могут использоваться и базы данных других СУБД и базы данных младших версий СУБД ORACLE. При этом двухфазная фиксация также будет гарантирована.
До сих пор среди специалистов идут споры о том, плох или хорош предлагаемый подход. Многие считают, что большинству пользователей нужна не полномасштабная распределенная БД, а возможность копировать данные во множество узлов под контролем единого центрального узла.