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

Мы все же должны предостеречь вас от использования времени в качестве базы для разрешения конфликтов. Почему? Потому что во всех средах, кроме распределенной вычислительной среды (DCE), вероятность того, что тактовые генераторы серверов будут синхронизированы, крайне мала. Таким образом, применение стратегии разрешения конфликтов на базе последних значений практически эквивалентно случайному выбору (который в число вариантов, предлагаемых Oracle, не входит). В частности, если ваша сеть охватывает несколько часовых поясов, то может случиться, что все изменения, внесенные в Бостоне, в Сан-Франциско будут удалены.

Приоритет узлов также таит в себе опасность, если в сети больше двух узлов. Рассмотрим пример на рис. 12.6. При определенном стечении обстоятельств синхронность узлов нарушается, и узел С не согласуется с узлами А и В. Поскольку А определен как приоритетный узел, это предполагает, что данные узла С неверны.

Обновление

Рис 12 6. Потенциалы{ая проблема при разрешении конфликта по приоритету узлов

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

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

посредничество в правах обновления может осуществляться через столбец ORDER STATUS, как показано в табл. 12.1.

Таблица J2.1. Использование столбца статуса для определения прав обновления

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

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

Мы предпочитаем второй метод, даже несмотря на то, что при этом только что внесенное изменение не будет сразу же отображаться в копии на том сервере, с которого оно было внесено. Если для вас это серьезная проблема, ее можно решить;

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

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

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

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

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

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

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

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

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

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