За чим слідкувати і чим керувати при роботі додатків з Oracle, Інші СУБД, Бази даних, статті

Володимир Пржиялковского, викладач технологій Oracle













… Паллада Афіна,

За руку взявши, вигукнула до бурхливого богу Арею:

“… Не кинемо ми і троян і ахеян

Сперечатися одних, та Кронід Промислитель їх славу присудить? … “

Гомер, Іліада

 

Одним з лих часу був застарілий свавілля донощиків та їх підбурювачів.

Светоній, Життя дванадцяти цезарів: Божественний Тит



Виборче стеження за виконанням запитів SQL і завантаженням СУБД засобами пакета DBMS_MONITOR


Давнє засіб Oracle SQL Trace дозволяє фіксувати “профіль запитів SQL”, що видаються серверними процесами, що обслуговують сеанси зв’язку з СУБД, і представляє з себе корисний інструмент для виявлення проблемних запитів і аналізу завантаження СУБД додатками. До версії 10 воно могло включатися і виключатися тільки для конкретних сеансів зв’язку з СУБД. Це не завжди зручно, оскільки в житті більш насущні профілювання і налагодження програми, або навіть його фрагментів, а між додатком і сеансом найчастіше немає взаимнооднозначное зв’язку.


Новий для версії 10 пакет DBMS_MONITOR розширив раніше що була можливість профілювання SQL-дій сеансу (свого або чужого) стеженням за діями окремих програм і їх частин. Для цього використовується модель “служба БД” – “модуль” – “дія”. Між цими поняттями немає формальної залежності, але методично пропонується зіставляти “службі БД” групу логічно пов’язаних сеансів, “модулю” – додаток, працює з даними, а “дії” – епізод роботи додатку. Точніше, засобами пакета можна відстежувати видачу запитів SQL з точністю до наступних одиниць:



Перегляд і установка одиниць спостереження розглядаються нижче.


До того ж пакет DBMS_MONITOR дозволяє збирати узагальнену статистику виконуваних сеансами або додатками запитів.


Одиниці спостереження


У той час як стеження за діями сеансу (свого або чужого) і всіх сеансів примірника СУБД не викликає питань, решта одиниці спостереження можуть вимагати пояснення.


Поняття служба БД (SERVICE) формувалося в Oracle починаючи з версії 8, і до теперішнього часу використовується для логічного групування сеансів з метою як раз-таки мати узагальнену одиницю спостереження та управління при використанні загальної БД різними додатками. Наприклад, сеанси однієї і тієї ж служби БД можуть бути присутніми одночасно на різних вузлах кластера в конфігурації RAC, а в рамках однієї і тієї ж СУБД можуть одночасно виконуватися сеанси різних служб. Службу пропонується пов’язувати з набором додатків, об’єднаних загальними властивостями, пороговими характеристиками або правилами споживання ресурсів СУБД.


Поняття модуль (MODULE) використовується для позначення періоду роботи конкретного додатка протягом сеансу, а поняття дії (ACTION) – конкретного фрагмента програми, тобто епізоду видачі додатком певній послідовності команд SQL.


Призначення опізнавач клієнта (CLIENT IDENTIFIER) – мітити сеанси, наприклад встановлені за схемою використання загальних серверних процесів (shared server), або сеанси кінцевих користувачів при роботі через сервер додатків (наприклад, додатків для web).


Установка одиниць стеження і перегляд існуючих значень


Згадані значення одиниць стеження за роботою програми наблюдаеми в програмі або з полів таблиць словника-довідника, або з вбудованого контексту сеансу з ім’ям USERENV:





































Значення


Поле таблиць


Параметр контексту USERENV сеансу


SERVICE_NAME


V$SESSION, V$SERVICES


SERVICE_NAME


MODULE


V$SESSION


MODULE


ACTION


V$SESSION


ACTION


CLIENT_IDENTIFIER


V$SESSION


CLIENT_IDENTIFIER


SID


V$SESSION


SID


SERIAL#


V$SESSION



INSTANCE_NAME


V$INSTANCE


INSTANCE_NAME


Наприклад, усі значення, крім SERIAL #, наблюдаеми у відповідних параметрах контексту USERENV сеансу зв’язку клієнтської програми з СУБД.


Для подальшого перегляду цих параметрів в SQL * Plus зручно підготувати файл з параметризованих зверненням до контексту USERENV допомогою системної функції SYS_CONTEXT:


SELECT SYS_CONTEXT ( “userenv”, “&1” ) AS &1 FROM dual.


SAVE userenv REPLACE


SET VERIFY OFF


Приклад установки та перегляду SERVICE_NAME


Значення SERVICE_NAME виставляється автоматично при встановленні з’єднання, а управління службами відбувається за допомогою пакета DBMS_SERVICE.CREATE_SERVICE.


Прості приклади створення, включення, підключення, відключення і видалення:


EXECUTE DBMS_SERVICE.CREATE_SERVICE ( “secunda”, “secunda.class” )


EXECUTE DBMS_SERVICE.START_SERVICE  ( “secunda” )


CONNECT /@localhost:1521/secunda.class AS SYSDBA


EXECUTE DBMS_SERVICE.STOP_SERVICE   ( “secunda” )


EXECUTE DBMS_SERVICE.DELETE_SERVICE ( “secunda” )


Ще один спосіб створення служб – через командний інтерфейс за допомогою програми srvctl.


Можливі значення SERVICE_NAME вказуються в мережевих установках Oracle і реєструються в якості служби БД процесом listener. Значення зареєстрованих в рамках БД служб можна спостерігати в таблиці V $ SERVICES. Крім сконфігурованих, завжди є дві внутрішні служби: SYS $ BACKGROUND використовується внутрішніми процесами СУБД, а до SYS $ USERS зараховуються з’єднання користувачів, не вказали бажану їм службу.


Приклад перегляду:


SQL> CONNECT scott/tiger@prima.class


Connected.


SQL> @userenv SERVICE_NAME


SERVICE_NAME


——————————————————————–


prima.class


Вправа. Переглянути список служб, зареєстрованих для робочої БД. Пояснити наявність служб SYS $ USERS і SYS $ BACKGROUND.


Приклад установки та перегляду MODULE і ACTION


Значення MODULE і ACTION встановлюються в програмі за допомогою пакета DBMS_APPLICATION_INFO. Приклад:


SQL> EXECUTE DBMS_APPLICATION_INFO.SET_MODULE


 2    ( “some module”, “some action” )


PL/SQL procedure successfully completed.


SQL> @userenv MODULE


MODULE


——————————————————————–


some module


SQL> @userenv ACTION


ACTION


——————————————————————–


some action


SQL> EXECUTE DBMS_APPLICATION_INFO.SET_ACTION ( “” )


PL/SQL procedure successfully completed.


SCOTT> /


ACTION


———————————————————————


SQL>


Приклад установки та перегляду CLIENT_IDENTIFIER


Значення CLIENT_IDENTIFIER виставляється програмно за допомогою пакета DBMS_SESSION або ж викликом OCI setClientIdentifier (тільки JDBC у версії 9). Приклад:


SQL> @userenv CLIENT_IDENTIFIER


CLIENT_IDENTIFIER


———————————————————————


SQL> EXECUTE DBMS_SESSION.SET_IDENTIFIER ( “Web client” )


 PL/SQL procedure successfully completed.


/


CLIENT_IDENTIFIER


——————————————————————-


Web client


Приклад відстеження запитів SQL з боку програми та його елементів


Процедура SERV_MOD_ACT_TRACE_ENABLE пакета DBMS_MONITOR дозволяє стежити за видачею запитів SQL окремими “додатками”, “модулями” в складі додатків і “діями” в рамках модулів. Приклад:


DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE (


  service_name  => “prima.class”


, module_name   => “SQL*Plus”


, action_name   => DBMS_MONITOR.ALL_ACTIONS


, waits         => TRUE


, binds         => TRUE


, instance_name => NULL


);


/*


* … вичікуємо, поки триває робота


 */


DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE (


  service_name  => “prima.class”


, module_name   => “SQL*Plus”


, action_name   => DBMS_MONITOR.ALL_ACTIONS


, instance_name => NULL


);


Для параметра MODULE_NAME по аналогії можна вказати ALL_MODULES.


Таким же чином включається трасування запитів, що надходять з поточного або чужого сеансів (SESSION_TRACE_ENABLE / DISABLE), сеансів, помічених CLIENT_IDENTIFIER (CLIENT_ID_TRACE_ENABLE / DISABLE) і з всіх сеансів підряд, або ж породжуваних певним примірником СУБД, наприклад з конфігурації RAC (DATABASE_TRACE_ENABLE / DISABLE).


Перегляд профілю видачі запитів SQL виконується за допомогою програм tkprof і trcsess. Остання програма стала поставлятися в ПО версії Oracle 10 і як раз-таки і вибирає з трасувань файлів різних процесів дані, пов’язані з зазначеним одиницям стеження. Ось приклад, як може виглядати спільне використання цих програм:


>trcsess output=out.txt module=SQL*Plus c:oracleadminprimaudump*


>tkprof out.txt final.txt


Вправа. Включити трасування всіх запитів SQL, що надходять від сеансів SQL * Plus, і спостерігати накопичення профілю видачі запитів. Відключити трасування.


Приклад збору статистики про запити SQL в додатку


Для сеансів, помічених CLIENT_IDENTIFIER, і для додатків, позначених комбінаціями SERVICE_NAME – MODULE – ACTION, пакет DBMS_MONITOR дозволяє не тільки збирати профіль видачі запитів SQL, а й статистику витрат СУБД на обробку запитів.


Приклад зі збором статистики про роботу певних клієнтів. Видамо:


CONNECT / as sysdba


EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_ENABLE ( “Web client” )


HOST sqlplus scott/tiger


EXECUTE DBMS_SESSION.SET_IDENTIFIER ( “Web client” )


SELECT COUNT ( * ) FROM dual;


EXIT


Тут за допомогою команди HOST програми SQL * Plus був здійснений короткий запуск сеансу, позначеного значенням CLIENT_IDENTIFIER = “Web client”.


Продовжимо в первісному сеансі від імені SYS:


SYS> SELECT aggregation_type, primary_id


2> FROM dba_enabled_aggregations;


AGGREGATION_TYPE      PRIMARY_ID


——————— ——————————————–


CLIENT_ID             Web client


SYS> COLUMN client_identifier FORMAT A20


SYS> COLUMN stat_name         FORMAT A35


SYS> COLUMN value             FORMAT 99999999


SYS> SELECT client_identifier, stat_name, value


  2> FROM v$client_stats


  3> ;


CLIENT_IDENTIFIER    STAT_NAME                               VALUE


——————– ———————————– ———


Web client           user calls                                  4


Web client           DB time                                  3807


Web client           DB CPU                                   3807


Web client           parse count (total)                         2


Web client           parse time elapsed                        421


Web client           execute count                               4


Web client           sql execute elapsed time                 1940


Web client           opened cursors cumulative                   2



SYS> EXECUTE DBMS_MONITOR.CLIENT_ID_STAT_DISABLE ( “Web client” )


PL/SQL procedure successfully completed.


Ось перелік системних таблиці, що дозволяють контролювати збір статистики і спостерігати результати:


DBA_ENABLED_AGGREGATIONS


V$CLIENT_STATS


V$SERVICE_STATS


V$SERV_MOD_ACT_STATS


V$SERVICEMETRIC


V$SERVICEMETRIC_HISTORY


Останні дві дають детальну інформацію про витрачання процесорного часу.


Це був приклад з використанням процедур CLIENT_ID_STAT_ENABLE / DISABLE. Процедури SERV_MOD_ACT_STAT_ENABLE / DISABLE використовуються аналогічно.


Вправа. Включити збір узагальненої статистики виконання запитів SQL всіх з’єднань до СУБД по SQL * Plus і спостерігати її накопичення. Відключити збір статистики.


Не тільки стеження і не тільки з програми


З вказаних вище одиниць спостереження найбільш розробленою є служба. Вона не тільки дозволяє стежити за діями додатків, але і є одиницею управління. Ось приклад можливостей її вживання в цій якості на даний момент:


– У планувальнику завдань зі службою можна пов’язати конкретний клас завдань (пакет DBMS_SCHEDULER, процедура CREATE_JOB_CLASS).


– Розмови, що здійснюються в рамках служби, можна вказати у визначенні групи споживачів ресурсів СУБД при роботі з розподільником (диспетчером) ресурсів (пакет DBMS_RESOURCE_MANAGER, процедура SET_CONSUMER_GROUP_MAPPING). 


– У системі попереджувальної сигналізації саме для конкретної служби можна встановлювати порогові значення для загального часу (ELAPSED_TIME_PER_CALL) і процесорного часу (CPU_TIME_PER_CALL) обробки запитів SQL, про перевищення яких СУБД буде доповідати автоматично (пакет DBMS_SERVER_ALERT, процедура SET_THRESHOLD).


– Процедура DISCONNECT_SESSION з пакету DBMS_SERVICE зупиняє всі сеанси необхідної служби.


Згадані пакети DBMS_SCHEDULER, DBMS_SERVER_ALERT і DBMS_SERVICE, а також процедура SET_CONSUMER_GROUP_MAPPING старого пакета DBMS_RESOURCE_MANAGER з’явилися у версії 10.


Крім того, всі реалізовані програмно можливості стеження і управління широко представлені відповідними web-сторінками OEM.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*