Глава 10

хоть что-нибудь о системе в целом: все знали только свои задачи и компоненты. Представить себе ситуацию в целом всегда сложно.

Поскольку ни один из компонентов не был снабжен средствами контроля и отладки, для выявления проблемы пришлось использовать представленные ранее средства СУБД. Трассировка с помощью SQLTRACE не показала ничего подозрительного (фактически, она показала, что SQL-операторы выполняются отлично). Профилировщик тоже не дал ничего, кроме подтверждения, что PL/SQL-код тоже работает отлично. Представления динамической производительности V$ в базе данных подтвердили, что все в порядке. С помощью этих средств мы просто доказали, что замедление не связано с работой СУБД. Но выявить проблему они не помогли. Она была вне базы данных, где-то между браузером и базой данных. К сожалению, этот промежуток представлял собой жуткую смесь страниц JSP, компонентов EJB, пулов подключений и CORBA-вызовов. Нам оставалось только снабдить код средствами контроля и отладки, чтобы выявить медленно работающий компонент. Нельзя было просто запустить программу под отладчиком, как в старые добрые времена . Приходилось работать с десятками компонентов и фрагментов кода, связанными по сети - именно эти компоненты и должны были нам указать, какой именно из них работает медленно.

В конце концов мы этот компонент обнаружили. Это б]л CORBA-вызов существующей системы, который выполнялся для генерации практически каждой страницы. Только создав журнальные файлы с временными метками, мы смогли это обнаружить. Оказалось, что это не проблема базы данных и даже не проблема приложения, но пользователям от этого легче не стало; для них не важно, чей код работает медленно. Жаль было потраченных на обнаружение причин проблемы недель.

Способ включения средств контроля и отладки зависит от используемого языка программирования. Например, в языке PL/SQL я использую специально разработанный для этого пакет DEBUG. Он реализует стандартный механизм журнализации для создания журнальных файлов в любой подпрограмме PL/SQL. Достаточно включить вызовы debug.f в код приложения следующим образом:

create function foo . . .

begin

debug.f(Enter procedure f00); if (some condition) then

l predicate := x=l; end if;

debug.f( Going to return the predicate %s , l predicate) ; return l predicate;

end;

и автоматически в журнал вносятся записи вида:

011101 145055 ( FOO, 6) Enter procedure foo

011101 145056 ( FOO, 11) Going to return the predicate x=l

При этом в журнал автоматически добавляется дата (01/11/2001) и время (14:50:55), а также информация о том, в какой процедуре/пакете и в какой строке б]л вызов. Можно

Стратегии и средства настройки 575

включать и отключать трассировку в любом модуле или наборе модулей. Это не только полезное средство отладки - по трассировочным файлам легко понять, что именно работало долго. Утилиту DEBUG мы еще рассмотрим в главе 21, где она многократно упоминается.

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

Еще раз повторю: все компоненты приложения, даже не связанные с базой данных, должны быть снабжены средствами контроля и отладки, особенно в современных средах, где редко встретишь приложение, взаимодействующее с единственным сервером. С учетом роста популярности Web-приложений, в особенности, использующих сложные распределенные архитектуры, определение источников проблем намного сложнее их устранения. Снабдив с самого начала код средствами контроля и отладки, мы реализуем защитный подход к программированию, который положительно скажется в дальнейшем. Я гарантирую, что вы никогда не пожалеете о включении в приложение средств контроля и отладки, жалеть придется, если вы этого не сделаете.

Я настоятельно рекомендую оставить средства отладки в коде готового приложения. Не удаляйте средства отладки в реально работающем приложении. Именно там они наиболее полезны! Я обычно подставляю пустую реализацию тела пакета DEBUG (где все функции сразу делают возврат). При этом если необходим трассировочный файл, я подставляю реальное тело пакета DEBUG, трассирую все, что нужно, а затем подставляю снова пустую реализацию. Удаление кода из производственного приложения из соображений производительности существенно снижает его полезность. Посмотрите на саму СУБД: путем установки огромного количества событий служба технической поддержки Oracle может получить огромный объем диагностических данных из производственной базы данных клиента. Разработчики ядра СУБД поняли, что отсутствие трассировочного кода в производственной системе значительно хуже, чем возможные дополнительные расходы ресурсов.

Набор утилит StatsPack

Мы уже рассмотрели средства настройки приложений. Трассировка с помощью SQL TRACE, пакет DBMS PROFILER, добавление средств контроля и отладки - все это обеспечивает настройку на уровне приложения. Если есть уверенность, что приложение работает максимально хорошо, имеет смысл разобраться с работой всего экземпляра базы данных, оценить его производительность в целом. Именно здесь перекрываются служебные обязанности и размывается грань между функциями администратора базы данных и разработчика приложений. Администратор базы данных должен найти причину замедления, но устранять ее зачастую приходится разработчику. Совместная работа в данном случае обязательна.

Раньше для оценки работы экземпляра использовались средства UTLBSTAT и UTLESTAT (начать сбор статистики и закончить сбор статистики). Сценарий UTLBSTAT

Глава 10

делал моментальный снимок многих представлений динамической производительности V$. Затем с помощью сценария UTLESTAT создавался отчет по начальным и конечным значениям в таблицах V$. Полученная статистическая информация обрабатывалась и выдавалась для изучения в виде простого текстового отчета. Начиная с Oracle8i, сценарии BSTAT/ESTAT формально б1ли заменены набором утилит StatsPack. Этот набор инструментальных средств намного превосходит прежние возможности BSTAT/ ESTAT. Наиболее существенным добавлением стала возможность сохранять значения представлений V$ в хронологическом порядке. Т.е. вместо удаления статистической информации после формирования отчета утилиты StatsPack позволяют сохранить данные и генерировать отчеты позже, при необходимости. При использовании средств BSTAT/ ESTAT, например, невозможно б1ло генерировать ежедневные отчеты и почасовой отчет для каждого дня недели. С помощью средств StatsPack можно установить почасовой сбор статистической информации (что мало влияет на работу системы) и генерировать отчеты, сравнивающие два моментальных снимка . Таким образом, можно создать отчет и за любой час, и за любой день недели.

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

Установка утилит StatsPack

Пакет утилит StatsPack должен устанавливаться при подключении как INTERNAL или, еще лучше, как SYSDBA (CONNECT SYS/CHANGE ON INSTALL AS SYSDBA), хотя в сценариях все равно будет выполняться CONNECT INTERNAL. Для успешной установки необходимо выполнить эту операцию. Очевидно, придется попросить сделать это администратора базы данных или администраторов сервера.

Если можно подключиться как INTERNAL, установка StatsPack - тривиальна. Необходимо просто выполнить сценарий statscre.sql в версии 8.1.6 или spcreate.sql в версии 8.1.7. Они находятся в каталоге [ORACLE HOME]\rdbms\admin после подключения как INTERNAL с помощью SQL*Plus. Процесс установки выглядит примерно так:

C:\oracle\RDBMS\ADMIN>sqlplus internal

SQL*PLUS: Release 8.1.6.0.0 - Production on Sun Mar 18 11:52:32 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved.

Connected to:

Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production

With the Partitioning option

JServer Release 8.1.6.0.0 - Production

sys@TKYTE816> @statscre

. . . Installing Required Packages

Перед запуском сценария statscre.sql надо знать следующее.