1572 Приложение А

Сервер каналов, с другой стороны, подобен многопотоковому серверу (MTS) в Oracle. Вы создаете пул разделяемых ресурсов (запускаете N серверов каналов), и они обслуживают обращения. Если одновременно поступает больше обращений, чем можно обработать, они выстраиваются в очередь. Это очень похоже на многопотоковый режим работы сервера Oracle, когда обращения поступают в очередь в области SGA и выбираются из очереди разделяемым сервером после обработки им предыдущего обращения. Это хорошо демонстрирует ранее рассмотренный пример сервера температуры. На первой схеме показан один сервер канала; он определяет и выдает температуру клиентам по одному. На второй схеме представлены два сервера канала, обслуживающие все поступающие обращения. Одновременно к термометру будут обращаться не более двух клиентов.

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

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

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

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

Пакеты DBMS ALERT и DBMS PIPE

1573

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

Пример в сети Internet

На Web-сайте издательства Wrox (http: www.wrox.com) можно найти пример небольшого сервера каналов. Он отвечает на часто задаваемый вопрос: как выполнить команду базовой операционной системы из PL/SQL? После добавления поддержки Java и внешних процедур на языке С, такую функцию выполнения команд можно легко реализовать с помощью любой из этих технологий. А если компилятора языка С просто нет или поддержка Java в базе данных не установлена - что тогда? Этот пример показывает, как создать небольшой сервер каналов , способный выполнять команды операционной системы, используя только утилиту SQL*Plus и командный интерпретатор csh. Сервер получился сравнительно простым, содержащим лишь несколько строк кода командного интерпретатора csh и еще меньше текста на языке PL/SQL. Однако он показывает основные возможности каналов базы данных и должен натолкнуть вас на идеи по созданию других полезных приложений.

Резюме

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

передачи сообщений электронной почты;

распечатывания файлов;

интеграции с другими источниками данных, находящимися вне баз данных Oracle и не поддерживающими язык SQL;

реализации аналога процедуры DBMS LOB.LOADFROMFILE для типов данных LONG и LONG RAW.

Пакет

DBMS APPLICATION INFO

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

Что делает сеанс, какая форма обрабатывается, какой код выполняется в модуле?

Насколько близко к завершению выполнение хранимой процедуры?

Насколько близко к завершению выполнение пакетного задания?

Какие значения связываемых переменных использованы в запросе?

Пакет DBMS APPLICATION INFO можно использовать для получения ответов на эти и многие другие вопросы. Он позволяет устанавливать значения трех столбцов - CLIENT INFO, ACTION и MODULE - соответствующей сеансу строки в представлении V$SESSION. Пакет предоставляет функции не только для установки этих значений, но и для их получения. Кроме того, один из параметров встроенных функций USERENV и SYS CONTEXT позволяет получить значения столбца CLIENTINFO в запросе. Можно, например, выполнить SELECT USERENV(CLIENT INFO) FROM DUAL или использовать конструкцию WHERE SOMECOLUMN -

SYS CONTEXT(USERENV,CLIENT INFO) в запросах. Значения, устанавливаемые

в представлениях V$, сразу же доступны в других сеансах. Фиксировать их не нужно, что позволяет эффективно использовать эти представления для взаимодействия с внешним миром . Наконец, пакет DBMS APPLICATION INFO позволяет задать значения в представлении динамической производительности V$SESSION LONGOPS (LONG OPerationS). Это удобно для записи сделанного в продолжительных заданиях.