Базы данных Oracle - статьи
предоставила решение для продемонстрированной
Версия Oracle 7 предоставила решение для продемонстрированной выше проблемы. В версии 7, Oracle представил средства расширенной трассировки SQL-операторов. При включении расширенной трассировки (уровень 8 в табл. 1), ядро Oracle может сообщить, на что именно потрачено время. (Кстати, я начал практически работать с Oracle как раз версии 7.0.16 в 1994 году. Тогда меня подобные проблемы вообще не интересовали - важно было установить сервер и научиться компилировать код на Pro*C. Следующих 5-6 лет трассировку я так и не использовал...) Раньше предполагали, что время уходит на ввод-вывод с диска. Однако точно показывает, на что реально было затрачено время в ситуации, представленной ранее в : ядро Oracle ждало 4 раза, в итоге - около 10 секунд, событий enqueue. Другими словами, изменение было заблокировано - сеанс не мог установить блокировку.
Листинг 4. Трассировка уровня 8 показывает, на что ушло время
===================== PARSING IN CURSOR #1 len=31 dep=0 uid=73 oct=6 lid=73 tim=27139911 hv=1169598682 ad ='68f56dc8' update c set v1='y' where key=1 END OF STMT PARSE #1:c=0,e=902,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=27139911 WAIT #1: nam='enqueue' ela= 307 p1=1415053318 p2=393254 p3=35925 WAIT #1: nam='enqueue' ela= 307 p1=1415053318 p2=393254 p3=35925 WAIT #1: nam='enqueue' ela= 307 p1=1415053318 p2=393254 p3=35925 WAIT #1: nam='enqueue' ela= 132 p1=1415053318 p2=393254 p3=35925 EXEC #1:c=2,e=1056,p=0,cr=3,cu=3,mis=0,r=1,dep=0,og=4,tim=27140969 WAIT #1: nam='SQL*Net message to client' ela= 0 p1=1413697536 p2=1 p3=0
Можно было догадаться? Да. В конечном итоге, оператор UPDATE в Oracle может быть заблокирован. Но причина могла быть и в чем-то другом. На самом деле, скажем, в версии Oracle 7.3.4, это могло произойти по одной из 106 причин, поскольку в версии 7.3.4 трассировкой было охвачено 106 различных веток кода ядра Oracle.
Так что, при среднем "везении", вероятность угадать была около 1%. Но даже если бы вы и угадали, без средств расширенной трассировки вы бы не могли этого доказать. Можете угадать, что это была за блокировка и в каком режиме? Интерпретируя трассировочные данные (p1=1415053318) в соответствии со статьями Oracle Metalink, например, 55541.999 и 62354.1, можно точно сказать, что это исключительная блокировка TX.
Для включения расширенной трассировки в Oracle версии 7 как раз и появился уже представленный ранее оператор ALTER SESSION, устанавливающий событие 10046:
alter session set events '10046 trace name context forever, level 12' ... alter session set events '10046 trace name context off'
Поддерживаемые уровни трассировки были представлены ранее в .
С помощью этого оператора можно включить трассировку в приложении, создатели которого об этом позаботились. (А вы, господа, в нынешнем 2006 году, через 13 (!) лет после выхода версии 7, предоставляете возможность включения и отключения трассировки в своих приложениях? То-то же...). Хорошо, если доступен исходный код приложения - тогда вы сможете его дополнить... А если нет?
Можно, конечно, включить трассировку нужного уровня для всей системы с помощью оператора ALTER SYSTEM. Но от этого будет больше проблем, чем пользы. Диски могут оказаться забиты трассировочными файлами. А если места и хватит, большая часть информации окажется абсолютно бесполезной.
Стадартный пакет Oracle, DBMS_SYSTEM, позволяет действовать намного избирательнее. Упоминавшаяся выше (в разделе "Различные способы включить трассировку") процедура DBMS_SYSTEM.SET_EV позволяет АБД (пользователю sys) включить расширенную трассировку любого сеанса в системе:
dbms_system.set_ev(sid, serial, 10046, 12, ") ... dbms_system.set_ev(sid, serial, 10046, 0, ")
Однако процедура эта и по сей день (официально) не поддерживается. Причем, по соображениям, скорее, "политическим", чем техническим.
На первый взгляд, отказ от поддержки процедуры SET_EV выглядит вполне обоснованным. Привилегию на выполнение пакета DBMS_SYSTEM АБД в производственной системе никому предоставлять не должен - при этом пользователи получат слишком широкие права. Да и сам АБД, при неправильном использовании процедуры SET_EV, может нанести серьезный ущерб системе. Например, если указать вместо события 10046 событие 10004, будет сымитировано разрушение управляющего файла, а это вряд ли полезно в производственной среде... Тем не менее, на практике использование пакета
DBMS_SYSTEM зачастую более чем оправдано. Странно, что использование расширенной трассировки поддерживается официально уже много лет, а вот средства избирательного ее выключения - нет.
