У меня большой нагрузки нет, но, тем не менее, считаю - federation годится, если только нет другого выхода (который позволит всё держать в одной базе). Правда, я имею дело с DB2 <-> Oracle и не имею дела с DB2 <-> DB2. И факт излишней перекачки, и генерируемые SQL-выражения Oracle мне довольно сильно не нравятся. Лучше скопировать все нужные данные себе в базу и с ними работать. Но:

Лично я в своё время умаялся с apply, работающей через federation. Любит виснуть, падать, самостоятельно останавливать свой сервис без вразумительного сообщения об ошибках, игнорирует мои команды через Replication Server. (Один сервер Oracle находится примерно в 20 километрах и примерно в 2 мегабитах (но вначале было 64 килобита) от нас, на достаточно загруженном канале; возможно, это оказывает влияние, но всё равно такие глюки как-то черезчур). В конце концов, после долгой борьбы и попыток понять, что, собственно, происходит, у нас она (apply) теперь работает не как сервис, а как консольное приложение в терминальной сессии, а скрипт на REXX'е эту штуку убивает через pskill и рестартует, если репликации не было в течение 90 минут.

MQT с deferred refresh (последний раз, когда я смотрел; быть может, поведение уже изменилось с каким-нибудь фикспаком) на federated-источнике освежается как бы в два приёма - данные куда-то полностью скачиваются, и лишь потом идёт вставка в таблицу, вместо того, чтобы вставлять сразу. На больших таблицах это довольно заметно.

Не помню, писал я это здесь или нет, но я как-то наткнулся на большую неприятность.

Итак: делаем CREATE NICKNAME ... (на таблицу, имеющую первичный ключ), затем DROP тот же NICKNAME, затем CREATE тот же NICKNAME... теперь оно не создаётся! Оказывается, при CREATE NICKNAME "под ковром" происходит всякая подозрительная деятельность вроде создания constraint'ов - "теней", а DROP NICKNAME их (по крайней мере, часть) не удаляет (и что с ними после этого делать, неизвестно). Повторное CREATE NICKNAME, обнаружив их существование, завершается с ошибкой.

Отметим, что в Control Center эти constraint'ы не видны. Таким образом, перед удалением Nickname нужно обратиться к системному каталогу.

Не знаю, исправили ли уже эту ошибку.