DeepEdit!

Итак, вы обнаружили в файле расширенной трассировки SQL событие ожидания, занимающее много времени. Следующая задача состоит в том, чтобы определить, какую операцию приложения можно изме­нить с тем, чтобы уменьшить расход времени. Эта задача легко реша­ется с помощью данных расширенной трассировки SQL. Необходимо сопоставить длительность каждого события WAIT #n первому вызову ба­зы данных для курсора #n, который следует за данной строкой WAIT в файле трассировки. Я называю этот метод опережающим атрибути­рованием (forward attribution). Опережающее атрибутирование помо­гает безошибочно определить, какая из SQL-команд приложения отве­чает за возникновение каждого периода ожидания. Как это ни удивительно, но опережающее атрибутирование работает для событий, ис­полняемых как внутри вызовов базы данных, так и между ними.

Опережающее атрибутирование для событий внутри вызовов

Для событий, исполняемых внутри вызовов базы данных, обоснова­ние опережающего атрибутирования вполне понятно. Строки записы­ваются в файл трассировки в момент завершения соответствующего действия, поэтому события ожидания, исполняемые определенным вызовом базы данных, появляются в потоке трассировки перед стро­кой вызова. Следующий отрывок кода (фрагмент примера 5.3), пока­зывает, каким образом ядро Oracle выдает в файл трассировки строки для событий ожидания, исполняемых внутри вызова:

В этом примере события db file sequential read, которым соответствуют строки О и ©, были исполнены в контексте вызова FETCH, представлен­ного в строке ©.

Опережающее атрибутирование для событий между вызовами

Для событий, исполняемых между вызовами базы данных, основание для применения опережающего атрибутирования не так очевидно. Следующий отрывок кода (фрагмент примера 5.4) помогает понять, как это работает. Из-за недостатков драйвера базы данных данное приложение дважды1 передает каждый вызов разбора в базу данных. Об­ратите внимание на две идентичных секции PARSING IN CURSOR, разде­ленные парой строк для событий to/from SQL*Net message:

Несмотря на то, что вызовы разбора были незатратными (два значения e=0 специально выделены в тексте), время отклика для всей пользова­тельской операции сильно увеличилось от огромного количества не­нужных выполнений события SQL*Net message from client, на которые бы­ло потрачено в среднем 0,027 секунды на вызов. Общее влияние на время отклика составило несколько минут для пользовательской опера­ции, которая в целом должна была занять менее 10 секунд (см. раздел «Ситуация 3: большая длительность события SQL*Net» в главе 12). Для того чтобы избавиться от исполнения событий SQL*Net, приведенных встроках О и ©, можно удалить вызов разбора, представленный встроке ©, которая следует за строками событий ожидания. В общем можно сказать, что вызов базы данных, «породивший» событие между вызовами, - это вызов базы данных, строка трассировки для которого следует за соответствующей строкой WAIT.