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

Рис. 6.2. Многопоточный сервер Oracle использует отношение один-ко-многим для клиентского и серверных процессов, поэтому данные о сеансе могут направляться в несколько файлов трассировки

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

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

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

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

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

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

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