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

Анатомия SQL-предложения

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

Рассмотрим следующее предложение SELECT:

SELECT ord.id

, ord.value INTO ;ord ld

, :ord val FROM orders ord WHERE ord,cust id = ; ord. cust id AND ord.value > :threshold;

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

Примечание

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

SELECT ord.id,ord.value FROM orders ord WHERE ord.cust id = :1 AND ord.value > ;2

SQL*Plus, SQL*DBA и Server Manager никаких преобразований не производят.

Ниже следует краткое описание каждого из пяти этапов обработки SQL-предложения.

Разбор (Parse)

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

Определение (Define)

Клиент запращивает свойства всех переменных в списке SELECT (в примере - ORDERS.ID и ORDERS .VALUE). Чтобы ответить на запрос, сервер использует дерево разбора, построенное на предыдущем этапе.

Привязка (Bind)

Клиент определяет фактические значения всех связанных переменных в предложении (в данном примере - :ord id) и передает эти значения на сервер.

Выполнение (Execute)

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

Выборка (Fetch)

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

Теперь давайте несколько уточним эту модель выполнения SOL-предло-жения и выясним, как она влияет на проектирование для архитектуры клиент/сервер.

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

2. DML-операторы (INSERT, UPDATE и DELETE) не требуют выборки. Оператор завершается после выполнения.

3. В Oracle есть механизм, известный как Deferred Call Interface (интерфейс отложенных вызовов), который иногда называют UPIALL. Он позволяет объединить этапы разбора, определения и привязки с выполнением, хранить результаты на клиенте и выдавать их только при получении запроса на выполнение. Это может значительно снизить сетевой трафик, а также повысить общую пропускную способность и уменьшить время реакции в системе клиент/сервер благодаря меньшему числу пакетов данных (правда, те, которые используются, большего размера). Этот протокол применяется в более новых инструментальных средствах Oracle, например Oracle Forms версий 4.0 и 4.5. Если для разработки используется Рго*С, следует инсталлировать версию 1.6, 2.0 или выше, иначе эту технологию применять будет невозможно.

4. Блоки PL/SQL похожи на DML-операторы тем, что не требуют выборки. Такой блок просто выполняется. Все ссылки на внешние переменные в блоке PL/SQL трактуются как связанные переменные (даже если они выбираются в пределах блока). Использование блока PL/SQL для группировки SQL-предложений - хороший способ сокращения сетевого трафика. В качестве примера возьмем клиентское приложение, которое изменяет сальдо двух бухгалтерских таблиц на 10%:

UPDATE checking accounts сас

SET сас.balance = сас.balance * 1.1 WHERE cac.cus id = :cus id;

UPDATE savings accounts sac

SET sac.balance = sac.balance * 1.1 WHERE sac.cus id = :cus id;

Даже при полном объединении вызовов это потребует двух пар сообщений - по одной для каждого SQL-предложения. Если эти два предложения заключить в операторы BEGIN ... END, образующие блок PL/SQL, то в лучшем случае нужна будет всего одна пара сообщений. (Еще лучше инкапсулировать это действие и перенести эти два предложения на сервер как хранимую процедуру. Чтобы выполнить действие, программа запустит анонимный блок, содержащий вызов хранимой процедуры.)