20. April 2007

Der Datenbank sagen, was man tut ...

Heute schneide ich ein etwas anderes Thema an: Die Zusammenarbeit zwischen Entwicklern und DBA's. Und als Entwickler, gleich ob Java, .NET oder PL/SQL, können wir eine ganze Menge tun, um diese zu verbessern. Betrachten wir den typischen Fall einer 3-Schichten-Architektur mit J2EE-Server und Connection-Pool ... Der DBA schaut in seine Datenbank und sieht in der View V$SESSION ...
SQL> select sid, serial#, username, client_info 
  2  from v$session 
  3  where username is not null;

       SID    SERIAL# USERNAME             CLIENT_INFO
---------- ---------- -------------------- ---------------
       147         35 DEMO_WS
       149         73 DEMO_WS
       159        285 SYSTEM
         :          : : 
Und was tun diese Sessions gerade? Tja ... keine Ahnung ...
Es wäre natürlich gut, wenn der DBA wüsste, was da passiert. Er muss vielleicht entscheiden, ob er die Session, die da gerade 90% CPU-Leistung konsumiert, "abgeschossen" werden soll oder nicht. Genauere Informationen würden die Entscheidung erleichtern ... und zum langen Telefonieren bleibt vielleicht keine Zeit mehr ...
Und es ist ganz einfach! In der Oracle-Datenbank gibt es eine fertige Schnittstelle, mit der man den DBA als Entwickler über das, was man da tut, benachrichtigen kann: DBMS_APPLICATION_INFO. Angewendet wird es wie folgt:
begin 
  DBMS_APPLICATION_INFO.SET_CLIENT_INFO(
    client_info => 'APPLIKATION MIS 01'
  );
  DBMS_APPLICATION_INFO.SET_MODULE(
    module_name => 'ADMIN_MODUL',
    action_name => 'BATCH_JOB_FRIDAY_001'
  );
end;
Und der DBA sieht nun folgendes ...
       SID    SERIAL# USERNAME        CLIENT_INFO          MODULE             ACTION
---------- ---------- --------------- -------------------- ------------------ -------------------------
       138         82 SCOTT           APPLIKATION MIS 01   ADMIN_MODUL        BATCH_JOB_FRIDAY_001
         :          : :               :                    :                  :
... das ist natürlich eine ganz andere Arbeitsbasis für den DBA. Ich kann den Einsatz dieses Paketes nur wärmstens empfehlen ... Die PL/SQL-Calls können natürlich auch von Java (CallableStatement), PHP, .NET oder anderen Umgebungen aus genutzt werden.
Es ist natürlich wie immer: Solange alles gut läuft, braucht man es nicht - aber wenn der DBA eines Tages schnell reagieren muss und keine Zeit mehr für lange Telefonate hat, dann wird's richtig wertvoll ...

Keine Kommentare:

Beliebte Postings