Tracing mit DBMS_MONITOR

04.
Juli
2010
Veröffentlicht von: Hildegard Asenbauer

In einem<link http: www.muniqsoft.de tipps monatstipps jahr-2002 maerz-2002.htm internal-link> früheren Beitrag<link http: www.muniqsoft.de tipps monatstipps jahr-2002 maerz-2002.htm internal-link> wurde das Tracing einer Datenbank-Session bereits generell beschrieben, daher soll hier nicht näher auf die Grundlagen eingegangen werden. Neben den dort vorgestellten Methoden gibt es seit Version 10g noch das Package DBMS_MONITOR, das diverse Möglichkeiten zum Tracing bietet.

Tracing einer Session

In einem Leitet Herunterladen der Datei einfrüheren Beitrag wurde das Tracing einer Datenbank-Session bereits generell beschrieben, daher soll hier nicht näher auf die Grundlagen eingegangen werden. Neben den dort vorgestellten Methoden gibt es seit Version 10g noch das Package DBMS_MONITOR, das diverse Möglichkeiten zum Tracing bietet.

Analog zu den bekannten und Leitet Herunterladen der Datei einhier beschriebenen Möglichkeiten bietet auch DBMS_MONITOR eine Prozedur an, um anhand von SID und SERIAL# (aus v$session) für eine bestimmte Session Tracing zu aktivieren: SESSION_TRACE_ENABLE. Die ersten beiden Parameter (session_id und serial_num) identifizieren die Session, für die Tracing aktiviert werden soll. Werden sie weggelassen (bzw. wird NULL für sie übergeben), so ist die eigene Session gemeint. Der dritte (waits) und vierte (binds) Parameter legt fest, ob Informationen über Wartezustände bzw. Bind-Variablen gesammelt werden sollen (TRUE) oder nicht (FALSE).

-- eigene Session, Waits und Binds:
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(NULL, NULL, TRUE, TRUE)
-- fremde Session (SID = 128, serial# = 47), nur Waits:
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(128, 47, TRUE, FALSE)

Ob Tracing eingeschaltet ist, und wenn ja, wofür, ist in v$session in den Spalten sql_trace, sql_trace_waits und sql_trace_binds ersichtlich (manchmal aber erst, wenn diese Session aktiv wurde):

SELECT sql_trace, sql_trace_waits, sql_trace_binds
FROM v$session WHERE username = 'SCOTT';

SQL_TRAC SQL_T SQL_T
-------- ----- -----
ENABLED  TRUE  FALSE

Ausgeschaltet wird diese Art des Tracing mit SESSION_TRACE_DISABLE:

EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(NULL, NULL)
EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(128, 47)

So weit, so gut. Aber dafür braucht man doch kein neues Package? Richtig, aber DBMS_MONITOR bietet auch Möglichkeiten, die NICHT an die SID einer Session gebunden sind. Das Package ist vor allem dafür gedacht, 3-Tier-Applikationen zu tracen, bei denen keine durchgehende Session zwischen Endbenutzer und Datenbank besteht.

 

Tracing anhand eines Client Identifiers

Um dieses Feature nutzen zu können, muss ein Client Identifier gesetzt sein. Hier sind die Applikationsentwickler gefordert, einen entsprechenden Aufruf einzubauen, wenn eine Verbindung zu Datenbank hergestellt wird:

EXEC DBMS_SESSION.SET_IDENTIFIER('USER_1')

Dieser Identifier ist auch sichtbar in v$session. Die Spalte heisst client_identifier.

Anstelle der SID dient nun dieser Identifier als Identifikationsmerkmal, was mitprotokolliert werden soll. Tracing wird in diesem Fall eingeschaltet mit:

-- mit waits, ohne Binds:
EXEC DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('USER_1')
-- mit waits, mit Binds wäre:
-- EXEC DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('USER_1', TRUE, TRUE)

Diese Art von Tracing verhält sich in einigen Aspekten komplett anders als klassisches Session-Tracing:

  • Es ist sichtbar in DBA_ENABLED_TRACES:

SELECT primary_id,  waits, binds
  FROM DBA_ENABLED_TRACES
 WHERE trace_type = 'CLIENT_ID';

PRIMARY_ID WAITS BINDS
---------- ----- -----
USER_1     TRUE  FALSE

  • Es ist nicht an bestimmte Sessions gebunden; daher ist es auch NICHT sichtbar in den entsprechenden Spalten in v$session
  • Es bleibt auch bei einem Neustart der Datenbank aktiv(!). Es sollte daher auf keinen Fall vergessen werden, das Tracing wieder auszuschalten, wenn es nicht mehr nötig ist.

Ausgeschaltet wird es durch:

EXEC DBMS_MONITOR.CLIENT_ID_TRACE_DISABLE('USER_1')

Die dabei erzeugten Tracefiles können in bekannter Art mit TKPROF ausgewertet werden. Da es hier jedoch zu einem Identifier in der Regel mehrere Tracefiles gibt, ist eine Einzelauswertung mühsam. Vorteilhafter ist es, alle zugehörigen Tracefiles erst zusammenzuführen mit trcsess, einer ebenfalls mit 10g neu eingeführten Utility, und dann das Output-File zu analysieren:

trcsess output=user_1.txt clientid=USER_1 *

Der "*" bedeutet, es sollen alle Tracefiles einbezogen werden. trcsess unterstützt auch Tracefiles aus klassischem Session-Tracing. Eine Übersicht der Syntax erhalten Sie, wenn Sie trcsess  ohne Parameter aufrufen.

 

Tracing anhand von Module und Action

DBMS_MONITOR bietet als dritte Alternative die Möglichkeit, anhand von Service-Name, Module-Name und Action-Name Tracing einzuschalten. Wird kein Modulname mitgegeben, dann wird standardmäßig für alle Module Tracing aktiviert. Sofern nicht explizit eine bestimmte Instanz angegegben wird, gilt das Tracing für alle Instanzen, die über den angegbenen Service-Namen angesprochen werden. Auch diese Art von Tracing bleibt bei einem Neustart bestehen und muss explizit beendet werden.

Sowohl Module-Name als auch Action-Name können in einer Session über einen DBMS_APPLICATION_INFO-Aufruf gesetzt werden. Das Package ist dafür gedacht, innerhalb einer Applikation Informationen darüber zu liefern, was gerade passiert, z. B. mit welchem Formular (module) der Anwender gerade welche Aktivität (action) ausführt:

-- setzt module und action
EXEC DBMS_APPLICATION_INFO.SET_MODULE ( 'Modul_1', 'testen')
-- setzt nur action neu
EXEC DBMS_APPLICATION_INFO.SET_ACTION ('abrechnen')

Beides ist sowohl in v$session als auch in v$sqlarea sichtbar, die Spalten heissen module und action.

Wird beim Aufruf nur ein Service-Name mitgegeben, dann ist das Tracing für ALLE Module aktiviert (Default), wird für module_name NULL mitgegeben, dann gilt das Tracing für alle Sessions, bei denen kein module_name gesetzt wurde. Der Aufruf ist streng hierarchisch, das heisst, action_name wird nur im Zusammenhang mit module_name wirksam. Es wird nur protokolliert, wenn alle drei Eigenschaften übereinstimmen.

BEGIN
   DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'o10g',
                                          module_name  => 'Modul_1',
                                          action_name  => 'testen',
                                          waits        => FALSE,
                                          binds        => FALSE);
END;  
/

SELECT trace_type, primary_id, qualifier_id1, qualifier_id2, waits, binds
  FROM DBA_ENABLED_TRACES;

TRACE_TYPE            PRIMARY_ID QUALIFIER_ID1   QUALIFIER_ID2   WAITS BINDS
--------------------- ---------- --------------- --------------- ----- -----
SERVICE_MODULE_ACTION o10g       Modul_1         testen          FALSE FALSE

Das Tracing wird wieder ausgeschaltet durch die entprechende DISABLE-Methode:

BEGIN
   DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'o10g',
                                          module_name  => 'Modul_1',
                                          action_name  => 'testen');
END; 
/

Auch hier können Tracefiles über trcsess zusammengefasst werden.  Die entscheidenden Parameter lauten in diesem Fall service, module und action:

trcsess output=modul.txt service=o10g module=Modul_1 action=testen *

DBA PL/SQL Trace File

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.