Во всем согласен с DB2Adventurer. Естественно, лучше иметь одну базу, чем 50. Даже если БД-источники вырастут до 10 Гб получаем полтера, для DB2 при наличии соответствующего железа - это не размер. Единственно, что вам нужно обязательно обеспечить - так это уникальность записей в таблицах назначения. Я имею в виду то, что есть, например, таблица tbl1 во всех базах и она реплицируется в центральную базу в таблицу tbl1 и один филиал отреплицировал какую то запись в нее, а через 5 мин другой точно такую же (Primary_key или Unique одинаковые). В этом случае репликация не пройдет и будет лепить ошибку -803. Это первый момент.
Второй - нужно тщательно следить за функционированием репликации. Если в одном из филиалов случиться нечто в результате чего capture запустится в холодном режиме (журналы потерялись или ratention limit закончился), то apply из этого филиала в первом цикле аккуратненько обнулит все таблицы назначения и запишет в них копии своих таблиц не подозревая о том, что кроме нее в таблицы назначения пишут еще 49 apply.
Третье - ссылочная целостность. С этим всякие тоже заморочки бывают, но если у вас центральная БД используется только для отчетов и там никто ничего не правит, то в принципе можно прибить внешние ключи и ничего страшно в этом не будет.

P.S. Все, что написал относится к случаю если все филиалы быдыт реплицировать данные в ОДНУ одноименную таблицу. Если же Вы сделаете 50 схем с одинаковым набором таблиц и будете реплицировать по схемам типа филиал.таблица - схема.таблица то первого и третьего случая не должно, а второй не смертельно, ну обнулит свои таблицы и заново запишет.

Apply, мне кажется лучше запускать на серверах филиалов, а то на одном сервере 50 apply, да каждый в БД имеет 2 агента - всего 100, за ними и следить то тяжело, опять же ресурс жрут, но это конечно вопрос, с которым уже на месте определитесь