Расширенный опыт работы с очередями Oracle

Я рассматриваю возможность использования технологии Oracle Advanced Queuing для асинхронной связи. Моя цель - использовать его для параллельного выполнения процессов (асинхронные вызовы процедур PL/SQL).

Текущая устаревшая реализация для параллельного выполнения процесса состоит из сценариев Unix KornShell (ksh), которые мы запускаем из внешнего интерфейса через SSH-соединение в фоновом режиме. Это прекрасно работает для нас, но я недоволен таким решением из-за:

  • Безопасность (интерфейс запускает SSH-соединение и выполняет ksh-скрипты в фоновом режиме. От наших коллег я заметил, что такой вход в нашу компанию будет ограничен.)
  • Обслуживание (не все из нашей команды знакомы с ksh-скриптами)
  • Разнообразие технологий (я стараюсь уменьшить разнообразие технологий благодаря ноу-хау и усилиям по миграции)
  • Ведение журнала (наша серверная система регистрируется в таблицах журнала базы данных, параллельное выполнение частично регистрируется в файле журнала)

Перейдя с ksh на базу данных, я смогу повысить общее качество своей системы:

  • Безопасность (больше никаких SSH-соединений, внешний интерфейс будет отправлять сообщения в базу данных, а прослушиватель сообщений базы данных будет реагировать на сообщения и выполнять процедуры асинхронно)
  • Обслуживание (Мы используем PL/SQL, где мы знакомы)
  • Разнообразие технологий (при следующей миграции ОС нам нужно будет перенести только объекты базы данных и данные)
  • Ведение журнала (мы будем полностью использовать наше серверное решение для ведения журнала)

Что вы думаете о моих соображениях и каковы ваши впечатления от Oracle Advanced Queueing? Особенно в стабильности, производительности и обслуживании? Есть ли лучшие альтернативы?


person eglobetrotter    schedule 23.01.2012    source источник


Ответы (2)


Я, очевидно, не знаю деталей вашего проекта, но если асинхронные вызовы процедур PL/SQL являются вашей единственной целью, может быть проще использовать DBMS_SCHEDULER. Ваша программа может отправлять задания для «запуска сейчас» через планировщик, который вызывает ваш PL/SQL. На мой взгляд, с планировщиком гораздо проще работать, чем с AQ.

person Craig    schedule 23.01.2012
comment
О да, спасибо, это тоже классная альтернатива для одновременного выполнения. Возьму для своих соображений. - person eglobetrotter; 24.01.2012

Управление потоками с помощью асинхронных очередей Oracle имеет свои преимущества и недостатки:

ПРЕИМУЩЕСТВА

  1. Возможность управлять потоками по типу, создавая специальный код, для которого можно создать обработчик (JOB EVENT или APPLY PROCESS) для управления различными подпотоками.
  2. Легко вывести целый тип потоков, закрывающих DEQUEUE Queue.
  3. Управление приоритетами (параметр при создании Coda) MSG для ВСТАВКИ ВРЕМЕНИ или ПРИОРИТЕТА (параметр msg в полезной нагрузке) Управление сообщением с крайним сроком или истекшим ВРЕМЕНЕМ.
  4. Согласуйте парадигму с решением СОБЫТИЯ без ОПРОСОВ

НЕДОСТАТКИ

  1. Вся нагрузка бизнес-логики будет на БД.
  2. При установке нового PKG вам нужно будет остановить очереди (постановку в очередь и УДАЛЕНИЕ ОЧЕРЕДИ), чтобы перезапустить ОБРАБОТЧИК, указывающий на PKG.
  3. Приходится внедрять систему восстановления msg Неправильно обработано.

Я думаю, что хорошим решением было бы использовать CODE JMS (поставщик JMS) на хвостах ORACLE, чтобы перенести BL на JAVA и использовать различные возможности языка, включая Logging.

person Antonino Barila    schedule 05.12.2014