DeepEdit!

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

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

Знакомство с приложением

накомство с приложением


Как известно из главы 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)
В многопоточной конфигурации несколько клиентских процессов совместно пользуются меньшим числом серверных процессов Ora­cle. Такая конфигурация сокращает количество процессов, необходимых для обслуживания приложения, для которого характерно большое количество подключенных пользователей, в основном на­ходящихся в состоянии ожидания.
Пул соединений
В конфигурации с пулом соединений единственный процесс опера­ционной системы (называемый службой) на промежуточном узле создает единственное соединение с Oracle и поддерживает единст­венный сеанс с единственным серверным процессом Oracle. Эта служба затем от имени множества пользователей выполняет вызо­вы к базе данных в рамках собственного единственного сеанса. Мас­штабируемость такой конфигурации для большого количества пользователей лучше, чем у многопоточного сервера.
Мы с коллегами в своей практике встречались с умопомрачительными комбинациями этих и других технологий, особенно в таких системах, где отдельная пользовательская операция обращается к службам, рас­пределенным по нескольким базам данных. Как уже говорилось, сейчас самой сложной частью методов диагностики обычно становится сбор диагностических данных в корректно определенной области. Хо­рошо то, что как только найден способ сделать это для данной архитек­туры, дальнейший сбор данных для нее заметно упрощается. Кроме того, я полагаю, что архитектурные изменения, планируемые в Oracle версии 10, упростят процесс получения корректно выбранных данных по отдельной пользовательской операции.
Ключ к успешному сбору данных расширенной трассировки SQL в том, чтобы понять, как идентифицировать нужные сеансы Oracle. А для архитектур с пулом соединений - в правильной идентификации вызовов БД и событий ожидания, относящихся к диагностируемой пользовательской операции.

 









jAntivirus