Если вы пользуетесь обновляемыми снимками, то должны знать о следующих двух наиболее важных ловушках :

Когда создается обновляемый снимок, ограничения из главной таблицы не наследуются (включая ограничения FOREIN KEY). Их нельзя создать вручную на самом снимке, поскольку он является представлением таблицы, которая называется 8НАР$<имя 1паблицы>. Получается, что можно воссоздавать ограничения на самой таблице SNAPS. Однако это неавтоматизированный процесс, и поэтому он подвержен ошибкам. Последствия ошибки весьма неприятны. Если пропущено ограничение на таблице SNAPS, то можно создать и зафиксировать строку, которая его нарушает. При обновлении главной таблицы операция вставки даст сбой, и в какой-то момент эта строка безо всякого предупреждения исчезнет из

, снимка, в котором она была создана. Единственный признак существования проблемы будет присутствовать в таблице регистрации {US-Ь0С$ <имя 1паблицы>) на узле, содержащем главную таблицу.

Необходимо соблюдать осторожность при создании триггеров на обновляемых снимках. Предположим, что у нас есть триггер на таблице ORDERLINES, который обновляет суммарную стоимость заказа в таблице ORDERS (денормализованный столбец). Например, в триггере BEFORE INSERT мы прибавляем к общей стоимости заказа стоимость нового элемента заказа. Мы хотим, чтобы это происходило на всех узлах, и поэтому помещаем триггер не только на главную таблицу, но и на SNAP$-тaблицы всех остальных узлов. Коды триггеров одинаковы, и на узлах-снимках они фактически обновляют представление таблицы ORDER. Мы включаем снимки на базе таблиц ORDERS и ORDER LINES в группу, чтобы они обновлялись одновременно. Есть, правда, одна проблема: группа снимков гарантирует, что эти две таблицы будут обновляться в один момент времени, однако изменения будут применяться в произвольном порядке. Если заказ обновляется до строки заказа, то при вставке строки заказа сработает триггер на главной таблице и аддитивный трщгер добавит стоимость этой позиции заказа вторично (и сделает стоимость неверной).

Чтобы избежать повторного применения триггера, можно воспользоваться функцией DBMS SNAPSHOT.AM I A REFRESH, но здесь есть более глубокая проблема. Происходит распространение большого объема данных, поэтому стоит рассмотреть такой вариант: не создавать триггер на SNAP$-тaблицe и выполнять фильтрацию изменений на главном узле. Этот вариант предпочтителен, если можно продолжить работу с неверной суммой заказа до тех пор, пока снимок не будет полностью синхронизирован с главной таблицей. Поскольку это вряд ли возможно, то в данном случае, вероятно, стоит вообще воздержаться от денормализации.

При проектировании распределенных баз данных вы встретите много таких головоломок, поэтому будьте внимательны и попытайтесь их избежать!

Неограниченное число триггеров на одной таблице

Запись изменений в главные таблицы выполняется с помощью триггеров на соответствующих таблицах. В версии 7.0 это вызывало серьезную проблему. Если инсталляционный скрипт какого-то фрагмента ПО хотел поместить триггер на таблицу (например, триггер BEFORE INSERT уровня строки), а такой триггер уже существовал, то возникший в результате конфликт можно было разрешить только путем слияния этих двух триггеров. К принятию этого решения склонялись очень немногие авторы инсталляционных скриптов (а то и вообще таких не было), поэтому возможность иметь на таблице несколько триггеров с одинаковыми временными параметрами оказалась очень кстати.

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

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

Асинхронные удаленные вызовы процедур

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

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

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

отчет, отражающий все операции с деталями, которые либо закончились неудачей, либо не сопровождались подтверждением. Эта задача может быть частью основного приложения или же, что более удобно, выполняться каким-нибудь средством управления приложениями, например PATROL фирмы ВМС. В любом случае она представляет собой чистое проектирование. Нужно довести эту информацию до сведения аналитиков и согласовать вопрос о том, как решать эту ситуацию на бизнес-уровне. Исходя из нашего опыта работы с бизнес-аналитиками, их мнение можно предугадать: операции необходимо производить в оперативном режиме, чтобы эта проблема не возникала!

Получив такой ответ, следует вернуться к шести -остям и найти компромиссное решение, которое лучше удовлетворяет самым важным требованиям.

Асинхронная симметричная репликация

Средства асинхронной симметричной репликации позволяют нескольким копиям одной таблицы одновременно существовать в разных базах данных и, следовательно, на разных серверах. Ни одна из копий не является главной: все они равны, или симметричны. Можно вносить изменения в отдельные реплицированные таблицы, и эти изменения распространяются асинхронно в остальные копии этой же таблицы. Время, необходимое для распространения изменения, зависит от различных параметров, установленных администратором БД, а также от готовности баз данных, в которые распространяются изменения. В результате могут, естественно, возникать конфликты обновления. Для их устранения в Oracle имеются как средства обнаружения конфликтов, так и средства их разрешения, в том числе возможность реализовать набор специализированных правил в PL/SQL.

Обнаружение конфликтов при обновлениях в Oracle осуществляется просто, поскольку распространяются и старые, и новые значения. Если на каком-либо узле строка в текущий момент не содержит распространенное старое значение, это говорит о наличии конфликта обновления. Легко и просто. Со многими приложениями установленные правила разрешения конфликтов работают хорошо, особенно аддитивное правило типа: Изменить значение на ту же самую величину .

Предположим, на складе есть 50 единиц детали 37В и мы выдаем 20 из них. При этом мы распространяем изменение, которое гласит, что для детали 37В количество сначала было равно 50, а теперь 30. Если где-то на другой машине обнаруживается, что эта деталь имеется в количестве 40 единиц, мы просто уменьшаем эту величину до 20, производя такое же относительное изменение, которое мы выполнили сначала. В конечном итоге изменение, в результате которого число деталей на удаленной машине сократилось с 50 До 40, будет распространено обратно на исходную машину, где тем же способом наша цифра будет уменьшена с 30 до 20. Все счастливы, если только У нас нет правила, согласно которому число деталей не может быть меньше 30!