Приветствую!
1. Создал процедуру на удаленном сервере:



2. На основном серваке сделал процедуру для вызова удаленной:

Которая просто вызывает удаленную процедуру.

3. Пытаюсь на основной базе создать триггер на удаление и в нем вызвать удаленную процедуру, через основную:


Идет ругачка :
Error: ERROR [25000] [IBM][DB2/NT64] SQL30090N Operation invalid for application execution environment. Reason code = "22".

Я слишком многого хочу от DB2? В триггере невозможно вызывать удаленные процедуры ?

Mark Barinsteinmedoed В триггере невозможно вызывать удаленные процедуры ?
Добрый день.

Согласно RC=22, если процедура объявлена как MODIFIES SQL DATA, то нельзя.

db2 "? SQL30090"
...
22 A federated insert, update, or delete operation, or a call to
federated procedure with an SQL data access indication of
MODIFIES SQL DATA is invalid in a function, a
data-change-table-reference, a dynamic compound statement, a
trigger...
Это весьма грустно Марк!

Марк, а можно я все же задам накипевший вопрос? А почему создатели ядра такое сделали, в функциях в динамике работать с NickName нельзя. В триггере дергать процедуру или использовать NickName для модификации данных на удаленно сервере тоже?
Для чего??? Я разработчик и мне решать, что можно или нельзя делать на удаленном сервере - а то что сейчас каждый раз мне дают по рукам разработчики ядра - тошнит уже и руки опускаются!
Они (разработчики ядра СУБД DB2) наверное гордятся этим и не собираются исправлять, да?

Mark Barinsteinmedoed,

Эти ... федерасты сидят далеко от разработчиков ядра, они свою работу как сделали, так сделали...
Сидят там у себя на другом континенте, только жизни загубленные себе звёздочками на фюзеляже подрисовывают. Вот ещё одна, похоже, вырисовывается :)
Но вы, как заказчик, можете заставить их работать с помощью т.н. RIMS (aka DCR) - запросов на расширение функциональности. Если вы не будете этого делать, то сама эта нужная, может быть, только вам функциональность делаться неизвестно для кого не будет. Эти разработчики просто не узнают, что это кому-то надо...
Меня как клиента не должно волновать - где сидит команда! Тем более в эру современных технологий скайпа и видеотрансляций!
Я посылал свою хотелку в декабре прошлого года- даже ответа не было!
Компания вроде крупная, есть и прогеры и тетстеры и манагеры - а такой отстой в архитектуре творится!
disable/enable триггер нету ну это писец по-моему!

anton.kФедеративной инфраструктуре в DB2 for LUW много лет. Я не сильно ошибусь если скажу, что добавлена она была лет 15 тому назад. В те времена драйвера, используемые DB2 для связи с удаленными базами данных, не обладали механизмами необходимыми для корректной реализации некоторых фундаментальных принципов СУБД (именно в рамках федеративной инфраструктуры). Например, DB2 не могла гарантировать, что в случае dynamic compound statements (сейчас они называются compound inlined statements) все remote statements, на которые разбивается compound statement, завершаться в рамках одной транзакции. То есть это не было ограничение DB2 или федеративной инфраструктуру, просто инструментарий, на который опиралась DB2, не поддерживал требуемого функционала.

Изменилась ли ситуация сейчас? Не берусь утверждать наверняка, но с осторожностью предположу, что да. Тогда почему не добавили до сих пор поддержку INSERT/UPDATE/DELETE запросов и федеративных функций, определенных как MODIFIES SQL DATA, в триггеры, функции и compound statement'ы? Марк вам совершенно точно уже ответил на этот вопрос - потому что никто об этом не просил (либо просили недостаточно настойчиво :) Так что если оно вам очень сильно надо - начинайте трясти тех. поддержку. Насколько я помню, не так давно изменился процесс подачи и обработки запросов на расширение функциональности, по идее должно было стать проще.
За 15 лет должно уж что то поменяться!!! Я писал им раннее об этой проблеме - ноль эмоций! Ну я доложил об ограничениях СУБД начальству, как следствие (в том числе) мы переходим в 2015 на ту СУБД, в которой таких дебильных проблем нет (MSSQL)!
И более того, если меня когда то спросят, как консультанта про выбор базы - никогда не посоветую DB2!!!
Я в MSSQL тоже натыкался на проблемы, но это было раза 2-ва за 5-ть лет, здесь же за 2-ва года на 5-7 на крупных камня наступил!
Вообщем DB2 буду рекомендовать тока врагам )

mustaccioanton.kНасколько я помню, не так давно изменился процесс подачи и обработки запросов на расширение функциональности, по идее должно было стать проще.

Чтобы не быть голословным -- новая книга жалоб и предложений здесь: https://www.ibm.com/developerworks/rfe/
Уже неинтересно, пусть получат пилюлей от какого нить крупного клиента, желательно перед рождеством! Чтобы то что за 15 лет не довели до ума - аврально исправляли!!!

n&nmedoed...пусть получат пилюлей от какого нить крупного клиента, ...
пмсм, крупным (действительно крупным) клиентам все это глубоко безразлично.
Они берут готовые решения от крупных вендоров, в точ числе и от самой IBM.
Видел только несколько таких решений и судя по ним основной тренд эти 15 лет -
переносить любые распределенные операции на уровень сервисных приложений
(Хоть тот же стек WebSphere).
Может поэтому и нет нет смысла развивать такой функционал в СУБД.
А я видел трейдинговые системы как раз с логикой на СУБД (это было на MSSQl), думаю на DB2 такое бы не взлетело!

anton.kmedoedУже неинтересно, пусть получат пилюлей от какого нить крупного клиента, желательно перед рождеством! Чтобы то что за 15 лет не довели до ума - аврально исправляли!!!
Ну то есть тот факт, что за все это время востребованность данной конкретной функции не достигла критической массы, достаточной для того, чтобы разработчики DB2 добавили ее поддержку (при том, что вам достаточно внятно объяснили, почему это не было сделано изначально, а так же почему это не было сделано в последующее время ), наводит вас на один единственный вывод, что архитектура DB2 - отстой? Я правильно вас понял?
Нет конечно. Ноя не понимаю, почему если на одном инстансе развернуто несолько баз DB2 возникают вообще какие то проблемы при коммуникации между ними. В MSSQL я просто могу в запросе написать так: select * from base1.dbo.table1 as t1, base2.dbo.table1 as t2 where t1.id = t2.id без всяких MQT и NICKNAME (base1 и base2 разные базы), ну не умеет так db2, ну пусть сделает полную функциональность между федеративными серверами! Но нету ее ни шиша!
А насчет востребованности - если в db2 disable/enable для триггеров не возможен а только drop/create, то явно показывает отношении компании на клиентов, я ее с помощью картинки продемонстрирую (пользователи на переднем плане, отношение db2 к клиентам на заднем):

A.Panskikhmedoed,

db2 ориентирована на крупных кастомеров, где срок и стоимость разработки систем несравнимы со сроками и стоимостью поддержки.
Из этого построена вся идеология системы и продуктовой линейки IBM.

Что такое "дернуть хранимую из триггера". Это значит, что часть кода из транзакция уйдет безконтрольно. Что произодет при роллбэке? Что произойдет при зависании внешней хранимой процедуры? Во сколько денег выльется поддержка, сколько будет стоить развернуть тестовый/девелоперский стенд, провести интеграционное тестирование? Извращения программиста потом выливаются в невозможность нормально поддерживать систему, безумные затраты на модификацию и тестирование.

Поэтому ни одному кастомеру IBM этого не надо.

Мой совет - либо выберете более удобное для ваших задач решение, либо примите правила разработки.

Идеология DB2 в двух словах - кесарю кесарево. В БД лежат данные, на сервере приложений - код, интеграционная компонента - шина, транспортный уровень - MQ, процессами рулит process manager, для распределенных транзакций используем TM, и т.д. Все компоненты информационной инфраструктуры представлены IBM и даже в нескольких вариантах. При этом ничто не мешает заменить каждый компонент на продукт от другого вендора и/или на иной платформе.

Если данный подход не устраивает, выбираете любое другое решение, которых на рынке с идеологией
"Лосьен Огуречный! Выпивка и закуска в одном флаконе!" полно (и задать себе вопрос - а почему полно?).
AP
Вы на себя взяли авторитетное мнение за всех кастомеров, ну ну ? Ну я давно понял, что если логика на стороне СУБД (такие системы все же есть, как вариант для быстродействия) то DB2 для таких решений -УГ! Про удобство для клиентов я привел конкретный пример с alter/disable trigger этого нет в DB2, но есть в MSSQL, SYBASE,ORACLE. Вывод прост - Db2 неудобна как минимум. Хотя по вашей логике триггеры вообще не нужны, все контролим на сервере приложений Наша компания уже выбрала решение и то что она отказывается от DB2 - это верное решение (как мне видится), потому как сама СУБД имеет слишком много ограничений да и в администрировании тяжела, в отличие от MSSQL, где многое можно сделать нативно!

A.Panskikh,
Много буков выше и анекдотец заплесневелый!
Я лишь о том что DB2, заявляемая как полноценная СУБД таковой не является по сути, даже потому что нельзя disable/enable триггер не поддерживается и даже потому что НЕПОЛНОЦЕННО организованы федеративные связи, могу ещё кучу багов привести!
Далее можете все что угодно писать и тролить, но против фактов не попрешь!!!
Ау фидерзейн!

Victor MetelitsaВспоминается анекдот про Буратино и винтик. Тот, где Буратино обнаружил винтик у себя в пупке и ради любопытства его раскрутил. Но то про деревянного ребёнка. А эта эпопея... В одной базе запросы работают полноценно, но надо обязательно сделать из неё две. Запрос с реплицированными данными будет работать быстрее (поскольку в одной базе), но надо обязательно использовать никнейм. Так, по дороге, пришли к Java-функции - самому тормознутому решению из возможных. И наконец упёрлись в триггера, которые не позволяют. Зачем всё это затевалось, совершенно непонятно.
Радует, что вам еще что то вспоминается
Несколько баз было сделано из за блокировок и тормозов на одной. Разные клиенты на разных базах и одна справочнная база общая, не самое лучшее решение, но и не самое плохое (этому решению лет 7-мь и придумалось до меня). MQT при обновлении нехило дает блокировки, поэтому постарались внедрить NICKNAME где это возможно (пока что не пожалели). Java функции придумал ваш мозг, в который нежданно пришли фантазии . Триггер рассматривался как вариант синхронизации между справочной базой и основными при удалении справочника, да через NickName и в таком подходе я не вижу ничего криминального!!!
В MSSQL и Sybase на базе BASE1:
это бы работало без проблем!!!
А DB2 встает раком!

db2manVictor MetelitsaВспоминается анекдот про Буратино и винтик. Тот, где Буратино обнаружил винтик у себя в пупке и ради любопытства его раскрутил.
....и теперь у "буратины" этого "бисер" не усваивается (постоянно отрыгивается фекалиями) , так что, парни, завязывайте с "метанием", бо не в свинью коня корм

Victor Metelitsa Зачем всё это затевалось, совершенно непонятно.
Так бывает, когда "разруха в головах". Здесь можно только обнять и плакать "панять и пгастить"
А вы посмотрите % распространенности у нас на рынке СУБД DB2 (по сравнению с Oracle и MSSQL) где нет лоббирования - неудобно, поэтому мало кто выбирает!
Это неспроста!

anton.kmedoedпропущено...

Нет конечно. Ноя не понимаю, почему если на одном инстансе развернуто несолько баз DB2 возникают вообще какие то проблемы при коммуникации между ними.

Если "нет конечно", то тогда, наверно, не стоило делать столь категоричное заявление, потому что подобные эскапады выставляют вас в весьма неприглядном свете. Далее, если вы чего-то не понимаете, то это, опять же, не дает вам право отзыаться нелестно о предмете обсуждения, в котором вы, по вашему же собственному утверждению, не разбираетесь - это отбивает всякое желание вести с вами диалог. Слушайте, вникайте, и делайте правильные выводы. Здесь люди тратят на объяснение ваших вопросов свое личное время, пытаются вам помочь и делятся информацией, которую, возможно, вы больше нигде не найдет - уважайте их за это, и ведите себя подобающим образом (это к вопросу о картинках, которым место в вашем Фйесбуке, а не на техническом форуме).

medoedЯ лишь о том что DB2, заявляемая как полноценная СУБД таковой не является по сути, даже потому что нельзя disable/enable триггер не поддерживается и даже потому что НЕПОЛНОЦЕННО организованы федеративные связи, могу ещё кучу багов привести!
Далее можете все что угодно писать и тролить, но против фактов не попрешь!!!
Что значит неполноценная СУБД? Как вы это оцениваете? Мне не хватает какой-то функции, значит система неполноценная? А как вам такой факт: DB2 - коммерчески успешный продукт с многомиллиардным оборотом и внушительной базой клиентов по всему миру. Почему все они пользуются "неполноценной" СУБД и еще и платаят за это деньги? В чем подвох?
В чем вопрос? Я считаю, что если нет полного функционала (а не отдельной функции) по федеративным связям (на удаление или изменение данных на удаленном источнике) - то да? я считаю такую СУБД не полноценной (тем более что здесь один и тот же источник данных база DB2). Мне есть с чем сравнивать, я поработал с базами Sybase, MSSQL и Oracle. На этом закончу, в этой теме я Марка просил ответить и он ответил по существу, за что ему спасибо!
Вы же свое уникальное и дорогущее время не тратьте на меня, тратьте только на продукты IBM, главное чтобы они вас вставляли!!!

[quot anton.k]medoedВ чем вопрос? Я считаю, что если нет полного функционала (а не отдельной функции) по федеративным связям (на удаление или изменение данных на удаленном источнике) - то да? я считаю такую СУБД не полноценной (тем более что здесь один и тот же источник данных база DB2). Мне есть с чем сравнивать, я поработал с базами Sybase, MSSQL и Oracle.
Вижу, что ущербность данного критерия оценки вам не очевидна. Придется объяснить на пальцах. Вот допустим, в DB2 есть такая замечательная функция как multi-temperature data management, а в MSSQL - нет. В DB2 есть настоящий, без всяких оговорок, columnar store engine. А в MSSQL - нет (а как же columnar store index скажите на это вы, и я отвечу - это костыль, который решает весьма ограниченный круг задач, это близко не то же самое, что columnar store в традиционном понимании). Исходя из этого, будем ли мы считать MSSQL ущербной СУБД? Следуя вашей же логике - нам так и слудует поступить. [quot]
А давайте проведем опрос среди разработчиков MSSQL и спросим натыкался ли кто то или не хватало ли тех возможностей то что вы описали выше?!
Я вам про распространенные вещи, а вы какие то узкопрофильные фишки! Да есть плюшки и в DB2 мне функция
понравилась, в MSSQL это через xml проще сделать. Но вот то что распостраненные вещи, которые в современных СУБД работают на ура в DB2 не реализованы! Неполноценная работа с федеративными серверами тому подтверждение! Ну а про то как они думают о конечных пользователях - показывает отсутствия деактивирования/активирования триггеров.

anton.kmedoedЯ вам про распространенные вещи, а вы какие то узкопрофильные фишки!
Вы упорно не желаете видеть дальше написанного. Я бы мог заменить multi-temperature и BLU (кстати, на счет BLU - вот уж никогда бы не подумал, что самая раскручиваемая в последнее время функция DB2 на самом деле узкопрофильная, ну да ладно) на десяток других возможностей, аналогов которых нет в MSSQL, суть от этого бы не изменилась. Мысль, которую я пытаюсь до вас донести очень простая - нельзя просто так взять и назвать информационную (да и любую другую) систему неполноценной, ущербной или недостойной внимания только потому, что в ней не реализованны некоторые функции, которые поддерживаются другими системами, потому что очень легко вы можете попасть в обратную ситуацию, как я вам это только что наглядно продемонстировал. Надеюсь с этим мы разобрались.

medoedА давайте проведем опрос среди разработчиков MSSQL и спросим натыкался ли кто то или не хватало ли тех возможностей то что вы описали выше?!
Очень хорошо, что вы об этом заговорили, потому что я могу предложить вам провести аналогичный опрос среди разработчиков DB2 с целью выяснения как многим из них нехватает возможности выполнять модифицирующие операции на федеративных объектах в триггерах, функциях и compound statement'ах.

medoedНу а про то как они думают о конечных пользователях - показывает отсутствия деактивирования/активирования триггеров.
Про то, как они думают о пользователях, лучше всего говорит количество разрешенных PMR и исправленных дефектов.
Опять вы много буков написали. Не жалеете своего времени Хотите опросы, проводите - мне за это деньги не платят.
Для меня прямым и косвенным доказательством является распространенность СУБД на рынках. MSSQL у нас более распространено чем DB2 и думаю не просто так! Выбирают чаще не только, что дешевле - но и то что удобнее! Адьюс!

Евгений Хабаровmedoed,

Любую задачу можно, как правило, решить более чем одним способом.

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

Но, вы пробовали сформулировать для себя или здесь исходную задачу?
Возможно, для нее существует другой способ решения, который более подходит для СУБД DB2.
Возможно, для СУБД DB2 вообще нет принципиальной необходимости разносить данные по нескольким базам, либо можно применить другие техники для решения первоначальной задачи.

Т.е. возможно для Вашей задачи существует другое архитектурное решение (для СУБД DB2), возможно даже более простое и надежное, чем то, что вы пытаетесь реализовать.
Ну, или, как вариант, СУБД DB2 не подходит (в чем я сомневаюсь) для решения той задачи, которая вам нужна.

В любом случае, это не повод говорить про "ущербность" DB2.
С тем же успехом я могу сказать что MS SQL совершенно ущербная СУБД, т.к. не работает на платформах IBM Power(AIX), IBM System z (z/OS и z/Linux). Для Вас это не критично, а для меня - очень критично.

В мире IT нет "серебряной пули", поэтому решение нужно подбирать под конкретную задачу. И иногда задачу нужно переосмысливать исходя из преимуществ, которые предоставляет продукт, чтобы максимально эффективно его использовать.
Мы уже решили эту задачу на текущий момент через клиент и дополнительную таблицу на справочной базе.
Я тут думал, мозххххи, которые все говорят о неверном архитектурном подходе и о том что не надо было разносить по разным базам - скажут нужное решение, но нет, они тока критиками могут быть!
Озвучу сам разумное решение - верным был бы подход (7-мь лет назад) разнести данные не по базам, а по схемам в рамках одной базы для каждой логической сущности. Это бы дало и независимость данных (не было бы блокировок) и скорость запросов была бы громоздкой! Минусом была бы динамика в запросах, но наш (да и любой толковый) клиент это умеет.

Зы: Про то что MSSQL не работает, под другие платформы согласен - но и винда не самая плохая и редкая вещь!
Сорри, но нет времени на дальнейшую переписку! Я останусь при своем мнении, а вы и дальше молитесь на IBM, я не против

Евгений Хабаровboogimanпропущено...

Каждую схему в отдельное табличное пространство и усе. Не?
Можно и каждую таблицу в отдельное табличное пространство.
Схема - это способ логической организации объектов (таблиц, индексов, функций и т.п.). Позволяет, помимо прочего, создавать одноименные таблицы (в разных схемах).
Ну это уже перебор, как мне кажется... Схема была бы удобно для каждой сущности(для каждого логического объекта). Получается совокупность классов, одинаковой структуры. Весьма удобно имхо...

const64boogimanПро рынки распространенности. Давайте рассмотрим те, которые не подвластны американскому лоббированию: Китай и Россия например. Посмотрим уровень распространенности современных СУБД в этих странах. Думаю DB2 уступит MSSQL and Oracle. Догадываетесь почему?
А ссылки есть? А то я пока только от Oracle нашел...
Искать в лом. Но опять же косвенные подтверждения есть:
T-SQL - язык года (2013)

const64medoedпропущено...

Искать в лом. Но опять же косвенные подтверждения есть:
T-SQL - язык года (2013)
Ну, ну, ну... а если на PHP в основном под MySQL пишут, то что, он круче чем MSSQL? А на C вообще можно писать под любую СУБД...
Ну вы высокоуровневые ООП языки с языками баз данных не путайте! У базы MySql своя ниша, думаю он тоже пораспространенней в вышеуказанных странах, чем DB2

anton.kboogimanКаждую схему в отдельное табличное пространство и усе. Не?
Забыли перелогиниться? ;) Я не могу утверждать однозначно, что это бы помогло в вашем конекретном случае. Да, возможно блокировок стало бы меньше, так же как и возможно, что это вовсе не было узким местом в вашей системе, так что предложенный вами вариант выглядит как неплохая попытка решить проблему малой кровью, но он вовсе не является панацеей и ничего не гарантирует. Впрочем, я уверен вы и сами это прекрасно понимаете.
Ага писал со смартфона, а там по дефолту для данного сайта другой логин стоял)) Думаю бы помогло и значительно (а малую кровь - считай халяву любят многие ). У нас сейчас половина проблем в блокировках от MQT, они бы соответственно стали не нужны. Другую крупную проблему даже озвучивать боюсь (засмеете), она в коде. Надоть будет попробовать как нить переписать.
Я рад, что вы признаете хоть отчасти разумные доводы собеседника

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

boogimanПро рынки распространенности. Давайте рассмотрим те, которые не подвластны американскому лоббированию: Китай и Россия например. Посмотрим уровень распространенности современных СУБД в этих странах. Думаю DB2 уступит MSSQL and Oracle. Догадываетесь почему?
DB2 действительно уступает по распространнености ряду других крупных вендоров, однако, говоря, о распространнености, рассматривать ее нужно в разрезе региональных рынков и сегментов области пременения. И тогда окажется что там, где DB2 прочно занимает свою нишу, MSSQL не маячит даже на горизонте, и о каком доминировании, или распростраенности в таком случае можно вести речь? В этом вопросе вы снова совершаете всю ту же ошибку, что и раньше - вы выбираете слишком упрощенный критерий для оценки сложных процессов, который идеально подходит под выстроенную вами картину мира, но к реальности имеет весьма опосредованное отношение.
Уфф. Ну возьмем финансовый сектор или страховой, пусть даже Российский. Крупняк из СУБД выбирает как правило Oracle , мелкий и средний MSSQL. Я сейчас говорю исключительно о количестве, вы с этим будете спорить?

Евгений Хабаровmedoedпропущено...

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

anton.kЕвгений ХабаровЯ к тому, что схема и табличное пространство, условно говоря, перпендикулярны.
Схема - это логическое разделение объектов базы. Табличное пространство - физическое расположение и организация.
Разнесение таблиц по разным табличным пространствам и буферным пулам дает дополнительные рычаги управления производительностью и напрямую со схемой не связано никак.
Думаю, тут имело место продолжение изначальной идеи разнесения таблиц по схемам, с последующей корректировкой, что все объекты из одной схемы будут помещены в отдельное табличное пространство
Да я это имел в виду!

Евгений Хабаровmedoedпропущено...

Тоесть вы утверждаете, что
, если все таблицы схем находятся в разных табличных пространствах, то запросы будут лочить друг друга? При изоляции на уровне строк?
Я думаю вы не правы!!!
Каким образом сделан такой вывод из того, что я написал выше?
Вы критиковали мое предложение первоначально про разбиение по схемам, не поняв сути до конца.
Антон уточнил и согласился в целом, что профит (правда он думает что небольшой), но будет.
Я вам конкретный код привел, который по моему предложению - давать блокировок не будет.
Ну как бы чтобы развеять все сомнения.

anton.kmedoedУфф. Ну возьмем финансовый сектор или страховой, пусть даже Российский. Крупняк из СУБД выбирает как правило Oracle , мелкий и средний MSSQL. Я сейчас говорю исключительно о количестве, вы с этим будете спорить?
Нет, спорить не буду, обсуждение уже давно вышло за рамки этого раздела форума и место ей в холиварной песочнице пососедству. Свою позицию по вопросу оценки "уровня распростраенности современных СУБД" я уже высказал, но повторю еще раз - я считаю, что если такие оценки и проводить, то сугубо в разрезе заранее определенных метрик и областей применения (как это делает Гартнер со своими квадрантами, например), все остальные способы оценки, а так же выводы, построенные на результах их применения, считаю неприменимыми, порочными и вводящими в заблуждение.

Ну и чтобы вы не обвинили меня в уклоненнии от конкретно заданного вопроса - да, в России, в финансовом и страховом секторе, как впрочем и в любом другом, DB2 проигрывает своим конкурентам по распространенности. Замените Россию на другую страну - и результат может быть уже другой. О чем это говорит? Только лишь о том, что в конкретно взятом регионе, в конкретно взятом секторе деловой активности СУБД MSSQL и Oracle являются более предпочтительными вариантом, чем DB2. Ни на какие другие вопросы эта информация ответов не дает, а только лишь пораждает новые, но это уже совсем другая история.
О лоббировании в Северной Америке и Европе определенных интересов, но это мое имхо. Там где решение принимают реальные спецы и архитекторы, выбирают то что удобно (в том числе и лучшую поддержку) и проверено практикой (не имеет подводных камней)!
Но пусть каждый останется при своем мнении... С уважением к Вам, Андрей!