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

ORA-00001: unique constraint (TKrE.SYS C002207) violated tkyte@TKE816> exit

В трассировочном файле я обнаружил:

PARSE ERROR #3:len=15 dep=0 uid=69 oct=3 lid=69 tim=7160573 err=903 select * from

PARSING IN CURSOR #3 len=27 dep=0 uid=69 oct=2 lid=69 tim=7161010 hv=1601248092

ad=32306c0 insert into t values ( 1) END OF

PAE#3:c=0/e=0,p = 0,cr=0,cu = 0,mis = 0,r=0,dep = 0,og=4,tim=7161010

EC #3:c=l,e=9,p = 0,cr=9,cu=7,mis = 0,r=0,dep = O,og = 4,tim=7161019 #3:err=l tine=71610l9

Как видите, поиск проблемного SQL-оператора, ставшего причиной ошибки, с помощью этого метода - тривиальная задача. При этом сразу видно, что не так. Это крайне полезно при поиске ошибки, возникающей, например, глубоко в коде большой хранимой процедуры. Неоднократно я сталкивался с ситуацией, когда ошибка возникала в глубоко вложенном вызове хранимой процедуры, а в приложении использовался обработчик исключительных ситуаций WHEN OTHERS, который все исключительные ситуации перехватывал и игнорировал. По моему убеждению, обработчик исключительных ситуаций WHEN OTHERS использовать вообще нельзя, а все приложения, в которых он используется и при этом не возбуждает исключительную ситуацию повторно, необходимо немедленно удалять - это бомбы замедленного действия. Рано или поздно ошибка произойдет, но она будет перехвачена и проигнорирована, и никто об этом не узнает. Будет казаться, что процедура работает, но на самом деле это не так. В этом случае установка SQL TRACE покажет, что действительно делает процедура, и ошибка будет обнаружена. Останется только разобраться, почему эта ошибка игнорируется. Я также использую трассировку, когда при выполнении операторов в]даются неинформативные сообщения об ошибках. Например, если при обновлении моментального снимка (материализованного представления) выдается сообщение об ошибке ORA-00942: table or view does not exist, установка параметра SQL TRACE поможет выяснить истинную причину. Вы можете и не знать всех SQL-операторов, выполняемых от вашего имени при обновлении материализованного представления, и то, какие таблицы они затрагивают . С помощью SQL TRACE можно легко установить, какая именно таблица или представление не существует, и изменить соответствующие права доступа.

Запись PARSE ERROR имеет следующий формат:

Поле Значение

len Длина SQL-оператора

dep Рекурсивная глубина SQL-оператора

5 7 2 Гл 10

Поле Значение

uid Схема, от имени которой выполнялся разбор (может отличаться от схемы, для которой определялись права доступа)

oct Тип команды Oracle

Jid Схема, с привилегиями которой фактически выполняется оператор

tim Таймер

err Код ошибки. Если выполнить следующую команду:

tkyte@TKYTE816> EXEC DBMS OUTPUT.PUT LINE (SQLERRM(-903) ) ; ORA-00903: invalid table name

то можно получить текст сообщения об ошибке.

Итак, в этом разделе достаточно глубоко рассмотрен набор ценнейших средств, работающих во всех средах и всегда доступн1х. Трассировка при установке SQL TRACE и результирующие отчеты, выдаваемые утилитой TKPROF - мощнейшие средства настройки и отладки. Я успешно использовал их для отладки и настройки огромного количества приложений. Их повсеместная доступность (нет ни одной СУБД Oracle, в которой эти средства отсутствуют) в сочетании с возможностями, делает их незаменимыми при настройке.

Зная, как трассировать приложение и интерпретировать результаты трассировки, можно считать, что настройка приложения наполовину завершена. Вторая половина - разобраться, например, почему запрос требует доступа к миллиону блоков или почему он пять минут ждет в очереди. Установка SQL TRACE позволит понять, что именно надо исправлять, а поиск причины проблем обычно сложнее, чем их устранение, особенно если детали реализации приложения неизвестны.

Пакет DBMS PROFILER

Те, кто интенсивно использует язык PL/SQL, с энтузиазмом отнесутся к добавлению в СУБД профилировщика исходного кода. В Oracle 8i полнофункциональный профилировщик исходного кода на языке PL/SQL интегрирован в базу данных. Этот пакет, именуемый DBMS PROFILER, позволяет определить, на какие подпрограммы и пакеты приходится наибольшая доля в общем времени выполнения. Более того, он позволяет анализировать охват кода, т.е. понять, сколько процентов кода приложения проверено в тесте.

Стратегии и средства настройки 5 7 3

В Приложении А я детально описываю использование пакета DBMS PROFILER и интерпретацию получающихся в результате отчетов и данных. Пакет очень легко использовать, и он отлично интегрирован в среду PL/SQL. По ходу работы хранимой процедуры на PL/SQL можно включать и отключать профилирование, сужая фрагмент настраиваемого кода.

При поэтапной настройке приложения я сначала с помощью SQLTRACE и утилиты TKPROF выявляю и исправляю плохо настроенные SQL-операторы. Если все SQL-операторы работают максимально быстро, но необходима дальнейшая настройка, я перехожу к профилированию исходного кода. За исключением действительно неудачных алгоритмов, основное повышение производительности достигается за счет настройки SQL-операторов. Настройка исходного кода PL/SQL дает обычно средние результаты: достаточные, чтобы этим стоило заниматься, но намного меньшие, чем исправление неудачных запросов. Конечно, если использован крайне неэффективный алгоритм, все обстоит иначе.

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

Средства контроля и отладки

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

В начале главы я рассказывал о недавно выполненной мною настройке. Архитектура приложения б1ла, мягко говоря, сложной. Пользовательский интерфейс в Web-браузере взаимодействовал с группой Web-серверов через весьма строгий брандмауэр. Web-серверы поддерживали страницы Java Server Pages (JSP). Эти страницы через пул подключений на сервере приложений взаимодействовали с базой данных, где выполнялся код SQL и PL/SQL. Кроме того, они с помощью CORBA обращались к еше одному серверу приложений для взаимодействия с существующей системой. Они были лишь составной частью большего приложения. В системе были еще пакетные задания, фоновые процессы, обработка очередей и другие готовые компоненты. Мне пришлось начинать, абсолютно ничего не зная о приложении, но что еще хуже, мало кто там вообще знал