Начиная работу над этой главой, я предполагал подробно описать око­ло двадцати событий ожидания Oracle, которые с наибольшей вероят­ностью могут встретиться в вашей работе. Однако за последние не­сколько лет корпорация Oracle так хорошо потрудилась над совершен­ствованием документации по событиям ожидания, что повторение здесь этой информации стало бы пустой тратой времени. Документа­ция по настройке производительности Oracle9i release 2 [Oracle (2002)] написана достаточно хорошо. Вместо того чтобы пересказывать то, что вы можете свободно найти в других источниках, я в этой книге сосре­доточил усилия на трех направлениях, не освещенных в стандартной документации Oracle:

Рассмотрение двух псевдособытий («событий», в действительности таковыми не являющихся), длительность которых может быть оп­ределена по данным файла расширенной трассировки SQL: CPU ser­vice и unaccounted-for.

Более полное описание нескольких так называемых событий про­стоя, которое другие авторы опускают, не считая их заслуживаю­щими внимания. Эти события приобретают исключительную важ­ность в свете дополнительных возможностей диагностики, которые дают правильный выбор области сбора диагностических данных.

Акцент на исключении бесполезной нагрузки при возникновении различных событий ожидания.

Данный раздел посвящен псевдособытиям и так называемым событи­ям простоя. Ниже в этой главе будет рассказано об исключении на­грузки.

Псевдособытия Oracle

Вы, наверное, уже заметили, что там, где можно было бы ожидать тер­мина «событие ожидания» Oracle, употребляется термин «компонент времени отклика». Причина проста. То, что называется компонента­ми времени отклика, состоит из двух разных вещей: настоящих собы­тий ожидания Oracle, описанных в V$EVENT_NAME, и двух других важных компонентов, отсутствующих в этом представлении:

CPU service unaccounted-for

Несмотря на то, что ни один из этих компонентов формально не отно­сится к «событиям ожидания Oracle», оба они представляют собой из­меримые (и часто существенные) составляющие времени отклика лю­бой пользовательской операции. Они рассматриваются здесь наравне с событиями ожидания, потому что каждая микросекунда, затрачен­ная ядром Oracle на «работу», добавляет ко времени отклика пользо­вательской операции ровно столько же, сколько и микросекунда, по­траченная на «ожидание». Последние версии Statspack также включа­ют процессорное время в число пяти основных «событий ожидания».

CPU service

Практически каждый профиль ресурсов Oracle будет содержать ком­понент CPU service, показывающий затраты процессорного времени. Часто он вносит основной вклад в значение времени отклика как для эффективно реализованных пользовательских операций, так и для совершенно неэффективных. Вопрос в том, насколько оправдана такая потребность в процессорном времени (см. главу 5).

При диагностике причин чрезмерных затрат процессорного времени прежде всего надо установить, какие вызовы базы данных ответствен­ны за это в наибольшей степени. Для этого необязательно применять опережающее атрибутирование, т. к. статистики c, характеризующие затраты процессорного времени, находятся непосредственно в тех стро­ках файла трассировки, которые соответствуют вызовам базы данных. Отыскав вызовы, потребляющие основную часть процессорного време­ни, нетрудно найти и соответствующие секции PARSING IN CURSOR, содер­жащие исходный код (на SQL или PL/SQL), породивший эти вызовы.

В первую очередь следует обратить внимание на вызовы базы данных, имеющие наибольшие значения c без учета своих потомков. Если большие значения c для вызова базы данных возникают вследствие суммирования затрат времени их рекурсивным потомством, то затра­ты процессорного времени без учета потомства определяются спосо­бом, описанным в разделе «Двойной учет рекурсивного SQL» главы 5. Вспомните, статистики потребления процессорного времени и опера­ций LIO для вызова базы данных (c, cr и cu) относятся к тем, которые включают в себя затраты, сделанные их потомством.

Если вызовы, в наибольшей степени ответственные за продолжитель­ность компонента CPU service вашей пользовательской операции, най­дены, то дальнейшие действия (в зависимости от типа вызова базы данных) таковы:

Если много небольших значений c распределено среди значитель­ного количества вызовов FETCH или EXEC, исключите лишние вызовы базы данных везде, где это возможно, и объедините оставшиеся вы­зовы в наименьшее возможное количество вызовов (например, об­рабатывайте строки массивами, а не по одной).

Если большое значение c принадлежит отдельному вызову базы данных FETCH или EXEC, то сначала выясните, не связана ли загрузка процессора с операциями логического ввода/вывода (LIO):

При большом количестве операций LIO в вызове оптимизируйте SQL, как описано ниже в разделе «Оптимизация логического ввода/вывода» этой главы.

Если количество операций LIO невелико, то возможно, что сер­верный процесс Oracle тратит много процессорного времени на операции сортировки или хеширования. События 10032 и 10033 предоставляют подробную информацию об операциях сортиров­ки, а событие 10104 - о хеш-соединениях.

Возможно также, что большие затраты времени вызваны опера­циями приведения типов. Например, просмотр таблицы со срав­нением дат в каждой строке может очень сильно загрузить про­цессор.

Наконец, время может расходоваться на выполнение излишне ус­ложненного кода PL/SQL. Понятно, что выполнение инструкций PL/SQL требует работы процессора, даже если они не содержат обращений к базе данных. Большие значения c в строках файла трассировки EXEC для PL/SQL-блоков при малом количестве LIO (без учета потомков) часто означают, что время расходуется на выполнение ветвления, присваивания и других инструкций язы­ка. Для детальной диагностики выполнения кода PL/SQL можно воспользоваться имеющимся в Oracle пакетом DBMS_PROFILER [Kyte (2001)].

Если много небольших значений c распределено среди большого ко­личества вызовов PARSE, исключите как можно больше таких вызо­вов, следуя методике, изложенной ниже в разделе «Оптимизация разбора» этой главы.

Если большое значение c принадлежит отдельному вызову PARSE, то выясните, нельзя ли упростить команду SQL. Рассмотрите также возможность уменьшения значения параметра OPTIMIZERMAXPERMU-TATIONS (дополнительная информация доступна по адресу http:// www.ixora.com.au/q+a/0010/19140 702.htm).

unaccounted-for

Как рассказывалось в главе 7, существуют пять источников неучтен­ного времени в файле трассировки, соответствующего ненулевому зна­чению Д в уравнении e = с + ~Lela + Д:

Эффект влияния измерителя

Двойной учет использования процессора

Ошибка квантования

Время, в течение которого процесс не выполняется

Неизмеряемое время

Наличие такого количества неопределенностей в одном уравнении мо­жет вызвать сомнения в возможности определения вклада каждой из составляющих в Д. На самом деле работать с неучтенным временем unac­counted-for достаточно просто. Три из пяти его составляющих имеют ограничения, позволяющие считать их влияние на время отклика прене­брежимо малым. Если неучтенное время дает наибольший вклад в про­филь ресурсов пользовательской операции и данные получены в кор­ректно определенной области, то оно практически всегда вызвано наличием неизмеряемого времени или времени «невыполнения». Если источником неучтенного времени является отсутствие средств измере­ния в коде ядра Oracle, то, возможно, установка очередного обновления сократит количество реальных источников неопределенности до одного.

На практике большие значения неучтенного времени, как пра­вило, вызваны ошибками сбора данных, подобными тем, что описаны в главах 3 и 6. При аккуратном и точном выборе дан­ных в процессе сбора диагностической информации можно пол­ностью использовать те преимущества, которые дает обладание сведениями о продолжительности компонента unaccounted-for.

Подробно об этих пяти составляющих компонента времени отклика unaccounted-for рассказывалось в главе 7. Резюмируем сказанное там:

Эффект влияния измерителя незначителен (порядка нескольких микросекунд на вызов gettimeofday или getrusage), поэтому в целом им обычно можно пренебречь. Если влияние измерителя вас беспо­коит, то можно измерить его при помощи методики, изложенной в главе 7. Этот эффект вызывает небольшое увеличение Д.

Эффект двойного учета в большинстве событий невелик. Наиболь­шее влияние этого эффекта, виденное мной, проявлялось в событиях db file scattered read, перемещавших большие объемы данных (по­рядка 100 Кбайт и больше). В таких ситуациях наблюдался двойной учет примерно десяти миллисекунд на одно событие чтения. Двой­ной учет процессорного времени немного уменьшает значение Д.

Совокупный эффект, вызванный ошибкой квантования, также мал. В силу того, что вероятности возникновения положительных и отрицательных ошибок квантования одинаковы, эти ошибки ком­пенсируют друг друга, в результате чего их совокупное влияние на Д близко к нулю.

Если в профиле ресурсов длительность компонента unaccounted-for велика, то почти наверняка вы столкнулись либо со временем «не­выполнения», либо с неизмеряемым временем. В табл. 11.2 приве­дено хорошее эмпирическое правило. Время, в течение которого процесс не выполняется, всегда увеличивает Д.

Если приложение выполняет значительный объем кода ядра Orac­le, в котором отсутствуют средства измерения, то эффект неотли­чим от того, который вызван временем невыполнения процесса. В главе 7 рассказывалось, как обнаружить наличие неизмеряемых участков кода. Если даже в системе, не обремененной многочислен­ными переключениями контекста или подкачкой страниц, во вре­мени отклика преобладает неучтенное время, то следует обновить ядро Oracle, чтобы добавить измерительные средства в участки ко­да, выполняемые пользовательской операцией. Неизмеряемый код всегда вызывает изменение Д в сторону увеличения.