нимуму время, когда такая ошибка может произойти, но оно, тем не менее, не равно нулю. Серверы 2 и 3 должны держать транзакцию открытой в ожидании уведомления о результате от сервера 1. Если вспомнить архитектуру, описанную в главе 2, решать эту проблему должен процесс RECO. Здесь также вступают в игру операторы COMMIT и ROLLBACK с опцией FORCE. Если причиной проблемы б1л сбой сети между серверами 1, 2 и 3, то администраторы базы данных серверов 2 и 3 могут просто позвонить администратору базы данных сервера 1 и, в зависимости от результатов, выполнить соответствующий оператор фиксации или отката вручную.

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

Нельзя выполнять оператор COMMIT в удаленной базе данных. Фиксировать транзакцию можно только на сервере-инициаторе.

В удаленных базах данных нельзя выполнять операторы ЯОД. Это прямое следствие предыдущего ограничения на фиксацию операторов ЯМД. Фиксировать транзакцию можно только с сервера - инициатора транзакции, поэтому нельзя выполнять операторы ЯОД в связанных базах данных.

В удаленн1х базах данных нельзя выполнять оператор SAVEPOINT. Короче, в удаленных базах данных нельзя выполнять операторы управления транзакцией.

Невозможность управлять транзакцией в удаленной базе данных вполне понятна, поскольку список серверов, задействованных в транзакции, есть только на сервере-инициаторе. В рассмотренной выше конфигурации с тремя серверами, если сервер 2 попытается зафиксировать транзакцию, он не сможет узнать, что в ней задействован сервер 3. В Oracle только сервер 1 может выполнять оператор фиксации. Но после этого сервер 1 может передать управление распределенными транзакциями другому серверу.

Повлиять на то, какой именно сервер будет фиксировать транзакцию, можно путем установки приоритета точки фиксации сервера (с помощью параметра в файле init.ora). Приоритет точки фиксации (commit point strength) задает для сервера относительный уровень важности в распределенной транзакции: чем важнее сервер (чем более доступными должны быть его данные), тем больше вероятность, что он будет координировать распределенную транзакцию. Это может пригодиться в том случае, если необходимо организовать распределенную транзакцию между тестовым и производственным сервером. Поскольку координатор транзакции никогда не сомневается в результатах транзакции, предпочтительнее, чтобы координировал такую транзакцию производственный сервер. Ничего страшного, если ряд открытых транзакций и заблокированных ресурсов останется на тестовой машине. На производственном сервере этого допускать нельзя.

Невозможность выполнять операторы ЯОД в удаленной базе данных, в общем, не так трагична. Во-первых, операторы ЯОД встречаются сравнительно редко. Они выполняются один раз после установки или после обновления программного обеспечения. На производственных системах в ходе работы операторы ЯОД не выполняются (по крайней мере не должн1 выполняться). Во-втор1х, есть способ выполнить ЯОД в удаленной базе данных; для этого с помощью пакета DBMS JOB (он подробно описан в при-

ложении А) формируется очередь заданий. Вместо того чтобы пытаться выполнить оператор ЯОД в удаленной базе данных, можно использовать связь для постановки в очередь задания, которое должно быть выполнено при фиксации транзакции. Такое задание выполняется на удаленной машине, но, не являясь распределенной транзакцией, вполне может включать операторы ЯОД. Именно так службы репликации Oracle выполняют распределенные операторы ЯОД при репликации схемы.

Журналы повторного выполнения и сегменты отката

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

Посмотрим, что происходит при выполнении транзакции следующего вида:

insert into t (х,у) values (1,1); update t set x = x+1 where x = 1; delete from t where x = 2;

Разберем, что происходит при выполнении транзакции, по нескольким направлениям:

что происходит, если возникает сбой после изменения?

что происходит, если все операторы выполняются успешно и результаты фиксируются?

что происходит при откате?

Первый оператор INSERT INTO T будет генерировать как данные повторного выполнения (redo), так и данные отмены (undo). Данных отмены будет достаточно, чтобы избавиться от последствий вставки. Данных повторного выполнения будет достаточно для того, чтобы повторить вставку. Данные отмены могут состоять из нескольких частей. Например, по столбцам X и Y могут быть индексы, и изменения в них также придется отменять при откате. Данные отмены хранятся в сегменте отката. Сегмент отката хранится в табличном пространстве и (это крайне важно) защищен журналом повторного выполнения, как и любой другой сегмент. Другими словами, данные отката обрабатываются так же, как и данные таблицы или индекса, - изменения в сегментах отката генерируют определенные данные повторного выполнения, которые записываются в журнал. (Зачем это делается, станет ясно после описания происходящего при сбое сие-

темы). Данные отмены добавляются в сегмент отката и кэшируются в буферном кэше, как и любые другие данные. Как и генерируемые данные отката, данные повторного выполнения могу состоять из нескольких частей. Итак, после выполнения вставки мы имеем:

Буферный

t. .-----1

......\

Буфер журнала повторного выполнения

Сегмент откатИ Индексы ГтГаблицаТ

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

Гипотетический сценарий: сбой системе! происходит сейчас. Все в порядке. Содержимое области SGA пропало, но хранившееся там нам не нужно. При перезапуске все пойдет так, будто транзакция никогда не выполнялась. Ни один из блоков с изменениями не сброшен на диск; не сброшены и данные повторного выполнения.

Гипотетический сценарий: прямо сейчас заполняется буферн1й кэш. Процесс DB должен освободить место и сбросить на диск только что измененные блоки. В этом случае процесс DBWR сначала попросит процесс LGWR сбросить на диск блоки журнала повторного выполнения, защищающие блоки базы данных. Прежде чем процесс DBWR сможет записать на диск измененные блоки, процесс LGWR должен сбросить на диск данные повторного выполнения, связанные с этими блоками. В этом есть смысл, так как, сбросив на диск измененные блоки таблицы Т и не сбросив при этом данные повторного выполнения для соответствующих блоков отмены, в случае сбоя системы мы получим измененный блок таблицы Т, для которого нет соответствующих данных отмены. Нужно сбросить на диск буферы журнала повторного выполнения, прежде чем записывать туда эти блоки, чтобы при необходимости отката можно было повторно выполнить все изменения для перевода области SGA в текущее состояние.

Второй сценарий поможет продемонстрировать, что привело к созданию подобной системы. Набор условий если мы сбросили блоки таблицы Т, но не сбросили данные повторного выполнения для блоков отмены, и произошел сбой системы становится сложным. При добавлении пользователей, дополнительных объектов и одновременной обработки все станет еще сложнее.

Итак, имеется ситуация, представленная на предыдущем рисунке. Мы сгенерировали ряд измененных блоков таблицы и индекса. В результате был создан ряд новых блоков в сегменте отката, и все три типа блоков сгенерировали определенный объем защи-