DeepEdit!

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

В главе 12 приведены некоторые сегменты кода, снабженные измери­тельными средствами, для нескольких распространенных версий ядра Oracle, начиная с 7.3.4. Обратите внимание, что с увеличением номера версии значительно увеличивается и количество таких сегментов. На­пример, в версии 9.2.0 имеется 146 дополнительных, по сравнению с версией 8.1.7, измеряемых системных вызовов. Конечно, некоторые из этих событий представляют новые возможности продукта. Возмож­но, что часть новых имен в V$EVENT_NAME относится к сегментам кода, которые присутствовали, но не были оснащены измерительными сред­ствами в более ранних версиях ядра Oracle.

Если корпорация Oracle оставляет какую-то последовательность инст­рукций ядра без измерительных средств, то неучтенное время может проявиться в одном из двух вариантов:

Пропущенное время внутри вызова базы данных

Любой код, не содержащий измерительных средств и выполняемый в контексте вызова базы данных, приводит к расхождению значе­ний общей продолжительности вызова базы данных (e) и суммы зна­чений c + Eela для данного вызова. Данные файла трассировки не позволяют отличить это явление от рассмотренной ранее проблемы наличия времени, проведенного вне выполнения. В тех системах, где интенсивность свопинга невелика, значительное несоответствие частей (Д) данного равенства в рамках всего файла трассировки го­ворит о недостатке измерительных средств:

Для того чтобы осознать проблему, представьте себе, что продолжи­тельность пятисекундного чтения файла базы данных, выполняе­мого вызовом выборки, не измеряется. Фактическая продолжи­тельность выборки (e) составила бы 5 секунд, при этом ни общее время использования процессора (c), ни длительность событий ожидания (значения ela) не были бы настолько велики, чтобы со­ставить общую фактическую продолжительность вызова.

Пропущенное время между вызовами базы данных

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

В качестве примера данной проблемы можно привести ошибку Ora­cle с номером 2425312. Речь идет о случае, когда целые вызовы ба­зы данных, выполненные посредством PL/SQL RPC, не выводят ни­каких данных трассировки. В результате в файле трассировки мо­жет возникнуть огромный промежуток неучтенного времени.

На практике ситуация, в которой неизмеряемый системный вызов за­нимал бы значительную часть фактической продолжительности про­граммы, может не встретиться никогда. Мы в hotsos.com сталкивались с подобным явлением не чаще, чем в пяти случаях из тысячи файлов трассировки. Одним из вариантов неизмеряемой активности базы дан­ных является ошибка 2425312 в Oracle MetaLink. Такую ошибку мож­но увидеть при трассировке приложений Oracle Forms, содержащих (на стороне клиента) код PL/SQL. Могут встретиться и другие случаи серьезного влияния неизмеренного времени на ваши исследования, но они будут редкими.

Применяя трассировку SQL, вы встретите по крайней мере один неиз-меряемый системный вызов - вызов write, посредством которого ядро Oracle записывает вывод трассировки SQL в файл трассировки. Влия­ние этого вызова на производительность обычно невелико. С помощью утилиты strace нетрудно разобраться, каким образом ядро Oracle за­писывает каждую строку данных в файл трассировки. Из нескольких сотен файлов расширенной трассировки SQL, собранных нами в hot-sos.com к моменту написания этой книги, менее чем в 1% случаев на­блюдается накопление неучтенного времени, которое можно объяс­нить медленной записью в файл трассировки. Однако для того чтобы снизить риск существенного ухудшения производительности прило­жения за счет самого факта применения трассировки, необходимо сле­довать приведенными ниже рекомендациями:

• Обратитесь к Oracle MetaLink, чтобы проверить, не подвержена ли система ошибкам ядра Oracle, способным замедлить запись файла трассировки. Например, ошибка 2202613 влияет на производи­тельность записи файла трассировки для некоторых выпусков

MS Windows 2000. Ошибка 1210242 приводит к необоснованному снижению производительности Oracle при включении трассировки.

Разместите свои каталоги USER_DUMP_DEST и BACKGROUNDDUMPDEST на достаточно производительных устройствах ввода/вывода. Не запи­сывайте данные трассировки в корневую файловую систему или на самое старое и медленное дисковое устройство системы. Несмотря на то, что результатом диагностического процесса может быть зна­чительное улучшение производительности, ни один аналитик не захочет, чтобы его обвинили даже в кратковременном ее снижении.

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

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

Вы сможете исправить исследуемую программу, в результате чего будут сэкономлены вычислительные мощности и значительно уменьшено время отклика для конечного пользователя.

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