Документация Oracle на русском языке





Сайт посвящен разработке информационных систем с использованием технологий Oracle. На сайте можно найти полезную литературу и документацию на русском языке по программированию и администрированию Oracle.Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации.

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Определения фиксированных представлений


Поиск сведений о фиксированных представлениях 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.

 



jAntivirus