Als PDF Downloaden!

Tipps & Tricks: Juli 2010
Bereich:
PL/SQL, DBA
Erstellung:
06/2010 HA
Versionsinfo:
10.2, 11.1
Letzte Überarbeitung:
06/2010 HA
Tracing mit DBMS_MONITOR
Tracing einer Session
In einem frü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 hier 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
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 1 von 4
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
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 2 von 4
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 *
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 3 von 4
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 4 von 4