предупреждение

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

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

Последовательные операции

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

Предупреждение

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

При фиксации просто нужно записать элемент фиксации в журнал и очистить буфер (а в версии 7.3 еще снять блокировки уровня строки, если измененные блоки все еще находятся в памяти).

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

т 7rt

QQfJ

Удаленные DML-операции

Мы уже несколько раз использовали термин удаленные DML-операции . Под DML-операциями (Data Manipulation Language - язык манипулирования данными) мы подразумеваем только те операции, которые задаются следующими SQL-предложениями:

INSERT UPDATE DELETE

SELECT...FOR UPDATE LOCK

Имеющиеся в Oracle средства поддержки распределенных баз данных не обеспечивают непосредственную поддержку удаленных DCL-операций (Data Control Language - язык управления данными), таких как GRANT и REVOKE, и удаленных DDL-операций (Data Definition Language - язык определения данных), например CREATE, ALTER, DROP. Однако средства поддержки симметричной репликации включают PL/SQL-пакет под названием DMBSREPCAT, который способен выполнять удаленные DDL-операции, необходимые для настройки схемы распределенной репликации.

Однако несмотря на это, если прикладная логика потребует, чтобы процесс мог создавать таблицы, выдавать разрещения, усекать таблицы - короче, выполнять все, помимо запросов и пяти выщеупомянутых DML-операций, вы не сможете выполнить соответствующие операции на удаленном узле. Мы, конечно, можем ответить вопросом: а почему вы думаете, что вам понадобится выполнять такие операторы в рамках обычных транзакций? Мы бы напомнили также, что в Oracle DDL-операции имеют две неявные фиксации:

когда выдается DDL-операция, фиксируются все текущие транзакции данного сеанса;

когда DDL-операция заверщается, то она фиксируется (или откатывается, если обнаружена ошибка).

Таким образом, DDL-операция всегда вызывает заверщение текущей транзакции.

Синхронные удаленные вызовы процедур (RPC)

Помимо возможности выдавать удаленные DML-операции, мы также можем вызывать удаленную процедуру - либо через синоним, либо явно задавая канал связи БД:

success := stock.alloc@stores ( cust id => C155

, part no => AC7/95 , qty => 6

л IP

Это исключительно мощный способ выдачи удаленных DML-операций и даже удаленных запросов, потому что, во-первых, при этом сокращается число сообщений, передаваемых по сети (требуется всего одна пара сообщений независимо от объема работы, которую нужно выполнить на удаленном узле), а во-вторых, обеспечивается инкапсуляция. В локальной среде мы должны знать только то, что нужно сделать, а не то, какие структуры данных необходимы для этого.

и сведению

Мы настоятельно рекомендуем программировать все ссылки между приложениями с использованием RPC, чтобы предотвратить возникновение так называемой взаимозависимости схем. Она может возникнуть в случае, когда несколько приложений используют удаленные запросы и удаленные DML-операции для доступа к данным друг друга. Если доступ осуществляется непосредственно через SQL, то каждое приложение зависит от стабильности схемы базы данных в другом приложении и ни одна схема не может быть изменена без соответствующих изменений во всех приложениях, которые на нее ссылаются.

Используя вместо SQL вызовы процедур, мы можем создать один уровень изоляции, который поможет облегчить проблему взаимозависимости схем. Применение пакетных процедур и функций позволяет дополнительно уменьшить масштабы этой проблемы, так как дает возможность прибегнуть к перегрузке. Предположим, что мы решили ввести новую версию функции alloc, в которой требуемая дата (NEEDED) является обязательным параметром, После выполнения перегрузки нет необходимости переделывать существующие вызовы - они будут работать. Это иллюстрирует приведенный ниже код.

Учтите, что и вызывающие, и вызываемые базы данных должны поддерживать Distributed Option, следовательно, функция alloc сама может производить удаленные запросы, DML-операции и вызовы процедур. Отметим также, что этот процесс может быт многоуровневым, что серьезно влияет как на время реакции, так и на готовность.

Function alloc ( cust id in number - новый формат идентификатора пользователя , part no in varchar2 - номер детали , qty in number - необходимое число единиц

, needed in date - требуемая дата ) return boolean is

BEGIN

END; - alloc

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