[ОТВЕТИТЬ]
Опции темы
21.06.2012 15:34  
OlegON
Давно обратил внимание, что логи оптимизатора никто не читает, хотя они напичканы полезной информацией. Но иногда влом обеспечивать связь и ставить оптимизатор для какой-то простейшей и единственной операции (если есть - обязательно посмотрите, поскольку информации так куда больше, чем в это примере). Разберем случай, когда среди кучи дисков вы сидите и не знаете, куда и что положить. Разделим проблему проседания винтов на две части: 1) плавность работы 2) общая нагрузка. В первом случае ситуация развивается по схеме "работаем, работаем, налетаем на медленный отклик от винта). Во втором - "работаем, работаем, налетаем на зверски загруженный и без того винт". Первый случай больше виден в OLTP, т.е. вместо плавной работы интерфейса он начинает икать, второй, например, сказывается на общем времени выполнения отчета. Есть системная вьюшка V$FILE_HISTOGRAM. Первая колонка - номер файла, вторая, SINGLEBLKRDTIM_MILLI - время ожидания, третья, SINGLEBLKRDS - количество таких ожиданий. Первым запросом будем выбирать файлы с большим временем отклика:
Код:
select d.name,h.SINGLEBLKRDTIM_MILLI,h.SINGLEBLKRDS from V$FILE_HISTOGRAM h, v$datafile d where h.file#=d.file# order by 2 desc,3 desc
вот пример вывода:
Цитата:
SINGLEBLKRDTIM_MILLI SINGLEBLKRDS
-------------------- ------------
/mnt/big/fftbles+4.dbf
16384 2

/mnt/stripe1/indx+6.dbf
16384 1

/mnt/stripe1/indx_ok.dbf
8192 2
видно, что big у меня чудовищно перегружена и сам винт тупой, поэтому при обращении к fftbles+4.dbf два раза было ожидание по 16384 миллисекунд. Соответственно, один раз было, что stripe1 просел и indx+6.dbf ждали 16384 миллисекунд. В зависимости от ценности файла можно рассматривать его претендентом на перенос куда-либо.

Вторым запросом - более нагруженные:
Код:
select d.name,sum(h.SINGLEBLKRDTIM_MILLI*h.SINGLEBLKRDS) "LOAD" from V$FILE_HISTOGRAM h, v$datafile d where h.file#=d.file# group by d.name order by 2 desc
пример вывода:
Цитата:
/mnt/main/users+2.dbf
30487678

/mnt/stripe1/indx+2.dbf
26867406

/mnt/main/users+1.dbf
26221257
по нему видно, что раз в первой табличке users+2.dbf не фигурирует, то в принципе ничего страшного, но тем не менее, по всем файлам больше всего ждать приходится его и если есть возможность его отсадить на отдельный винт - хорошо бы это сделать.
Можно так же анализировать еще одну вьюшку
Код:
select d.name,s.* from V$FILESTAT s, v$datafile d where s.file#=d.file# order by 5 desc,6 desc
 
"Спасибо" OlegON от:
29.06.2012 17:05  
leonid
По поводу дисков наш сисадмин говорит, что:
"Из 10 дисков лучше собрать один скоростной рейд 60 (ну или типа того) с одним скоростным кэшем на SSD, чем городить 5 зеркал."
Я говорю "У оракла концепция - раскладывать ТС по разным дискам."
Он - типа эта концепция не актуальна на современном железе.
Так в общем мы с ним и не пришли к единому мнению.
Ваши мысли?
 
29.06.2012 17:41  
OlegON
Мои мысли, что сисадмины и админы БД в большинстве случаев - совершенно разные люди. И к большому сожалению, 90% из сисадминов вообще таковыми не являются. Не знаю, что у вас там за железо, но я, например, еще не видел винтов, работающих со скоростью оперативки. Соответственно, если отдел аналитики не кладет десятком отчетов винты, на которых еще и оперативные таблицы лежат, то дело не в скорости современного железа, а в том, что база ваша еще не столь велика или аналитики не набрали методов оценки, но это все пройдет... Дорастет сисадмин до осознания, что разная нагрузка должна распределяться.
 
29.06.2012 17:49  
leonid
Но сколько бы не было массивов, они будут работать через один кэш контроллера.
А кэш например у меня сейчас 32GB (SSD).
Или это не противоречит идее раскладывать ТС по массивам?
 
29.06.2012 21:58  
OlegON
Да, я предлагаю еще и контроллеры делить, кто может. Смотри, абстрагируясь от железок, если есть дискА и дискБ, так вот при условии независимости их друг от друга (пусть даже частичной, как в случае одного контроллера), абсолютная загрузка дискаА не создает абсолютной загрузки дискаБ, так? Логика-то простая. Соответственно, десятки отчетов не убьют способность базы реагировать на запросы по оперативным таблицам, если они на разных винтах. На самом деле, если идти дальше, поднимаясь уровень за уровнем, то станет видно даже что распределение данных по разным файлам в разумных пределах дает выигрыш на уровне ОС. Как по производительности, так и по удобству администрирования.
 
 
Опции темы



Часовой пояс GMT +3, время: 11:39.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.