DeepEdit!

Поиск сведений о фиксированных представлениях V$ в публикациях об Oracle может оказаться нелегким делом. Иногда необходимая инфор­мация просто нигде не опубликована. Иногда она отыскивается, но ока­зывается неверной. Не следует слепо доверять публикациям по Oracle, относящимся к ядру, т. к. оно быстро развивается. К счастью, в том, что касается фиксированных представлений, ядро в некотором роде са­модокументировано. Секрет заключается в правильном использовании V$FIXED_VIEW_DEFINITION. Самое сложное здесь - запомнить это имя:

Из представления V$FIXED_VIEW_DEFINITION я, например, узнал точные определения столбцов STATE и WAITTIME представления V$SESSION_WAIT. Это можно сделать при помощи нескольких простых шагов. Начнем с выполнения следующего запроса, возвращающего определение представления V$SESSION WAIT:

Кстати, заметьте, что значение VIEWNAME для этого представления хра­нится в верхнем регистре. Итак, теперь вы знаете, что V$SESSION_WAIT -это просто отображение GV$SESSION_WAIT. Хотя пока это вам мало о чем говорит. На следующем шаге выясним определение GV$SESSION_WAIT:

Вуаля! Здесь можно заметить операцию округления при вычислении WAITTIME. Из приведенного текста также видно, в каких единицах вы­ражена величина, названная здесь X$KSUSECST.KSUSSTIM. Нам известно, что WAIT_TIME выражается в сотых долях секунды, также мы знаем, что ядро Oracle, чтобы получить сантисекунды, делит исходное значение на 104. Следовательно, в одной секунде содержится 10k единиц, причем 10k/104 = 102. Отсюда получаем 106 единиц KSUSSTIM в одной секунде. Другими словами, ядро Oracle измеряет время ожидания в микросекун­дах, а внешний API (V$SESSION_WAIT) представляет его в сантисекундах.

Обнаружение неэффективного SQL

Написанный Джеффом Холтом сценарий htopsql.sql, приведенный в примере 8.2, - это тот инструмент, посредством которого мы в hot-sos.com можем быстро выяснить, какая команда SQL из находящихся в данный момент в библиотечном кэше вносит наибольший вклад в за­грузку системы. Этот запрос напрямую не связан с временем отклика, но для большинства команд существует сильная корреляция между показателем LIO и полным временем выполнения SQL-запроса. Новые столбцы CPU_TIME и ELAPSEDTIME, появившиеся в Oracle9i, представляют в V$SQL сведения, ранее доступные только в данных трассировки SQL.

col	stmtid	heading	'Stmt Id'	format	9999999999
col	dr	heading	'PIO blks'	format	999,999,999
col	bg	heading	'LIOs'	format	999,999,999
col	sr	heading	'Sorts'	format	999,999
col	exe	heading	'Runs'	format	999,999,999
col	rp	heading	'Rows'	format	9,999,999,999
col	rpr	heading	'LIOs|per Row'	format	999,999,999
col	rpe	heading	'LIOs|per Run'	format	999,999,999
set	termout	on
set	pause	on
set	pagesize	30
set	pause	'More: '
set	linesize	95

Результат запроса отсортирован по количеству вызовов LIO, приходя­щихся на одну строку результата. Эта величина служит грубой оцен­кой эффективности команды. Например, представленные ниже дан­ные должны вызвать вопрос: «Почему для получения пяти строк приложению требуется более 174 миллионов обращений к памяти?»

SQL> @htopsql More:

				LIOs		LIOs
Stmt Id	PIO blks	LIOs	Rows	per Row	Runs	per Run
2503207570	39,736	871,467,231	5	174,293,446	138	6,314,980
1647785011	10,287,310	337,616,703	3	112,538,901	7,730,556	44
4085942203	45,748	257,887,860	8	32,235,983	138	1,868,753
3955802477	10,201	257,887,221	8	32,235,903	138	1,868,748
1647618855	53,136	5,625,843	0	5,625,843	128,868	44
3368205675	35,666	3,534,374	0	3,534,374	1	3,534,374
3722360728	54,348	722,866	1	722,866	1	722,866
497954690	54,332	722,779	0	722,779	1	722,779
90462217	361,189	4,050,206	8	506,276	137	29,564
299369270	1,268	382,211	0	382,211	42,378	9

Приведенные здесь данные помогли в 1999 году найти ту единствен­ную команду SQL, которая потребляла почти 50% общего процессор­ного времени в системе оперативной обработки. Однако определение эффективности команд по количеству LIO на строку может, как и в случае с любым отношением, привести к неверным выводам. Рас­смотрим, к примеру, такую команду SQL:

Этот запрос может вполне оправданно опросить множество блоков Ora­cle (даже с использованием индекса по первичному ключу CUSTID1), но вернет, как правило, только одну строку. Согласно отчету htopsql.sql, такой запрос неэффективен, хотя на самом деле такой негативный вы­вод может оказаться ошибочным.

Многие аналитики используют запросы, аналогичные htopsql.sql, в ка­честве первого шага в каждом проекте по повышению производитель­ности. Однако попытка основать метод повышения производительно­сти на каком-либо запросе к V$SQL чревата ошибками определения вре­менной области и области операций. Как и в большинстве данных, по­лучаемых из фиксированных представлений V$, в случае применения V$SQL трудно контролировать принадлежность данных определенному множеству программ на определенном интервале времени. Рассмот­рим следующие ситуации:

Команда SQL, требующая первоочередного внимания, не выполня­лась со времени расчета итогов последнего месяца. Команда отсут­ствует в библиотечном кэше и, следовательно, не попадет в сего­дняшний отчет по V$SQL.

Команда SQL, признанная «самой неэффективной», входит в про­грамму загрузки данных, которая в вашей компании никогда не бу­дет использована повторно.

Команда SQL, признанная «самой неэффективной», выполняется между полуночью и тремя часами утра. Поскольку допустимое вре­мя выполнения продолжается до 6:00, а все ночные пакетные зада­ния заканчиваются задолго до этого срока, медленное выполнение неэффективной команды SQL никого не беспокоит.

Команда SQL, производительность которой в наибольшей степени препятствует увеличению чистой прибыли, движению денежных потоков и возврату инвестиций, не попала в верхние строчки ни од­ного из отчетов по V$SQL. Она находится где-то в середине, т. к. ни один из ее статистических показателей особо не выделяется, но с точки зрения бизнеса именно она в наибольшей степени снижает экономическую эффективность системы.

Не обладая знаниями о бизнесе, невозможно решить, действительно ли критична для этого бизнеса производительность команды, располо­жившейся в верхних строчках отчета. Я уверен, что из всех фиксиро­ванных представлений V$SQL - самое ценное для аналитика по производительности. Однако эффект от применения этого представления в проекте повышения производительности существенно меньше, чем от Метода R.