накомство с приложением
Как известно из главы 3, необходима возможность трассировки операций, выполняемых строго определенным пользователем или пакетным заданием на строго определенном временном интервале. Ниже в этой главе показано, что ядро Oracle версий 7, 8 и 9 позволяет управлять расширенной трассировкой SQL только на уровне сеансов Oracle. В зависимости от архитектуры приложения возможность управлять трассировкой лишь на уровне сеанса может создать серьезные трудности для процесса сбора диагностических данных. Поэтому, к сожалению, прежде чем приступать к трассировке приложения, надо понять его архитектуру.
Получение диагностических данных в корректно определенной области представляет собой наиболее сложную часть задачи диагностики производительности приложений, работающих с Oracle версий 7, 8 и 9. Как только такие данные получены, дальнейшие шаги не вызывают затруднений.
Для начала определим некоторые понятия. Пользовательская операция - это функционально законченная часть работы, выполняемой некоторым человеком. Именно пользовательская операция представляет интерес с точки зрения производительности для пользователя (а значит, и для вас тоже). Такая операция может требовать выполнения кода на любых (в том числе и на всех) узлах многозвенной архитектуры -таких как броузер клиента, сервер приложений, сервер БД и различные сетевые устройства.
В центре внимания этой книги находится узел сервера базы данных, т. к. именно он обладает инструментальными средствами, позволяющими наиболее эффективно диагностировать большинство проблем производительности. Пользовательская операция может затрагивать несколько процессов (или даже потоков) сервера базы данных, а может не затрагивать ни одного. Процессом называется объект операционной системы, представляющий собой экземпляр некой исполняемой программы. Процесс идентифицируется присвоенным ему операционной системой уникальным идентификатором (PID), управление процессами осуществляется средствами ОС. Например, приведенная команда Linux ps (вывести состояние процессов) показывает четыре процесса (8233, 8325, 8326 и 8327), созданные тремя различными программами (ksh, ps и двумя копиями t):
Нас в первую очередь будут интересовать два типа процессов ОС на сервере базы данных. Первый и самый главный из них - это серверный процесс Oracle, отвечающий за совместное использование памяти, доступ к файлам базы данных и выполняющий основную работу в большинстве систем, основанных на Oracle. Имена таких процессов обычно содержат подстроку «oracle». Показанная ниже команда Linux выводит список всех процессов, содержащих в таблице процессов подстроку «oracle» и не содержащих «grep»:
$ ps -ef
|
1 grep
|
oracle |
|
grep
|
-v grep
|
|||
oracle
|
756
|
1
|
0
|
Feb04
|
?
|
00:00:19
|
ora_pmon_V816
|
oracle
|
758
|
1
|
0
|
Feb04
|
?
|
00:00:04
|
ora_dbw0_V816
|
oracle
|
760
|
1
|
0
|
Feb04
|
?
|
00:00:03
|
ora_lgwr_V816
|
oracle
|
762
|
1
|
0
|
Feb04
|
?
|
00:00:43
|
ora_ckpt_V816
|
oracle
|
764
|
1
|
0
|
Feb04
|
?
|
00:00:01
|
ora_smon_V816
|
oracle
|
766
|
1
|
0
|
Feb04
|
?
|
00:00:00
|
ora_reco_V816
|
oracle
|
8834
|
8833
|
0
|
16:12
|
?
|
00:00:00
|
oracleV816 (DESCRIPTION=(LO
|
oracle
|
8859
|
8858
|
0
|
16:13
|
?
|
00:00:00
|
oracleV816 (DESCRIPTION=(LO
|
Обратите внимание, что эта команда вывела также данные обо всех фоновых процессах Oracle в моей системе (т. к. их владельцем является пользователь oracle).
Серверные процессы могут называться по-разному, в частности: Серверные процессы Теневые процессы Процессы ядра Процессы переднего плана
Второй интересный тип процессов, выполняемых на сервере, - это клиентские процессы, устанавливающие соединения с базой данных. Например, такие программы, как отчеты или пакетная загрузка, интенсивно обращающиеся к базе данных, часто запускают непосредственно на сервере БД. Такой способ хорошо подходит для любой клиентской программы, большая часть времени выполнения которой проходит в ожидании ответов на запросы к базе данных. В таком случае расходы на выполнение клиентской программы на сервере многократно окупаются уменьшением нагрузки на сеть, избавленную от массовой пересылки по SQL*Net сообщений между клиентом и серверными процессами oracle.
В качестве примеров клиентских программ Oracle можно привести: sqlplus (SQL*Plus) f60run (Oracle*Forms)
FNDLIBR (программа Oracle Financials Concurrent Manager)
PYUGEN (программа Oracle Human Resouces)
Сеанс Oracle (или, далее в этой книге, просто сеанс) представляет собой конкретную последовательность обращений к базе данных, передаваемых через соединение между клиентским процессом и экземпляром Oracle. Сеанс имеет уникальный идентификатор, образованный
сочетанием значений V$SESSION.SID и V$SESSION.SERIAL#. Например, следующая команда SQL*Plus выводит данные о девяти сеансах Oracle:
9 rows selected.
Сбор данных не вызывает затруднений, если в пользовательской операции участвует только один клиентский процесс, один серверный процесс Oracle и один сеанс Oracle. К счастью, такая ситуация довольно часто встречается в случае таких проблем с производительностью, как долго выполняющиеся отчеты и пакетные задания. Сложность сбора данных возрастает, если пользовательская операция задействует несколько процессов или сеансов Oracle. Например:
Многопоточный сервер Oracle (MTS)
В многопоточной конфигурации несколько клиентских процессов совместно пользуются меньшим числом серверных процессов Oracle. Такая конфигурация сокращает количество процессов, необходимых для обслуживания приложения, для которого характерно большое количество подключенных пользователей, в основном находящихся в состоянии ожидания.
Пул соединений
В конфигурации с пулом соединений единственный процесс операционной системы (называемый службой) на промежуточном узле создает единственное соединение с Oracle и поддерживает единственный сеанс с единственным серверным процессом Oracle. Эта служба затем от имени множества пользователей выполняет вызовы к базе данных в рамках собственного единственного сеанса. Масштабируемость такой конфигурации для большого количества пользователей лучше, чем у многопоточного сервера.
Мы с коллегами в своей практике встречались с умопомрачительными комбинациями этих и других технологий, особенно в таких системах, где отдельная пользовательская операция обращается к службам, распределенным по нескольким базам данных. Как уже говорилось, сейчас самой сложной частью методов диагностики обычно становится сбор диагностических данных в корректно определенной области. Хорошо то, что как только найден способ сделать это для данной архитектуры, дальнейший сбор данных для нее заметно упрощается. Кроме того, я полагаю, что архитектурные изменения, планируемые в Oracle версии 10, упростят процесс получения корректно выбранных данных по отдельной пользовательской операции.
Ключ к успешному сбору данных расширенной трассировки SQL в том, чтобы понять, как идентифицировать нужные сеансы Oracle. А для архитектур с пулом соединений - в правильной идентификации вызовов БД и событий ожидания, относящихся к диагностируемой пользовательской операции.
< Предыдущая | Следующая > |
---|