Выбор стратегии распределения данных

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

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

сократить нагрузку на сеть или сервер или

повысить уровень готовности,

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

примечание

В этой главе мы мало говорим о щдюзах, предлагаемых Oracle, и об архитектуре сетевых вычислений. Шлюзы различаются как по степени поддержки функциональных возможностей сервера Oracle, так и по степени эффективности выполнения своих задач. Мы рекомендуем перед принятием рещения об использовании какого-либо распределенного механизма провести всестороннее тестирование в реальных условиях. Это особенно касается ситуации, когда применяются разнородные серверные технологии. Архитектура сетевых вычислений (Network Computing Architecture, NCA) позволяет делать инкапсулированные запросы к картриджам данных . Это средство может облегчить реализацию распределенных рещений, но в настоящее время оно вряд ли способно рещить вопросы повыщения эффективности и готовности,

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

CREATE VIEW all customers (cust loc, cust id, cust name, ...) AS SELECT LOCAL , cust id, cust name, . , ,

FROM customers - из локальной базы данных в Нью Йорке

UNION ALL

SELECT LONDON , cust id, cust name,... FROM customersSlondon UNION ALL

SELECT TOKYO , cust id, cust name,...

FROM customersgtokyo UNION ALL

SELECT SYDNEY , cust id, cust name,...

FROM customersgsydney UNION ALL

SELECT LOS ANGELES , cust id, cust name,... FROM customers@la;

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

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

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

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

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

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

Подробнее о двухфазной фиксации

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

Потребность в двухфазной фиксации

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

UPDATE emp@chicago SET sal=sal*1.05 WHERE deptno = 26;

Если в отделе 26, зарегистрированном в чикагской версии таблицы, служащих нет, то, когда координатор спросит у чикагского экземпляра, вносил ли он изменения, экземпляр ответит отрицательно, В результате этого, если транзакция вносит изменения только в один (даже удаленный) экземпляр базы данных, двухфазная фиксация не требуется, Уловка-22 состоит в том, что в Oracle необходимо иметь компонент Distributed Option (включающий двухфазную фиксацию), чтобы определить, что двухфазная фиксация не требуется. Другими словами, если двухфазная фиксация не инсталлирована, то нельзя обновить данные через канал связи БД даже в тех случаях, когда двухфазная фиксация не требуется,

Сомишиельные данные

Вторая проблема состоит в том, что в промежутке времени между подготовкой и фиксацией даннью считаются сомнительными. Когда база данных, в которой выполнено обновление, получает команду подготовки, то до тех пор, пока координатор не просигнализирует о второй фазе фиксацией или откатом, никак нельзя определить, зафиксированы данные или нет. По этой причине Oracle с помощью блокировки на уровне блока предотвращает доступ к этим данным, поскольку не может определить, следует ли применять согласованность по чтению. Обычно в среде локальной сети эти блокировки существуют всего несколько миллисекунд, а в глобальной сети - несколько сот миллисекунд. Тем не менее, если какая-то проблема (например, сбой в сети) не дает завершить вторую фазу, то сомнительные данные остаются недоступными до тех пор, пока проблема не будет решена. Решить ее можно либо с помощью встроенного в Oracle механизма восстановления, либо путем вмешательства администратора БД, который должен выдать SQL-предложение COMMIT FORCE или ROLLBACK FORCE,