V$FILE_HISTOGRAM, распределение файлов по дискам : Oracle

Давно обратил внимание, что логи оптимизатора никто не читает, хотя они напичканы полезной информацией. Но иногда влом обеспечивать связь и ставить оптимизатор для какой-то простейшей и единственной операции (если есть - обязательно посмотрите, поскольку информации так куда больше, чем в это примере). Разберем случай, когда среди кучи дисков вы сидите и не знаете, куда и что положить. Разделим проблему проседания винтов на две части: 1) плавность работы 2) общая нагрузка. В первом случае ситуация развивается по схеме "работаем, работаем, налетаем на медленный отклик от винта). Во втором - "работаем, работаем, налетаем на зверски загруженный и без того винт". Первый случай больше виден в OLTP, т.е. вместо плавной работы интерфейса он начинает икать, второй, например, сказывается на общем времени выполнения отчета. Есть системная вьюшка V$FILE_HISTOGRAM. Первая колонка - номер файла, вторая, SINGLEBLKRDTIM_MILLI - время ожидания, третья, SINGLEBLKRDS - количество таких ожиданий. Первым запросом будем выбирать файлы с большим временем отклика:
вот пример вывода:
видно, что big у меня чудовищно перегружена и сам винт тупой, поэтому при обращении к fftbles+4.dbf два раза было ожидание по 16384 миллисекунд. Соответственно, один раз было, что stripe1 просел и indx+6.dbf ждали 16384 миллисекунд. В зависимости от ценности файла можно рассматривать его претендентом на перенос куда-либо.

Вторым запросом - более нагруженные:
пример вывода:
по нему видно, что раз в первой табличке users+2.dbf не фигурирует, то в принципе ничего страшного, но тем не менее, по всем файлам больше всего ждать приходится его и если есть возможность его отсадить на отдельный винт - хорошо бы это сделать.
Можно так же анализировать еще одну вьюшку

По поводу дисков наш сисадмин говорит, что:
"Из 10 дисков лучше собрать один скоростной рейд 60 (ну или типа того) с одним скоростным кэшем на SSD, чем городить 5 зеркал."
Я говорю "У оракла концепция - раскладывать ТС по разным дискам."
Он - типа эта концепция не актуальна на современном железе.
Так в общем мы с ним и не пришли к единому мнению.
Ваши мысли?

Мои мысли, что сисадмины и админы БД в большинстве случаев - совершенно разные люди. И к большому сожалению, 90% из сисадминов вообще таковыми не являются. Не знаю, что у вас там за железо, но я, например, еще не видел винтов, работающих со скоростью оперативки. Соответственно, если отдел аналитики не кладет десятком отчетов винты, на которых еще и оперативные таблицы лежат, то дело не в скорости современного железа, а в том, что база ваша еще не столь велика или аналитики не набрали методов оценки, но это все пройдет... Дорастет сисадмин до осознания, что разная нагрузка должна распределяться.

Но сколько бы не было массивов, они будут работать через один кэш контроллера.
А кэш например у меня сейчас 32GB (SSD).
Или это не противоречит идее раскладывать ТС по массивам?

Да, я предлагаю еще и контроллеры делить, кто может. Смотри, абстрагируясь от железок, если есть дискА и дискБ, так вот при условии независимости их друг от друга (пусть даже частичной, как в случае одного контроллера), абсолютная загрузка дискаА не создает абсолютной загрузки дискаБ, так? Логика-то простая. Соответственно, десятки отчетов не убьют способность базы реагировать на запросы по оперативным таблицам, если они на разных винтах. На самом деле, если идти дальше, поднимаясь уровень за уровнем, то станет видно даже что распределение данных по разным файлам в разумных пределах дает выигрыш на уровне ОС. Как по производительности, так и по удобству администрирования.