ggvExactly as I suspected - oracle stream messaging CAN NOT be used without oracle database.
Again main oracle mistake - all in one.
That's why I don't use it. I can not make a STREAM module for example, which will be pushed in IP stack, do es some action and sends messages. FOr such small task I need a whole oracle,
That's bullshit IMHO, and restricts the area where the solution from oracle could be used.Хм. AQ так позиционируется. Зато если у меня везде стоят базы Oracle и между ними надо организовывать обмен данными, то зачем мене покупать целую Веб Сферу (MQ ведь в её составе?), да ещё и от IBM для полного зоопарка. Ведь согласитесь, вариант, когда везде в организации стоят базы Oracle и между ними нужен обмен информацией, не такой уж редко случающийся.
ggv"Скорость передачи почти прямо пропорциональна скорости работы с данными в БД. " -- sorry, one oracle DBA said here the performance is terrible,"Ты просто не умеешь их готовить" (c) Макаревич, реклама.
Надо провести настройку производительности базы.
Видел Oracle-ы которые при I/O в 10 Мб/мин тормозили, видел, у которых гигабайтный архивный журнал раз в две минуты вылетал.
Вообще-то мысль хорошая. Спасибо за идею. Надо будет попробовать собрать стенд и померять.
ggvIn IBM the performance of Queue Manager does not depend from performance of database.Это игра словами. Ну конечно же, ведь базы-то и нет. Противник посрамлён и краснеет от стыда. ;-)
Давайте посмотрим в корень, как призывал Маковецкий. Производительность от чего-то зависит? От чего?
Для MQ:
Предположим, что канал неограничен, тогда производительность ограничена следующими факторами:
1) Производительность процессора
2) Конкуренция за внутренние ресурсы в RAM-памяти (кэши и прочее).
3) Физический ввод/вывод на диск
Из перечисленных факторов, как мне кажется, наиболее весомым является 3).
Т.е. можно с большой долей уверенности сказать, что
Производительность MQ ~ скорость I/O.

Для AQ:
Предположим, что канал неограничен, тогда производительность базы ограничена следующими факторами:
1) Производительность процессора
2) Конкуренция за внутренние ресурсы в RAM-памяти (защёлки).
3) Физический ввод/вывод на диск
Поскольку для AQ характерна активная вставка-удаление записей из таблиц, то опять же наибольшее влияние оказывает 3).
Т.е. можно с большой долей уверенности сказать, что
Производительность AQ ~ производительность базы ~ скорость I/O.

Т.е. делаем вывод, что
(Производительность MQ)/(Производительность AQ) = CONST.

Таким образом, можно утверждать, что в плане "поведения" MQ и AQ ничем принципиальным не отличаются. Если AQ будет деградировать при росте нагрузки, то и MQ будет показывать точно такое же поведение. Вопрос только в константе.

Nikolay KulikovВ организации нет других систем кроме как на Oracle??? Верится с трудом.Ох, поймали меня на лжи. ;-) Конечно, как я мог забыть про Windows.
Если серьёзно: я говорил про типичность задачи интеграции баз Oracle с базами Oracle для обоснования права на существования системы AQ.

Nikolay KulikovПо поводу сравнения производительности. Слишком много допущений. Ваше доказательство очень похоже на очередной софизм. "Полуполное то же самое, что и полупустое следовательно, полное то же самое что и пустое" :)Вы, Николай, сразу видно, не получали физическое образование (без обид). Для проведения сравнительного анализа двух каких-то физических систем достаточно учесть самые значимые факторы. I/O это основное узкое место как для MQ, так и для AQ.
Если рассмотреть прочие фактором, то следующим будет конкуренция за внутренние ресурсы. Но его влияние в разы меньше, чем I/O.

ggvNobody told here anything about AQ before 'guest'. Seems we may stop the discussion which become useless. At leats for me.Вы непоследовательны. Обратите внимание, что " but if to compare MQSeries with Oracle messaging, then MQSeries really looks like "супер-пупер. " было сказано Вами раньше моего упоминания об Oracle.
ggv"права на существования системы AQ." -- nobody here said AQ must not exist.
The first question was "What for to use MQSeries"
The second question was "What is the difference between MQSeries and SoniMQ".Это замечательно, но как на эти вопросы отвечает фраза Николая: "Куча успешных внедрений в том числе и в России, например Ценробанк" ? Мне кажется, что это не совсем объективно.
ggvWhere companies know there are other databases except of oracle. And of course it is enough forever for RU.
Bad luck.Кому как...