dbtwoshnick,

Я бы сказал, что это не совсем правильная точка приложения силы.
Когда памяти более-менее хватает, и вы не имеете чёткого представления, зачем вам буфферпул именно такого размера, то чаще всего мы будем наблюдать совершенно замечательный hitratio (98-99%), но будет это за счёт крайне неэффективных запросов с очень большим соотношением ROWS_READ / ROWS_RETURNED.
Отсутствие того или иного индекса, плохо сформулированный предикат, ещё чего-то приводят к необоснованным table scan'ам. В каком-нибудь join'е всё это умножается на кардинальность второй таблицы, как результат получаем миллиарды прочитанных строк при требующемся десятке/другом тысяч.

Большие буфферпулы часто скрадывают/маскируют эту катастрофическую ситуацию, так что начните лучше с отлова таких запросов или _уменьшения_ буффрпулов с последующим разбором, как оно на hitratio влияет.

МысльMark BarinsteinКлассический реорг перестраивает индексы в конце. Зачем собирать статистику перед реорг тоже непонятно.

тем дороже оборудование нужно, предлагаю запускать все это в цикле, чтобы было еще дольше
Не надо усложнять. Где денег спереть кто надо и так найдёт, без помощи горе-девелоперов.
Всё обычно проще - "пусть лошадь думает, у неё голова большая".

dbtwoshnickЯ не хочу вносить какие-либо изменения в структуру базы данных, даже если это улучшит ее работу
потому что это лишняя ответственность, вдруг такое изменение временно что-то улучшить, а потом после очередной версии ухудшит.

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

Это _ваша_ организация платит за железо и DB2'шные лицензии. Чего ж зря мощности раздувать.