Стратегии и средства настройки 5 6 5

Поле Значение

ela Реальное время ожидания события в сотых долях секунды.

р1, р2, рЗ Параметры ожидаемого события. Каждое событие имеет определенный набор параметров. Значение параметров р1, р2 и рЗ для конкретного события см. в руководстве Oracie Server Reference

Теперь можно переходить к первому реальному оператору в трассировочном файле:

PARSING IN CURSOR #3 len=110 dep=0 uid=54 oct=47 lid-54 tim=6185026 hv=2018962105

ad=31991c8 declare

l empno number default 7698;

begin

update emp set ename = lower(ename) where empno = l empno;

end;

END OF STMT

PARSE #3:c=0,e=0,p=0,cr=0,cu=O,mis=l,r=0,dep=O,og=4,tim=6185026

BINDS #3:

Мы видим блок кода PL/SQL в том виде, в каком мы его передали. По записи PARSE можно понять, что разобран он был очень быстро, хотя и не был найден в библиотечном кэше (MIS = 1). Далее идет запись BINDS без детальной информации, поскольку в переданном блоке кода не использовались связываемые переменные. В дальнейшем мы еще вернемся к этой записи. Переходим к следующему оператору в трассировочном файле, где уже можно обнаружить кое-что интересное:

len-51 dep=l uid=54 oct = 6 lid=54

tim=6185026

WHESE EMINO

Pacing in cursor

hv=2518517322

ad=318e29cUPDATE END OF

Pa #4:c=0,e = 0,p = 0,cr=0,cu = O,mis=l,r=0,dep=l,og=0,tim=6185026 BINDS #4:

bind 0: dty=2 mxl=22(21) mal=00 scl = 00 pre=00 oacflg = 03 oacfl2 = l offset=0

size = 24

Глава 10

WAIT #4: nam=enqueue ela= 308 pl=1415053318 p2=393290 p3=2947

WAIT #4: nam=enqueue ela= 307 р1=1415053318 р2=393290 p3=2947

WAIT #4: nam=enqueue ela= 308 pl=1415053318 p2=393290 p3=2947

WAIT #4: nam=enqueue ela= 307 pl=1415053318 p2=393290 p3=2947

WAIT #4: nam=enqueue ela= 308 pl=1415053318 p2=393290 p3=2947

WAIT #4: nam=enqueue ela= 198 pl-1415053318 p2=393290 p3=2947

EXEC #4:c=0,e=5425,p=0,cr=17,cu=8,mis=0,r=l,dep=l,og=4,tim=6190451

EXEC #3:c=0,e=5425,p=0,cr=17,cu=8,mis=0,r=l,dep=0,og=4,tim=6190451

WAIT #3: nam=SQL*Net message to client ela= 0 pl=111183897 6 p2=l p3=0

WAIT #3: nam=SQL*Net message from client ela= 0 pl=1111838976 p2=l p3=0

Представлен оператор UPDATE в том виде, как его получил сервер Oracle. Он отличается от того, который использовался в PL/SQL-блоке, а именно: ссылка на l empno (переменная) заменена связываемой переменной. Перед выполнением SQL-оператора PL/SQL-машина заменяет в нем все вхождения локальных переменн1х связываемыми переменными. Кроме того, по записи PARSING IN CURSOR можно понять, что рекурсивная глубина (dep) теперь - 1, а не 0, как у исходного блока PL/SQL. Понятно, что это SQL-оператор, выполненный каким-то другим SQL- или PL/SQL-оператором; он не передавался клиентским приложением на сервер. Этот флаг можно использовать для поиска соответствующего SQL-оператора. Если поле dep имеет ненулевое значение, значит, выполнение SQL-оператора инициировано сервером, а не клиентским приложением. Это можно учесть при настройке. SQL-оператор, выполнение которого инициировано сервером, легко изменить без изменения приложения. Для изменения SQL-оператора, посылаемого клиентским приложением, необходимо найти соответствующее приложение, изменить код, перекомпилировать и снова установить его. Чем больше SQL-операторов находится на сервере, тем лучше - их можно изменить, не изменяя само приложение.

Для этого оператора тоже выдана запись BINDS, причем с детальной информацией. Наш оператор изменения содержит связываемую переменную, и можно явно узнать ее значение - первая связываемая переменная имела значение 7698. Теперь, если бы этот запрос был проблемным (выполнялся бы медленно), то имеется вся необходимая для его настройки информация. Есть точный текст запроса. Известны значения связывае-м1х переменных (так что можно повторно выполнить его с теми же данными). Известно даже, ожидание каких событий замедлило выполнение. Не хватает только плана выполнения запроса, но это лишь потому, что мы до него еще не дошли.

Запись BIND в трассировочном файле содержит следующую информацию:

Значение dty (тип данных) можно декодировать с помощью информации из представления USER TAB COLUMNS. Если выбрать из представления all views текст представления, для которого view name = USER VIEWS, можно увидеть функцию декодирования, сопоставляющую значениям dty строковые названия типов.

Интересующая нас информация - информация об ожиданиях - найдена. Можно четко увидеть, почему выполнение изменения потребовало почти минуту реального времени, хотя процессорное время, необходимое для этого, пренебрежимо мало. Мы ожидали снятия блокировки: в главах 3 и 4 было описано, что enqueue - один из двух внутренних механизмов, используемых сервером Oracle для поочередного доступа к разделяемым ресурсам. Трассировочный файл показывает, что мы ждали снятия блокировки, т.е. мы не ждали завершения ввода/вывода, синхронизации журнального файла или освобождения буфера, - мы стояли в очереди в ожидании освобождения некоторого ресурса. Если пойти дальше, можно взять значение параметра p1 и получить по нему тип блокировки, снятия которой пришлось ждать. Вот как это можно сделать:

(kjte@TKE816> create or replace

2 function enqueue decode(l pl in number) return varchar2

3 as

4 l str varchar2(25);

5 begin

6 select chr(bitand(l pl,-16777216)/16777215)

7 chr(bitand(l pl, 16711680)/65535)

8 decode (bitand(l pl, 65535),

9 0, No lock,

10 1, No lock,

11 2, Row-Share,

12 3, Row-Exclusive,

13 4, Share,