Nikolay KulikovКуча успешных внедрений в том числе и в России, например Ценробанк.Ха-ха. Если учесть тот факт, что начальство ЦБ было куплено IBM-ом, и разработку ЦБ поставили перед фактом: "Работайте с MQSeries и не вякайте. Не ваше дело. Мы вам еще и мейнфрейм прикупили", то Ваша фраза не доказывает, что MQ это супер-пупер.

It is a normal practice when a top management take a decesion what to use and how to use in a big company, and not always each employee will be askedExcellent!!!
Сначала покупаем софт по решению высокого начальства (которое очень далеко от реальности), а потом заставляем собственную разработку использовать его. Это скорее ненормальная практика.
About two years ago they got a lot of HP hardware with HPUX (and oracle for HPUX).Слышали-слышали. Купили до фига 32-х битного железа, а оказалось, что Oracle для 32 бит только в виде 8i есть. Теперь покупают новое. И думают, что делать со старым. Так что "It is a normal practice when a top management take a decesion what to use and how to use in a big company, and not always each employee will be asked" .
It does not look like IBM has bought all management of Central BankЯ про весь менеджмент не говорил. Sybase Вы забыли, кстати, упомянуть.

Я вообще-то просто хотел сказать, что фразы об успешном использовании MQ в ЦБ это больше реклама, чем действительность. У ребят в разработке просто не было выбора, с чем работать. Совершенно аналогично на них вдруг свалилась Java. "С n-го числа всё пишем на Java". А то, что Java не для всего подходит, то кого из высокого начальства это интересует? Не написали - сами дураки.
А соответственно, и нельзя утверждать, что раз что-то используется в большой организации, то это показатель того, что это is the best.

but if to compare MQSeries with Oracle messaging, then MQSeries really looks like "супер-пупер."Всё для своих целей. Например, если мне мне надо связать две оракловые базы, то я использую AQ.
+ Если я считаю свои деньги, то получаю AQ вместе с базой как бесплатную опцию (MQ же за дополнительные $)
+ Бэкап AQ и бэкап базы суть есть одно и то же.
+ Не думаю об XA при передаче данных от базы к базе.
Так что, повторяюсь, всё для своих целей.

but if to compare MQSeries with Oracle messaging, then MQSeries really looks like "супер-пупер."Чего-то обидно за Oracle стало. ;-)

Отвечу Вам Вашими же словами:
But your "but if to compare MQSeries with Oracle messaging, then MQSeries really looks like "супер-пупер"" means you know, probably, nothing, about what you said. Even if it is a fact I doubt you could know about it.

Преимущества есть. Надо только их уметь видеть.
Нашёл замечательную бумагу от Oracle: Technical Comparison of Oracle Database vs. IBM DB2: Focus on Information Integration начиная от 17-й страницы излагается искомое.

What I remember exactly - he said about bad performance of the orcale messagong systemСкорость передачи почти прямо пропорциональна скорости работы с данными в БД.
I may add one thing - _if_ the orcale messaging system is impossible to use without oracle - it is useless for me.Что поделаешь... Так я и говорю, что для разных задач - разные инструменты

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.Кому как...