medoed,

Присоединюсь к Виктору.
Вы разбираетесь с плохим архитектурным решением и накручиваете сверху невесть что. Результат будет заведомо плохим.

Различные базы в DB2 by design независимы. У них свои выделенные блоки памяти, свои агенты (работающие в данный момент с конкретной базой), свой scope транзакций . Агент не может взять и полезть в "соседнюю" базу за данными, весь обмен идёт по DRDA протоколу.
Это
а) идеологически правильно (за что лично я люблю DB2, и из этого самым неожиданным образом вдруг вырастают всякие вкусные вещи)
б) позволяет изолированно управлять разными базами.

Из рассказываемого Вами следует то, что всё это должно быть одной базой. Ну так слейте всё вместе, в чём проблема? На уровне БД более чем достаточно механизмов разделения ресурсов, которые позволят отделять решение одних задач от других.
Если вы всё же не хотите, или есть веские причины этого не делать, то ПОЧЕМУ НУЖНО ОТКАЗЫВАТЬСЯ ОТ РОДНОГО МЕХАНИЗМА, специально предназначенного для инкрементального продуцирования изменений из базы в базу???

Репликации нуждаются в дополнительном maintenance? А кто обещал, что будет легко?! :)
У вас нет бэкапа для админа (это, вообще, админская работа, настраивать, мониторить и поддерживать репликации; мониторинг состояния репликаций отлично автоматизируется) на продуктиве на время болезней/отпусков??? :O Ну... срочно растите у себя ещё одного админа или совместителя. Мне непонятно, как можно жить без такого бэкапа.
Или ищите, кому можно отдать эту задачу на откуп (типа Triton ). Хороший вопрос, кстати, созрел ли у нас народ для подобных услуг (или, может, уже есть кто, такие услуги представляющий?).


По претензиям (ограничениям):
> 1) Триггеры нельзя disable/enable.

Да, неудобно. Но, возможно, свой смысл в этом есть.
Триггеры в DB2 "inlined" (с 9.7 для некоторых случаев можно сделать "compiled"), что означает, что тело триггера выполняется не как код в PVM (Procedure Virtual Machine), а встраивается непосредственно в запросы (и уже после компилируется и оптимизируются как единое целое).
"Выключение" триггера сразу инвалидирует пакеты и планы запросов в кеше, с ним связанные, т.е. может иметь достаточно большой impact.
При удалении, к примеру, view - это очевидно. "Выключении" триггера - не очень.

С другой стороны, если мы хотя бы чуть-чуть "в теме", дело, вроде, нехитрое:


(но надо ещё помнить про то, кто owner триггера, тут могут быть дыры в безопасности, как и с механизмом включения/выключения).


> 3) Уровень изоляции ставится на блок, вместо того, чтобы применяться к каждой сущности.

Не могу прокомментировать, пропустил часть обсуждения. Что именно Вам нужно (кроме как избавиться от блокировок на конкретном statement'е)?


> 4) Нет нормального монитора блокировок (аналог функции sp_lock), как на MSSQL или

Не хватает мощности MON_GET_LOCKS table function , MON_LOCKWAITS administrative view , MON_GET_APPL_LOCKWAIT table function , LOCKS_HELD administrative view , LOCKWAITS administrative view , их deprecated snapshot monitoring версий, locking event monitor'ов , диагностики в diagpath, db2pd ... -locks ... -wlocks ... ???

> sp_showplan (план текущего выполнения процесса), как в Sybase.

Картина примерно такая же как с блокировками.


> 5) Нет нормального профайлера (родного от IBM), который бы логину или по имени машины - показывал полный лог, до
> мельчайшей команды в realtime

Вы хотите сказать, что не нашли "on-line" визуализатора?
Вообще говоря
а) есть такие вещи как tracing (CLI/ODBC, JDBC), statement monitoring, event monitoring для activities и т.п.
б) если мы говорим о взрослой серьёзной системе, то сотни/тысячи запросов, выплёвываемые в realtime вряд ли вам нужны.


> 6) При массовой вставке в IDENTITY поле, функция IDENTITY_VAL_LOCAL() - функция возвращает NULL,
> scope_identity() - в MSSQL так себя не ведёт.

Ну, identity - это вообще отдельная песня. Я не уверен, что это хорошо, что IBM пошла на поводу у пользователей и ввела эту сущность в DB2. Разве что для облегчения миграций.
Identity плохо вписываются (точнее - никак) в транзакционные механизмы, служат источником многих проблем в долго живущих системах ("А-а-а-ааа!!! У нас диапазон идентификаторов заканчивается!!!!!"), создают ОГРОМНЫЕ проблемы при слиянии информационных систем (например, нескольких баз, разделённых по регионам, в одну) и т.п.
GENERATE_UNIQUE() - вот идеологически правильный путь.

В данном же случае (scope_identity() после массовой вставки) - вопрос, нахре... зачем он нужен???


> 7) В табличной функции DB2 (RETURN TABLE ) нельзя объявить табличную переменную,
> заполнить её и вернуть declare @t table и вернуть без всякого SET (только в процедуре).

Это опять же определяется декларативной/функциональной природой, присущей inlined compound statement'ам, а не императивной/процедурной, присущей compiled блокам.
Только в этом случае ф-я может быть предметом для оптимизации в рамках более общего выражения. Когда используемое выражение стоит во FROM это очень важно.
Наложенное ограничение может быть несколько искусственно, но оно не даёт скатиться в полный трэш при разработке:
чаще разработчики почему-то не умеют мыслить функционально и оперировать set'ами, проще понаделать временных таблиц, самостоятельно их заполнить, итеративно перебирая строки, потом уже итеративно проходить по этим временным таблицам и т.д.
это мало того, что требует массовых и одновременно весьма дорогостоящих операций типа fetch (чаще - из случайных мест таблицы, т.е. prefetch не работает), так ещё и однозначно определяет план выполнения, который далеко не всегда оптимальный (или далеко не всегда будет оптимальный).

Другой важный момент, для "compiled" табличных функций статистика была бы сильно урезана. Для external можно указать только предплолагаемую cardinality. Если можно было бы указать какую другую, то стояла бы большая проблема поддержки её актуальности.
Для inlined табличных ф-ий статистика вычислима (хотя, зависит, конечно, от того, что мы внутри накрутим).


PS Хотелось бы ко всему этому порекомендовать с осторожностью относиться ко всяким tips & tricks, встречаемым в сети.
Они далеко не всегда разумны, подчас давно потеряли свою актуальность, иногда представляют какие-то новые фичи, которые не всегда проверены временем.