Home ORDIX AG             Dienstleistung             Trainingsshop    Kunden / Referenzen Aktuelles    Kontakt
Home  Pfeil  ORDIX News  Pfeil  1/2006
suche: 
Dieser Artikel richtet sich vor allem an erfahrene Oracle- Datenbankadministratoren, die in der Lage sind, Tracefiles zu erzeugen und interpretieren.

Glossar

Multi Threading Service (MTS)
Mehrere Clients teilen sich einen Datenbankprozess.
Wait Event
Wartezustand innerhalb der Datenbank.
Bind-Variable
Variabel gehaltener Teil eines SQLBefehls.
Service_Name
Logischer Name, unter dem der Client die Instanz erreicht.
Tnsnames.ora
Datei, in der der Client den Zugriff über Oracle*Net definiert.
Init.ora
Parameterdatei der Instanz und Datenbank.

Oracle 10g New Features − Teil VII

Session Tracing

Wer kennt es nicht! Der Buchhalter Müller beschwert sich, dass die "Datenbank" bei ihm so langsam läuft. Bei seinem Nachbarn Meier würde alles sehr schnell gehen. Sie machen daraufhin Performance-Messungen, stellen aber keine globalen Probleme fest. Also muss mitgeschnitten werden, was Müller genau macht, um detaillierte Aussagen treffen zu können.

 
Möglichkeiten eines Connects
Abb. 1: Schematische Darstellung der Möglichkeiten eines Connects an die Datenbank.
 
read_client_info Auslesen der Client-Informationen
read_module Auslesen des Modulnamens und der Aktion
set_action Definition einer Aktion im aktuellen Modul
set_client_info Setzen einer zusätzlichen Client-Information
set_module Definition eines Modulnamens
set_session_longops Informationen in die v$session_longops View laden
Abb. 2: Die sechs Prozeduren des Packages dbms_application_info.
 
DBMS_APPLICATION_INFO.SET_MODULE (
        module_name IN VARCHAR2, action_name
        IN VARCHAR2);
DBMS_APPLICATION_INFO.SET_ACTION (
        action_name IN VARCHAR2);
Abb. 3: Beispielaufrufe für dbms_application_info.
 
begin
dbms_application_info.set_module ('REIMERS','STEP1');
end;

select sid, serial#, module, action
from v$session where module is not null;

SID SERIAL# MODULE ACTION
--- ------- ------- ------
158 232 REIMERS STEP1
Abb. 4: Info aus v$session nach Initialisierung über dbms_application_info.


Client/Server-Technologien

Die gute, alte Client/Server-Welt gibt es heute kaum noch. Die Anwender greifen häufig über einen Terminal Server oder einen Application Server auf die Datenbank zu (siehe Abbildung 1).

Der Administrator kann deshalb nicht mehr erkennen, welcher Prozess oder welche Statements auf der Datenbank von welchem Anwender initiiert wurden.

Der Client ist aus Sicht der Datenbank der Application Server oder der Terminal Server und nicht mehr der Anwender. Eine ähnliche Problematik stellt sich bei Verwendung der Multi- Threading Architektur (MTS).

Was muss der Entwickler im Vorfeld leisten?

Das Package dbms_application_info steht schon seit Oracle 8 zur Verfügung, wird aber leider von den Entwicklern selten genutzt.

Wir möchten hier darstellen, warum die Verwendung dieser Funktionalität sehr wichtig sein kann und wie man dieses Paket sinnvoll verwendet.

Das Package dbms_application_info besteht aus 6 Prozeduren, die in Abbildung 2 kurz aufgeführt werden.

Wichtig für das Session Tracing sind die Prozeduren set_module und set_action (siehe Abbildung 3).

Der Entwickler sollte bei jedem Aufruf eines Moduls zunächst dbms_application_info. set_module aufrufen. Innerhalb eines Moduls können Teilsteps über dbms_application_ info.set_action definiert werden (siehe Abbildung 4).

Was haben wir nun davon?

Grundsätzlich kann der Administrator so relativ schnell erkennen, in welchem Modul sich der Anwender gerade befindet und braucht nicht aufwendig in vielen Sourcen nach dem Statement zu suchen.

Wie habe ich bisher Session Tracing angestoßen?

Das Mitschneiden einer Session konnte schon immer auf verschiedene Weise vollzogen werden (siehe Abbildung 5).

sql_trace=true in der init.ora Alle Sessions mittracen
alter session set sql_trace=true; Die eigene Session mittracen
alter session set events '10046 trace name context forever, level 8'; Die eigene Session mitschneiden, dabei zusätzlich Wait-Events und Bind-Variable mit ausgeben
Exec dbms_system.set_sql_trace_in_session (17,255,true); Vor Oracle 10g: Eine fremde Session, hier z. B. die Session mit SID=17 und Serial#=255 mittracen
exec dbms_session_trace_enable(17, 255, true, true); Neu in Oracle 10g: Eine fremde Session, hier z. B. die Session mit SID=17 und Serial#=255 mittracen
exec dbms_monitor.serv_mod_act_trace_disable ('PPS', 'REIMERS', 'STEP1'); Das spezifische Tracing wieder ausschalten
Abb. 5: Möglichkeiten, Session Tracing ein- und auszuschalten.

Das Package dbms_monitor

In Oracle 10g gibt es nun das neue Package dbms_monitor, über das das Session Tracing neu strukturiert wird. Dieses Package enthält neben vielen anderen Prozeduren folgende für uns hier relevante Funktionalitäten:

Einfaches Session Tracing mit dbms_monitor

Um eine fremde Session mitzuschneiden, gibt es in Oracle 10g nun dbms_session_trace_enable.

Diese Vorgehensweise entspricht dem alten, schon lange nicht mehr dokumentierten Package dbms_system (siehe Abbildung 5).

Die Parameter der Prozedur session_trace_ enable haben die in Abbildung 6 genannte Bedeutung.

SID System Identifier, Information aus v$session (im Beispiel "17", Abb. 5)
Serial# Information aus v$session (im Beispiel "255", Abb. 5)
Wait Events true/false – Tracing mit oder ohne Wait Events (im Beispiel "true", Abb. 5)
Bind Variable true/false – Tracing mit oder ohne Bind Variable (im Beispiel "true", Abb. 5)
Abb. 6: Parameter der Prozedur session_trace_enable.

Ein Tracing einer fremden Session ist nun syntaktisch einfacher geworden, der Event 10046 muss nicht eingebaut werden.

Session Tracing mit dbms_monitor im Application Server Umfeld

Wie eingangs bereits dargestellt, war das Mitschneiden von Benutzeraktionen im Application Server Umfeld bisher nahezu unmöglich. Hier bringt dbms_monitor nun die entscheidende Abhilfe.

Die Parameter der Prozedur serv_mod_act_ trace_enable haben die in Abbildung 7 genannte Bedeutung.

exec dbms_monitor.serv_mod_act_trace_enable ('PPS', 'REIMERS', 'STEP1', true, true);
Service_Name Der über die init.ora (Parameter service_names) definierte und über die tnsnames.ora angesprochene Service_Name (hier im Beispiel PPS)
Modul_Name Der über dbms_application_info.set_module definierte Modulname (hier im Beispiel REIMERS)
Action_Name Der über dbms_application_info.set_module oder dbms_application_info.set_action definierte Action_name (hier im Beispiel STEP1)
Wait Events true/false (hier im Beispiel true)
Bind Variable true/false (hier im Beispiel true)
Abb. 7: Anwendung und Parameter der Prozedur serv_mod_act_trace_enable.

Somit ist der Administrator in der Lage, defi nierte Teile einer Gesamtapplikation zu tracen. Es entstehen hier allerdings im Verzeichnis user_dump_dest viele einzelne Tracefiles.

... und nun die Auswertung mit trcsess und tkprof

Wie schon erwähnt, entstehen viele einzelne Tracefiles im udump-Verzeichnis. Zur Verdichtung dieser Daten liefert Oracle nun ein neues Utility trcsess aus. Dabei müssen zwingend ein Service_Name und eine Ausgabedatei eingegeben werden (siehe Abbildung 8).

trcsess
   [output=output_file_name]
   [session=session_id]
   [clientid=client_id]
   [service=service_name]
   [action=action_name]
   [module=module_name]
   [trace_files]
Beispiel:
trcsess
   output=reimers.txt
   service=PPT *.*
Abb. 8: Vorstellung des Utility trcsess sowie ein Beispiel für die mindestens zu übergebenden Parameter.

Diese kumulierte Datei dient nun als Eingabe für den allseits bekannten tkprof:
tkprof reimers.txt reimers.out

Zurück zu unserem Einstiegsbeispiel: Herr Müller sollte mitgetracet werden. Wir können jetzt ein Modul oder eine Aktion mitschneiden, nicht aber den Benutzer direkt.

Fazit

Der Entwickler muss die Voraussetzung schaffen, dass Session Tracing auch in modernen Umgebungen noch möglich ist. Die Verwendung von dbms_application_info ist in unseren Entwicklungsprojekten zur Pflicht erhoben worden. Das sollten auch Sie zum absoluten Standard erheben!

Da das Tracing nun modulweise angestoßen wird, muss mit dem Start des Tracings nicht mehr bis zum Connect eines Benutzers gewartet werden.

Klaus Reimers (info@ordix.de).