Gallemar,

я ж тебе уже все на эту тему рассказал. кому-то мало, кому-то много. Для классика и суперклассика - зависит от того, как часто одни и те же страницы модифицируются разными коннектами. Синхронизация измененных страниц в этих архитектурах идет через диск. Соответственно, при большой конкуренции по записи большой кэш не имеет смысла, он просто отжирает память у ОС.
И, да, размер кэша определяется экспериментально. И размер памяти, занимаемый кэшем, большого значения не имеет. Больше влияет количество страниц кэша.
Минимум страниц кэша = по 2 страницы на 1 таблицу, которую читает коннект, прямо или косвенно.
Например, если коннект обращается к 100 таблицам, значит минимальный кэш для CS/SC = 200 страниц.
Максимальный для CS, для большинства систем, показывает, что при >2048 страниц производительность ухудшается. Для SC может быть и 4096, но обычно не больше.
Для SS, понятное дело, кэш общий, там вообще можно вздуть кэш по максимуму, а кэширование ОС файла БД вообще отключить.

Gallemar,

в классике размер процесса обычно больше размера кэша. Потому что если кэш 2048 по 8к, это всего 16 мегабайт. А в 2.5 средний размер процесса обычно бывает от 150 до 250мб.
Потому что внутри него - кэш БД, кэш метаданных, память на битовые маски индексов, кэш сортировки, и т.д.