run09Но так ли это важно для OLTP базы со средним размером I/O Large read = 18 Mb/sec с редкими пиками Direct Reads в 80 MB/sec. И на весь I/O в среднем 120 IOPs ?

120IOPs даст пара SATA дисков по 10ТБ в зеркале, с высокой латентностью, но даст.

Быстрая хранилка полезна не столько для ежедневной работы, сколько для ситуаций когда надо много поменять, а времени дают мало. Т.е. "очень комфортно" это когда за среднее окно регламентных работ можно сделать full expdp\impdp. Это значит что почти любые чистки или конвертация данных, структуры таблиц поместится в окно. "Некомфортно" когда условная
конвертация превращается в многонедельный проект, чтобы и конвертацию сделать и приложение продолжало работать. А миграция между платформами в проект с временными серверами и goldengate.

run09master_yoda, т.е. иными словами, - не стоит "экономить" на спичках (с размерами и кол-ом) экстентов на современном железе?

Если это единственная БД, и ДБА нечем заняться, то можно конечно битовые карты поизучать. Но вопрос, заметит ли "улучшения" конечный пользователь или просто ДБА будет доволен тем, что запросы к DBA_EXTENTS не "тормозят"?

Есть старые БД, в которых как раз сделали всё "по уму", индексы отдельно от данных, ТП для маленьких, средних и больших сегментов, умножить на количество схем, да ещё часто всё на разных файловых системах (vxfs/vcs), красиво, упорядоченно. Но то разработчики ошиблись с ТП, особенно интересно, когда в ТП с 128К экстентом положили сотни ГБ, то место закончилось на файловой системе, то в табличном пространстве... и приходит понимание, что не надо это всё жонглирование вложенными друг в друга сущностями. Да, 10-15 лет назад думали что на какие диски положить, это имело определенный смысл, но сейчас, когда all flash СХД дешевле дисковых, с условными 10ТБ базы все эти ухищрения не заметны невооружённым взглядом. При миграции все базы складывается на одну ASM дисковую группу (+FRA, +REDO), в 3-4 ТП и жизнь становится проще :)