DeepEdit!

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

Отсутствие межплатформенного стандарта именования трассировоч­ных файлов вызвало у нашей компании затруднения при создании пе­реносимого инструмента для поиска таких файлов. Мы рассматривали вариант с пополняемой таблицей шаблонов имен (т. е. регулярных вы­ражений), которую можно было бы исправлять по мере переноса Oracle на новые платформы и выхода новых версий. Но мы пришли к выводу, что при поддержании актуальности такой таблицы неизбежно возни­кало бы множество ошибок. В результате мы остановились на таком алгоритме:

1. По заданным идентификатору и порядковому номеру выбранного

сеанса (значения V$SESSION.SID и V$SESSION.SERIAL#) определить сис­темный идентификатор (SPID) соответствующего серверного про­цесса. Этот идентификатор содержится в поле V$PROCESS.SPID, соот­ветствующем выбранному сеансу, и может быть получен при помо­щи соединения, аналогичного приведенному в примере 6.3.

Найти, в каком каталоге располагаются файлы трассировки. Этот каталог определяется значением параметра USERDUMPDEST, если V$SESSION.TYPE='USER', или параметра BACKGROUNDDUMPDEST, если V$SESSION.TYPE='BACKGROUND'.

Отсортировать содержимое каталога по убыванию даты изменения файла (например, командой ls -lt в UNIX). Имейте в виду, что вре­мя изменения файла (атрибут mtime) обычно указывается с точно­стью до секунды. Поэтому, если несколько файлов были созданы в течение одной секунды, сравнение значений mtime не даст ответа на вопрос, какой из них был создан последним.

Для каждого файла из полученного списка, значение mtime которого превышает время начала сбора данных (можно задать и более точ­ное условие, но сравнение времени изменения со временем начала сбора данных - это более консервативный подход):

Найти в файле последнюю преамбулу. В особенности это касает­ся платформ Microsoft Windows, где ядро Oracle часто стремится повторно использовать трассировочные файлы, дописывая но­вые данные к уже существующим. (Поэтому в одном файле мо­жет быть несколько преамбул.)

Найти в преамбуле строку, содержащую подстроку «pid» (для Unix и OpenVMS) или «thread id» (для Windows). Преамбулу со­ставляют все строки вплоть до той, которая начинается с под­строки «***».

Если число, следующее за подстрокой «pid» или «thread id», сов­падает с идентификатором SPID выбранного сеанса, нужный файл найден, и поиск заканчивается.

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

Для проекта Sparky, о котором можно прочитать на сайте http:// www.hotsos.com, мною был написан переносимый код на Perl, выпол­няющий действия, аналогичные описанным.

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

Параллельное выполнение (Oracle PX)

При параллельном выполнении Oracle (Oracle Parallel eXecution - PX) серверный процесс Oracle порождает два или более дочерних процесса (называемых подчиненными процессами PX) для выполнения парал­лельного чтения и параллельной сортировки. Подчиненные процессы PX наследуют атрибуты трассировки от координатора запроса. Следо­вательно, включение расширенной трассировки SQL для сеанса, кото­рый использует функциональность PX, приведет к формированию не­скольких файлов трассировки. Задача заключается в том, чтобы опо­знать и проанализировать все нужные файлы. Обычно она решается достаточно просто - необходимо оценить время изменения файлов трассировки, сформированных последними. Для запросов, исполь­зующих степень параллелизма p, количество n соответствующих фай­лов трассировки будет находиться в диапазоне 1 < n < 2p +1 для каж­дого вовлеченного экземпляра.

Многопоточный сервер Oracle

Применение многопоточного сервера Oracle (MTS) несколько услож­няет поиск данных трассировки. MTS делает возможным использова­ние коммутируемых соединений, что приводит к созданию отношения «один-ко-многим» между сеансом и серверными процессами Oracle, которые обслуживают вызовы базы данных, выполненные сеансом (рис. 6.2). Соответственно, данные трассировки для одного сеанса мо­гут оказаться разбросанным по двум или более трассировочным фай­лам. Ядро Oracle предоставляет полные сведения по идентификации сеанса и временные метки каждый раз, когда сеанс мигрирует в новый серверный процесс (а следовательно, и в новый файл трассировки). Создать логический эквивалент единого файла трассировки для кон­кретного сеанса несложно. Рассмотренный ранее способ поиска фай­лов трассировки претерпевает следующие изменения:

В зависимости от версии Oracle, совместно используемые серверные файлы трассировки могут храниться в параметре BACKGROUND_DUMP_DEST (мы с коллегами видели это на некоторых платформах для версий 7 и 8) или же в USERDUMPDEST (наблюдается в версии 9).

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

Определив все файлы, которые содержат нужные данные трасси­ровки, необходимо отбросить данные, относящиеся не к вашему се­ансу, а затем объединить оставшиеся. Сначала избавляемся от сег­ментов данных трассировки, относящихся к сеансам, отличным от исследуемого. Чтобы определить, какие секции следует сохранить, достаточно просто просмотреть строки идентификации сеансов, ко­торые начинаются с символов ***. Затем объединяем оставшиеся участки данных трассировки по возрастанию времени. Это тоже не­сложно, т. к. строки *** содержат и значения времени. В результате получаем «виртуальный файл трассировки», содержащий сведения только для исследуемого сеанса. Эту операцию можно выполнить вручную в многооконном текстовом редакторе, а можно приобрести специальное средство, которое все сделает за вас. Наша команда на hotsos.com создала подобный продукт и предлагает его на коммерче­ской основе.

Пул соединений

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

Проблемы диагностики производительности для пулов соединений возникают тогда, когда сервер приложений «утаивает» личность ко­нечного пользователя от базы данных. Один сеанс разделяют между собой несколько пользователей, из-за чего невозможно по одному лишь файлу трассировки определить, чьи действия вызвали появле­ние некоторой строки в трассировочных данных (рис. 6.3).

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

Если приложение ничем не может помочь в трассировке команд SQL отдельного пользователя, не отчаивайтесь. Конечно же, существуют идругие пути, ведущие к успеху. Рассмотрим такой пример: пользо-

ватель Нэнси, имеющая IP-адрес 150.121.1.102, сообщила об ухудше­нии производительности приложения ввода заказов, основанного на пуле соединений (архитектура приложения приведена на рис. 6.3). Приложение никак не способствует выделению данных расширенной трассировки SQL для Нэнси.

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

Более эффективный обходной маневр - временное изменение архитек­туры, которое бы изолировало сеанс Нэнси. Один из способов реализа­ции такого изменения изображен на рис. 6.4, где изоляция сеанса Нэнси обеспечена за счет предоставления ей собственного процесса на сервере приложений и отдельного выделенного серверного процесса Oracle. Для того чтобы реализовать такой переход, можно, например, назначить Нэнси специальный «идентификатор службы» (аналог спе­циального псевдонима TNS для уровня служб приложения), который

Рис. 6.4. Если изолировать действия пользователя так, чтобы в назначенный ему файл трассировки не попадали данные об операциях других пользователей, то сбор диагностических данных становится таким же простым, как в случае простого клиент-серверного приложения обеспечивает соединение со специальным диагностическим процессом сервера приложений.

Противники этого метода обычно отмечают, что изменение архитекту­ры может оказать влияние на производительность исследуемого сеан­са Нэнси. Однако эти изменения имеют более локальный характер, чем в первом случае, т. к. мы не изменяем нагрузку, конкурирующую с действиями Нэнси. Конечно же, необходимо будет изучить сделан­ные изменения, особенно если окажется, что перемены в архитектуре повлияли на производительность. Например, если измененная архитектура, представленная на рис. 6.4, демонстрирует значительно бо­лее высокую производительность, чем архитектура на рис. 6.3, то сле­дует задуматься, не является ли виновником низкой производитель­ности процесс сервера приложений httpdO.

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

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

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

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

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

Любая проблема сбора данных, с которой когда-либо сталкивались мои коллеги, имеет свое решение. Надеюсь, что сайт hotsos.com -это одно из тех мест, куда вы в первую очередь будете заглядывать в поиске новых решений.