Re: "Входная очередь" средствами Ораскла

From

Тимур Малыгин (2:5020/400)

To

Grigoriy Shpakov (2:5054/37.63)

Date

2005-04-11T15:20:58Z

Area

RU.RDBMS.ORACLE

From: "Тимур Малыгин" <t.malygin@soft.velton.net.ua>

Всем привет.

Посмотри в сторону Advanced Queuing.
Описание найдешь в Application Developer's Guide - Advanced Queuing.

Это самое оно.


"Grigoriy Shpakov" <grigory@sirena2000.ru> сообщил/сообщила в новостях
следующее: news:d3dk5n$39n$1@host.talk.ru...
>    Привет всем!
>    Подкиньте, пожалуйста, идей для решения следующей проблемы.
>    В некоторой Системе периодически возникают События. При возникновении
> Событию присваивается номер (уникальный в масштабах Системы). Номера могут
> присваиваться не подряд, но всегда присваиваются по возрастанию. В
> дальнейшем эти События надо обрабатывать. Не обязательно немедленно, но
> обязательно в порядке их поступления (а этот порядок можно восстановить по
> порядку присвоенных номеров).
>    В настоящий момент эта конструкция реализована с помощью таблицы,
которая
> по сути дела является входной очередью к системе. При возникновении
События
> в таблицу заносится запись с номером События и сопутствующей информацией.
А
> в цикле обработке Событий делается нечто вроде
>
>    SELECT MIN(номер_события) FROM входная_очередь
>     WHERE номер_события > номер_последнего_обработанного_события.
>
>    Все бы ничего, если бы не одно "но". Не так давно у нас тут сработал
> "генератор Событий", в результате чего количество записей во входной
очереди
> резко взлетело до примерно 20000 (обычно там десятка 2-3 записей). И в
> результате этот запрос стал очень конкретно тормозить. Вплоть до того, что
> этот самый SELECT стал составлять примерно половину общего времени
обработки
> События (засекли по ораклиной трассировке).
>    ВОПРОС: что можно сделать для улучшения ситуации?
>    Разумеется, индекс над таблицей-очередью по номеру события есть.
>    И еще: отказаться от использования СУБД в этой конструкции нельзя: по
> условиям работы Событие должно быть обработано вне зависимости от прочих
> обстоятельств. Даже если Система будет остановлена на какое-то время, а
> потом запущена, обработка очереди Событий должна начаться с того же места,
> на котором процесс прервался. Кроме того, сами События и результаты их
> обработки архивируются в другие таблицы базы.
> --
> Григорий Шпаков
> Бывший 2:5020/198.39 AKA /213.25 AKA /54.35 AKA grigory@sirena.rinet.ru
> Ныне grigory@sirena2000.ru
>
> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru


--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 50/203 520 450/159 186 451/30 452/25 454/9 461/33 43 74 106 640
SEEN-BY: 464/34 465/204 469/125 999 550/5068 4623/56 4625/8 9 4626/100 4627/10
SEEN-BY: 4641/444 4646/1 4653/10 4657/50 5000/76 5001/5001 5002/76 5002
SEEN-BY: 5003/34 57 5004/58 5006/1 5007/1 5010/53 70 5011/13 5015/4 28 5020/20
SEEN-BY: 5020/52 104 115 118 128 150 175 194 400 401 545 600 639 642 715 758
SEEN-BY: 5020/794 894 921 968 982 1057 1100 1169 1212 1234 1356 1604 1626 1642
SEEN-BY: 5020/1835 1873 1909 1930 2013 2020 2200 2238 4400 4441 5021/3 44
SEEN-BY: 5022/128 5023/11 5025/19 151 750 5026/14 45 78 5030/69 195 382 920
SEEN-BY: 5030/966 1016 1063 1339 1900 5032/11 16 5033/21 35 5034/8 5035/10
SEEN-BY: 5036/1 13 5037/21 5040/33 47 5041/4 10 5042/13 5045/7 42 5049/157
SEEN-BY: 5050/9 41 5051/15 35 5053/16 5054/1 8 9 28 35 37 45 50 5056/16 5057/1
SEEN-BY: 5058/77 5059/20 5060/88 90 5061/15 5062/1 5063/5 41 51 5064/7 35 36
SEEN-BY: 5066/18 5070/26 66 1222 5071/22 5079/23 49 5080/80 1003 5081/2 5082/6
SEEN-BY: 5083/13 21 5090/23 5093/27 57 5100/113 6000/12 6001/3

PATH: 5020/400 4441 52 5054/1 37