довести до 100% либо степень использования ЦП, либо (что бывает чаще) эффективность операций обмена с диском.

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

Дополнительная информация о параллельной обработке предлагается в главе 14.

Версия 7.1. 6

Б версии 7.1.6 появился ряд новых возможностей, влияющих на проектирование.

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

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

Чтобы задавать действия по репликации в распределенной среде, в Oracle реализован набор упакованных процедур, который называется Rep Cat (replication catalogue - каталог репликации). Эти процедуры обеспечивают сопровождение всех объектов словаря данных, необходимых для поддержки репликации.

Механизм распространения изменений данных построен на асинхронных RPC (удаленных вызовах процедур). Они, в свою очередь, используют двухфазную фиксацию для обеспечения целостности при передаче действий из одного экземпляра базы данных в другой. Асинхронные RFC также доступны пользовательским приложениям на PL/SQL, выполняющимся на сервере базы данных.

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

Разделяемый пул

Ранние версии Oracle? страдали рядом недостатков, связанных с управлением разделяемым пулом. Полный анализ этих проблем выходит за рамки книги по проектированию, поэтому мы лишь отметим основные трудности - способ кэширования триггеров и тенденция пула к сильной фрагментации.

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

Версия 7.2

В этом разделе описываются особенности версии 7.2, на которые нужно обратить особое внимание при проектировании.

Ручное секционирование

В версии 7.2 реализована ограниченная поддержка секционирования данных в форме ручного секционирования. Попросту говоря, при определенных ограничивающих условиях оптимизатор запросов версии 7.2 может заносить условия соединения в представление с UNION ALL.

Предположим, что у нас есть две таблицы, ORDERS и OLDORDERS, с идентичными столбцами и индексами и мы объявляем представление ALL ORDERS следующим образом:

SELECT *

FROM orders UNION ALL SELECT *

FROM old orders;

Запрос

SELECT c.cust name , o.order date , о.order value FROM customers с , all orders о WHERE c.zip = 12345 AND c.cust# = o.cust#;

теперь будет выполнен так:

SELECT c.cust name , o.order date , o.order value FROM customers с , orders о

WHERE c.zip = 12345 AND c.cust# = o.cust#; UNION ALL

SELECT c.cust name , o.order date , o.order value FROM customers с , old orders о WHERE c.zip = 12345 AND c.cust# = o.cust#;

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

запросах к большим таблицам последствия для производительности были просто катастрофические.

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

Цлаиировщлк задании PL/SQL

Версия 7.2 также включает планировщик заданий PL/SQL, позволяющий пользователю или разработчику настраивать PL/SQL-задачи на выполнение б указанный день и время и на повторение их с заданным интервалом. Это призвано в некоторой степени смягчить проблему отсутствия в Oracle? собственной подсистемы пакетного планирования.

Нсблокируюиие вызовы

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

Много лет назад, после того как Oracle выпустила прекомпиляторы версии 1, позволяющие использовать SQL-вызобы непосредственно в про-фаммах на языках третьего поколения (например, на С и Коболе), корпорация объявила о своем намерении прекратить поддержку OCI. По ряду технических причин этот шаг встретил сильное сопротивление со стороны поставщиков, продающих программные средства для работы с Oracle. Наиболее важно то, что OCI позволяет свободно передавать курсор при помощи ссылки из одной подпрограммы в другую, делая возможным написание универсального кода, обрабатывающего любое количество курсоров. Поскольку Oracle произвела ряд внутренних изменений, чтобы привести OCI в соответствие с современными требованиями в версии 7.0, наличие неблокирующих вызовов в версии 7.2 означает, что появилась еще одна важная группа функциональных возможностей, которые можно получить только через этот интерфейс вызова.

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

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