FUNCTION alloc ( cust id IN NUMBER

, part no IN VARCHAR2 , qty IN NUMBER

) RETURN BOOLEAN IS

BEGIN

RETURN alloc(TO NUMBER(cust id, part no, qty, TRUNK (SYSDATE)); END; - alloc

В версиях 7.0, 7.1 и 7.2 RPC имеют еще одну, довольно странную, особенность: они могут вызывать ощибки, которые таинственным образом исчезают при следующей попытке выполнить ту же операцию. На первый взгляд, эта особенность может показаться очень удобной. Действительно, если бы при вторичном запуске процесса все ощибки пропадали, программирование значительно облегчалось бы. Почему эта ситуация возникает при использовании RPC - вопрос, скорее, не к проектировщику, а к администратору БД, поэтому мы не будем здесь объяснять, почему так бывает, а просто предостережем проектировщиков: знайте, что если удаленно вызываемые процедуры или пакеты изменяются, то для обеспечения нормальной работы необходимо перекомпилировать весь остальной код, вызывающий эти фрагменты. Для ссылок в одном и том же словаре данных это происходит автоматически, но механизм запуска перекомпиляции на удаленных узлах в ранних версиях не так изящен.

Снимки

Как следует из названия, снимок - это копия таблицы (или таблиц), снятая в некоторый момент времени. Он определяется запросом к таблице или к совокупности таблиц (главной таблице снимка) и может быть простым либо сложным. Механизм снимков позволяет администратору БД определять другие схемы, в которых этот снимок будет регенерироваться с некоторым заданным интервалом.

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

На первый взгляд, снимки кажутся весьма полезными для сопровождения в масштабах всей сети копий таких объектов, как таблицы кодов, т.е. часто используемых, но редко обновляемых таблиц. При помощи фразы WHERE в определяющем запросе можно создавать простые снимки, не содержащие некоторые строки главной таблицы (которые, возможно, на удаленном узле не нужны). Кроме того, используя список SELECT, можно удалить некоторые столбцы - из соображений безопасности или просто из-за того, что они не нужны. Таким образом, простой снимок может быть как горизонтальным, так и вертикальным подмножеством главной таблицы (или и тем, и другим), как показано на рис. 12.5.

ТАБЛИЦА

СНИМОК

Рис. 12.5. Снимок, который является и вертикальным, и горизонтальным подмножеством таблицы

Основные проблемы со снимками касаются их эффективности (даже при ускоренной регенерации) и того факта, что, делая ссылку на снимок из программы, вы не можете быть уверены, что получите самые последние данные. Если надежность значения не имеет (насколько правдоподобно это звучит?), а сервер, на котором расположена главная таблица, может выдержать нагрузку от работы триггеров, выполняющих регистрацию всех внесенных изменений, то простые снимки с ускоренной регенерацией могут быть очень эффективны. Если же вносятся больщие объемы изменений, а затем главная таблица остается стабильной в течение продолжительного времени, то, возможно, лучще подождать завершения внесения изменений и сразу после этого вручную (или программным способом) принудительно выполнить полную регенерацию.

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

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

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

области неудовлетворительны. На решение данной проблемы было нацелено введение групп снимков, которые описаны ниже.

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

Устанавливая интервал регенерации снимка, следует помнить о проблеме ползучего отставания . Она возникает, когда регенерация фактически выполняется не так часто, как планировалось при определении интервала. Это может происходить по нескольким причинам. В частности, потому, что интервал определен как время с момента завершения одной регенерации до начала следующей и, следовательно, при этом не учтена средняя продолжительность регенерации. Кроме того, следует учитывать, что фоновые задачи, выполняющие регенерацию (SNPO, SNP1 и т.д.), активизируются периодически. Если продолжительность периода простоя (определяется параметром JOB QUEUE INTERVAL в файле init.ora) велика по сравнению с интервалом регенерации, то возможно отставание.

Пспроншворсчивыс снимки

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

Обновляемые снимки

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

В версии 7.1.6 снимки стали факультативно обновляемыми. Это означает, что простой снимок, включающий столбцы типа NOT NULL главной таблицы, можно обновлять, и все внесенные изменения будут распространяться обратно в родительскую таблицу. Это распространение выполняется позже с помощью механизма, который похож на рассматриваемый ниже в разделе Асинхронная симметричная репликация . Если главная таблица никогда не обновляется и отдельные таблицы-снимки не пересекаются, то это совершенно безопасный подход. Он обеспечивает удобную схему для управления данными в случае, когда ответственность за разные подмножества может быть возложена на разные серверы, а запросы требуется выполнять ко всей популяции данных.

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