Сделанные наблюдения помогают понять, как следует работать с профилем ресурсов, в котором преобладают длительности событий между вызовами базы данных. Если профиль ресурсов состоит в основном из событий, происходящих между вызовами базы данных, необходимо сделать следующее:
1. Убедиться в том, что продолжительность события между вызовами действительно является составляющей какого-то времени отклика.
Если это не так, то следует исправить ошибку сбора данных и построить новый профиль ресурсов.
Если вклад события между вызовами в значение времени отклика велик из-за наличия нескольких больших задержек между вызовами, то следует проверить, почему приложение провело так много времени между вызовами.
Если же вклад события между вызовами в значение времени отклика велик из-за большого количества вызовов события, то следует проверить, зачем приложение выполняет так много различных вызовов базы данных.
Если не удается уменьшить количество различных вызовов базы данных, то следует проверить, можно ли уменьшить среднюю продолжительность отдельного события ожидания. Например, избавиться от ненужных вызовов базы данных других процессов, которые могут приводить к образованию очередей к сетевым ресурсам.
Заметьте, что эта последовательность шагов полностью совпадает с процедурой, описанной в главе 5. Сначала избавляемся от ненужных вызовов, а затем от ненужной конкуренции между процессами.
Средство от этого недуга заключается в удалении максимального количества ненужных вызовов базы данных. Например, удаление излишних вызовов разбора (подробная информация приведена в разделе «Оптимизация разбора»). Обратитесь к возможностям обработки массивов Oracle, позволяющим в одном вызове работать с множеством строк, а не с одной.1
SQL*Net more data from client
Если вы в своих приложениях передаете в вызовы разбора огромные текстовые строки SQL, прекратите это делать. Вызывайте из приложения хранимые процедуры. Однако если большие массивы значений отправляются для связывания в заполнители («переменные связывания»), то, возможно, не удастся сократить время ожидания данного события без создания новых, более серьезных трудностей.
SQL*Net message from dblink
Подумайте о возможности локальной репликации данных вместо удаленной работы по каналу базы данных. Репликация может быть
Этот же совет может быть полезен и для избавления от событий single-task message. Событие single-task message не является событием SQL*Net, но оно используется в однозадачной конфигурации аналогично событию SQL*Net
message from client в двузадачных конфигурациях.
весьма эффективной, особенно для таблиц, которые изменяются очень редко или для которых использование слегка устаревших данных создает лишь незначительное неудобство. Если переработать план выполнения команды SQL так, чтобы между экземплярами передавалось меньше данных, то можно сократить потребность в выполнении подобных событий.
Для оценки количества пересылок по сети, генерируемых приложением, можно подсчитать количество выполнений событий, имя которых включает в себя строку SQL*Net. Исследование значений ela для таких событий позволит ответить на вопрос о том, значителен ли вклад сетевых задержек в общее время отклика.
Иногда вам приходится сталкиваться с чрезмерно большим вкладом во время отклика со стороны события, о существовании которого вы раньше даже не подозревали. Существует множество событий ожидания, на которых я не буду здесь подробно останавливаться. Однако в любом случае метод решения задачи не меняется, даже если главная проблема производительности вызвана чем-то, о чем вы ничего не знаете. Последовательность шагов вам уже знакома:
Определяем, какое событие потребляет большую часть времени отклика пользовательской операции.
Определяем, какая операция приводит к столь частому выполнению события.
Делаем так, чтобы приложение реже выполняло данную операцию.
Выполнение первого шага подробно описано в этой книге. Шаги 2 и 3 не представляют особых трудностей. Значение событий обычно отражается в их названиях. Например, события PX генерируются фрагментами кода, отвечающими за параллельное выполнение Oracle (parallel execution). Если вы знаете, как реализуется параллельное выполнение, вам будет понятен смысл событий PX: главный сеанс поручает работу подчиненным сеансам и ожидает результатов. Большую часть работы выполняют подчиненные. Рассмотрим еще один пример: событие запроса к глобальному кэшу global cache cr request - это то, что выдает процесс ядра Oracle, поддерживающий технологию RAC (Real Application Clusters), когда ему необходим доступ к буферу базы данных, удерживаемому другим экземпляром RAC. Как освободиться от выполнения запросов к глобальному кэшу? Требовать меньшего количества буферов от другого экземпляра или меньше обращаться к буферам вообще (см. далее раздел «Оптимизация логического ввода/вывода»).
Даже если вы никогда не слышали о подобном событии, и его имя ни о чем вам не говорит, метод R помогает найти решение. В начале главы я уже ссылался на ряд бесплатных источников информации в Интернете. И даже в худшем из случаев, который только можно себе представить, все не так плохо. Если вся глобальная сеть не в силах вам помочь, звоните в службу поддержки корпорации Oracle:
Звонок в службу поддержки (метод R не применяется): Моя система работает медленно. Мы в отчаянии и не понимаем, почему все так плохо. Как нам решить проблему?
Ответ, конечно, зависит от того, кто из аналитиков вам ответит, но будьте готовы к тому, что ничего конкретного не узнаете. Если же обратиться к методу R, то вопрос в службу поддержки можно сформулировать гораздо точнее:
Звонок в службу поддержки (с применением метода R): Время отклика самой важной пользовательской операции в моей системе составляет 75,32 секунды. Больше 73 секунд из этого времени тратятся на выполнение события под названием resmgr:waiting in check2. Не подскажете ли, во-первых, какая операция моего приложения приводит к выполнению данного фрагмента кода ядра Oracle? И, во-вторых, что можно сделать для того, чтобы выполнять его реже?
Это надо выучить наизусть: выяснить, почему событие было выполнено; выяснить, как избежать этого в следующий раз. Такой подход действительно эффективен.
< Предыдущая | Следующая > |
---|