в PL/SQL диагностику можно включить с помощью переменной пакета:

IF l degug.debug mode THEN -- диагностика

DBMS OUTPUT.PUT LXNE( About to insert 100 new orders ); END IF;

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

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

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

В следующих разделах приводится довольно краткое описание приемов пакетной обработки. Такая краткость в основном обусловлена нашим убеждением, что многие вопросы, связанные с успешным управлением пакетной обработкой, не имеют ничего общего с используемым ПО управления данными. Мы отвергаем идею о том, что такие проблемы, как управление заданиями, лучше всего решаются из СУБД, несмотря на все возможные преимущества переносимости. К сожалению, платформы открытых систем не поставляются с системами управления заданиями по типу мэйнфреймов-ских, и поддержка в этой области на промышленном уровне будет критическим фактором успеха для многих приложений. Но эта тема выходит за рамки книги по проектированию баз данных Oracle.

Вывод диагностических данных из PL/SQL

Пакет DBMS OUTPUT поставляется вместе с процедурной опцией Oracle?. Он имитирует функции ввода-вывода файлов, позволяя пользователю записывать и читать рабочий файл . Однако в том виде, в котором он реализован в текущих версиях Oracle?, для буферизации данных он использует не файловую систему, а SGA и позволяет выбирать эти данные только этому же соединению с базой данных.

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

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

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

Чего вы никогда не должны делать с диагностическими данными, так это вставлять их прямо в регистрационную таблицу в базе данных. Почему? Да потому, что если будет выполнен откат какой-либо транзакции, то все незафиксированные диагностические данные будут потеряны. Недопустимо также, чтобы профамма выполняла фиксацию после вставки каждого диагностического сообщения, поскольку это изменит границы транзакций. При посылке диагностического текста по каналу (pipe) принимающий процесс может спокойно вставлять и сразу же фиксировать каждое сообщение. Эти вопросы более подробно рассматриваются ниже, в разделе Обработка ощибок .

Выбор инструментального средства

Несмотря на большое число усовершенствований, сделанных в версиях ?.2 и ?.3, мы не рекомендуем использовать PL/SQL как средство реализации высокопроизводительной пакетной обработки. Как вы видите из

приведенных в книге примеров, мы - сторонники использования PL/SQL в качестве языка для хранимых процедур и триггеров, но у него есть ряд ограничений, делающих этот язык слишком дорогим для использования при обработки больших объемов данных. Эти недостатки таковы:

поддержка ввода-вывода файлов в версиях до 7.3 отсутствует;

модель безопасности для ввода-вывода файлов в версии 7.3 крайне несовершенна;

несмотря на улучшения в версии 7.3, управление памятью для таблиц PL/SQL не соответствует обработке больших массивов и кэшей данных, а именно такие приемы обычно использтотся для создания высокопроизводительной пакетной обработки;

PL/SQL - интерпретируемый язык, хотя перед интерпретацией программа и компилируется в некую промежуточную форму;

отладка сложного PL/SQL, работающего на сервере, - просто кошмар.

Рекомендуем писать выполняющиеся на сервере программы пакетной обработки на 3GL и осуществлять обмен данными с СУБД при помощи массивного интерфейса Oracle. Кроме того, рекомендуем ограничить операции с базой данных только теми, которые либо должны выполняться внутри нее, либо не должны экспортироваться. Так, если требуется прибавить единицу к какому-то значению в базе данных, но нет необходимости видеть это значение в управляющем коде, следует использовать простое относительное обновление, например:

UPDATE emp

SET sal = round{sal * (1 + :increase pct/100);

Однако вполне вероятно, что нам придется сообщать не только о том, сколько увеличений бьшо разрешено (это обновление возвратит количество обработанных строк), но и о том, каков общий объем увеличения. Поэтому нам почти наверняка следовало бы экспортировать эти значения. В этом примере также показана одна из весьма распространенных серьезных ошибок: для выполнения арифметических операций здесь используется интерпретатор SQL, хотя гораздо лучше это делать в 3GL (в данном случае мы имеем в виду деление на 100 и гфибавление 1). Помните, что Oracle выполняет всю SQL-арифметику с плавающей запятой с точностью до 38 разрядов. На очень многих машинах это нельзя сделать в одной машинной команде.

Для не критичных по времени заданий PL/SQL все же дает определенные преимущества, а именно:

это строго структурированный язык, который легко чгггать, причем он тесно интегрирован с SQL;

этот язык выбрала для себя корпорация Oracle, она вложила в него много денег и очень долго будет им пользоваться;

этот язык позволяет удобно упаковывать и инкапсулировать скомпилированный код на сервере.