В 1980-х годах, когда была изобретена большая часть «методов на­стройки», функция трассировки SQL в Oracle еще не поддерживала выдачу информации о продолжительности событий ожидания - строк WAIT - в файл трассировки. Доступ имелся только к таким данным, как c, e и tim. Конечно, если основное время отклика было потрачено на по­требление времени процессора, то данные c и e могут предоставить практически всю необходимую информацию о производительности на­ших вызовов базы данных. Однако если какая-то часть времени откли­ка вызова базы данных не связана с потреблением времени процессо­ра, то анализ сильно усложнялся.

Рассмотрим статистику для вызова выборки, полученную от приложе­ния, работающего с версией Oracle 8.1.7.2:

FETCH #1:c=80741,e=151841,p=9628,cr=34304348,cu=10,mis=0, r=0,dep=0, og=4,tim=87762034

Фактическая продолжительность данного вызова составила 1518,41 с, и только 807,41 из них было потрачено на процессоре. На что же пошли остальные 711,00 секунд времени отклика? Возникала ли конкуренция блокировок? Событие ожидания блокировки? Длинные дисковые оче­реди? Избыточная подкачка страниц? Просто посмотрев на строку FETCH, на эти вопросы ответить невозможно. В статистике слишком ма­ло информации для определения того, на что были потрачены неуч­тенные 711 секунд продолжительности вызова. Конечно, большое зна­чение p указывает на то, что некоторая часть неучтенного времени могла быть потрачена на системные вызовы чтения, но дело в том, что существует приблизительно 200 различных событий ожидания, кото­рые Oracle мог бы выполнять в течение этих 711 секунд. Имея перед собой только приведенные сведения для выборки, мы не можем уз­нать, каким образом были потрачены 711 секунд.

В 1992 г., выпустив версию ядра 7.0.12, корпорация Oracle элегантно решила эту проблему. Новый механизм, предложенный Oracle, заклю­чался в снабжении измерительными средствами различных выпол­няемых ядром событий из числа тех, которые вносят вклад в фактиче­скую продолжительность, но не потребляют процессорного времени. Так называемые «данные ожидания» имели исключительную цен­ность. Они помогли заполнить временной провал между значениями e и c. Аньо Колк (Anjo Kolk) и Шари Ямагучи (Shari Yamaguchi) были первыми, кто описал использование «данных ожидания» в документе, ставшем поворотной вехой в истории, - «YAPP Method» (Метод YAPP) [Kolk and Yamaguchi (1999)].

Вернемся к предыдущему примеру, в котором было 711 секунд неуч­тенного времени. После того как ядро Oracle стало формировать стати­стику WAIT, в файл трассировки добавилось еще 9748 строк данных пе­ред информацией о вызове выборки. Выполнив программу Perl, при­веденную в примере 5.7, для 9749 строк данных трассировки, мы по­лучим следующий профиль ресурсов:

$ prof-cid waits.l.trc

Duration	Pct	Oracle kernel event
807.41s	53.2%	total CPU
426.26s	28.1%	direct path write
197.29s	13.0%	db file sequential read
76.23s	5.0%	unaccounted-for
8.28s	0.5%	latch free
2.87s	0.2%	db file scattered read
0.05s	0.0%	file open
0.02s	0.0%	buffer busy waits
0.00s	0.0%	SQL*Net message to client
1518.41s	100.0°%	Total response time

Теперь все понятно. Более 53% времени отклика для выборки было потрачено на работу процессора в пользовательском режиме. Более 28% было потрачено на запись на диск (что удивительно!). Еще 13% ушло на чтение с диска и приблизительно 6% времени отклика было потрачено на другие события ожидания.

Обратите внимание на строку «unaccounted-for» (неучтенное) в профи­ле ресурсов. Посмотрим, как она была получена. Общая продолжи­тельность (по существу, время отклика) вызова выборки - это просто значение e для выборки. В исходных трассировочных данных это вре­мя учитывается двумя способами:

Составляющая полного времени занятости процессора во времени отклика вызова выборки записывается в статистику c в самой стро­ке FETCH.

Составляющие времени системных вызовов во времени отклика вы­зова выборки записываются в статистики ela во все строки WAIT, от­носящиеся к выборке.

Так что «неучтенное» время оказывается равным значению А (дельта), вычисляемому по формуле:

Интересна эволюция учета времени отклика со времен версии Oracle 6. В версии 6 в файле трассировки отображалось время отклика для вы­зовов базы данных (e) и время занятости процессора (c), но это были единственные данные о времени отклика, которые выводило ядро Oracle. Первая модель времени отклика Oracle была чрезвычайно про­стой и формулировалась так: «время отклика равно времени использо­вания процессора плюс еще что-то несущественное» или же так:

Эта модель эффективна, когда величина А мала, но не заслуживает до­верия при диагностике многих проблем со временем отклика, возни­кающих при больших значениях А. Во времена версии 6 большинство аналитиков были обучены считать, что большие значения А соответст­вуют времени, потраченному на вызовы чтения операционной систе­мы. Это предположение часто оказывается неверным (как, например, в случае с только что рассмотренным профилем ресурсов), но все же оно помогло аналитикам решить многие проблемы производительно­сти приложений. Причина успеха модели (несмотря на ее упрощен­ность) в том, что огромное количество проблем приложений Oracle связано с вызовами выборки, которые избыточно обращаются к кэшу буферов базы данных. Этим случаям соответствуют маленькие значе­ния А, и модель e = c + А работает отлично.

Разработчики ядра Oracle одними из первых столкнулись с неадекват­ностью модели. Диапазон потенциально возможных причин для больших значений А так велик, что некоторые важные и сложные пробле­мы времени отклика просто невозможно решить без дополнительных оперативных данных. Представленные корпорацией Oracle в 1992 г. с выходом версии 7.0.12 данные расширенной трассировки SQL ста­ли превосходным решением задачи. Расширенные трассировочные данные включают в себя строки WAIT, рассказывающие о том, сколько времени ядро Oracle провело за «ожиданием» исполнения ключевых событий. Новая, значительно усовершенствованная модель времени отклика, ставшая возможной благодаря новой функциональности рас­ширенной трассировки SQL из версии Oracle 7.0.12, - это та модель, с которой мы работаем и по сей день:

С этого момента расширенная трассировка SQL смогла предоставить такие мощные диагностические возможности, о которых большинство аналитиков и не мечтало. Из тех немногих аналитиков, которые хотя бы осознают наличие интервала А, некоторые считают, что его существование объясняется недостатками расширенной трассировки, делаю­щими данные недостоверными. На самом же деле, как вы увидите да­лее, в значении А скрывается весьма полезная информация. Существу­ет несколько причин, вносящих свой вклад в ненулевое значение А,-об этом мы поговорим в главе 7. Понимание этих причин поможет вам в полной мере использовать всю диагностическую мощь предоставляе­мых Oracle данных расширенной трассировки SQL.