DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Работа с событиями SQL*Net, заметно влияющими на время отклика


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

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

Вероятнее всего, в профиле ресурсов будут преобладать длительности таких событий SQL*Net:
SQL*Net message from client
Средство от этого недуга заключается в удалении максимального ко­личества ненужных вызовов базы данных. Например, удаление из­лишних вызовов разбора (подробная информация приведена в разде­ле «Оптимизация разбора»). Обратитесь к возможностям обработки массивов 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 Applica­tion Clusters), когда ему необходим доступ к буферу базы данных, удер­живаемому другим экземпляром RAC. Как освободиться от выполне­ния запросов к глобальному кэшу? Требовать меньшего количества бу­феров от другого экземпляра или меньше обращаться к буферам вооб­ще (см. далее раздел «Оптимизация логического ввода/вывода»).
Даже если вы никогда не слышали о подобном событии, и его имя ни о чем вам не говорит, метод R помогает найти решение. В начале гла­вы я уже ссылался на ряд бесплатных источников информации в Ин­тернете. И даже в худшем из случаев, который только можно себе представить, все не так плохо. Если вся глобальная сеть не в силах вам помочь, звоните в службу поддержки корпорации Oracle:
Звонок в службу поддержки (метод R не применяется): Моя система рабо­тает медленно. Мы в отчаянии и не понимаем, почему все так плохо. Как нам решить проблему?
Ответ, конечно, зависит от того, кто из аналитиков вам ответит, но будьте готовы к тому, что ничего конкретного не узнаете. Если же об­ратиться к методу R, то вопрос в службу поддержки можно сформули­ровать гораздо точнее:
Звонок в службу поддержки (с применением метода R): Время отклика са­мой важной пользовательской операции в моей системе составляет 75,32 се­кунды. Больше 73 секунд из этого времени тратятся на выполнение собы­тия под названием resmgr:waiting in check2. Не подскажете ли, во-первых, какая операция моего приложения приводит к выполнению данного фраг­мента кода ядра Oracle? И, во-вторых, что можно сделать для того, чтобы выполнять его реже?
Это надо выучить наизусть: выяснить, почему событие было выполне­но; выяснить, как избежать этого в следующий раз. Такой подход дей­ствительно эффективен.

 









jAntivirus