Schlagwort-Archive: Java

Oracle 12c / Java7: setEndToEndMetrics() deprecated

Dies ist eine kurze Aktualisierung zu meinem früheren Artikel „DBMS_SESSION: Anwender und Sessions mehrschichtiger Anwendungen in der DB identifizieren„, der sich auf Oracle 11.2 nebst der damals unterstützten JDBC-Version bezog.

Die Oracle 12c JDBC-Treiber unterstützen JDBC 4.1 über das JDK 7 und damit auch die JDBC DMS Metrics, wenn entsprechende Treiber-Packages (z.B. ojdbc7dms.jar) verwendet werden. Die in meinem damaligen Beispiel verwendete Methode setEndToEndMetrics schließt allerdings die wechselseitige Verwendung mit DMS-Methoden aus. Daher empfiehlt es sich auf die neue Methode setClientInfo umzustellen. Ein Codefragment mit der neuen Methode kann dann so aussehen:

...
Connection conn = DriverManager.getConnection(myUrl, myUsername, myPassword);
conn.setClientInfo("E2E_CONTEXT.DBOP", "MeinTag");
Statement stmt = conn.createStatement();
// DBOP-Tag wird mit dem naechsten DB-Aufruf gesetzt:
stmt.execute("select 1 from dual");
...

Dem Nachteil, dass schon wieder eine andere Methode als bisher verwendet werden soll, steht der Vorteil gegenüber, dass man sich mit DMS Metrics in einem standardisierten Umfeld bewegt und auch nicht mehr zwingend eine OracleConnection verwenden muss; eine einfache Connection reicht aus.

Advertisements

DBMS_SESSION: Anwender und Sessions mehrschichtiger Anwendungen in der DB identifizieren

„Wer war das“!?

In mehrschichtigen Softwarearchitekturen (also einem Großteil der Web-Anwendungen) wird die Verbindung zur Datenbank meist über wiederverwendbare Verbindungen, sog. Connection Pools, aufgebaut (siehe dazu auch meinen Artikel über Proxy-User). Wenn die Benutzerverwaltung nicht in der Datenbank sondern in der Anwendung stattfindet, verbindet sich dabei der Application Server üblicherweise mit einem einzigen, „technischen User“ mit der Datenbank.

Dem Vorteil der dadurch eingesparten Zeit für einen Verbindungsaufbau bei jeder DB-Abfrage steht damit aber der Nachteil gegenüber, daß auf der DB-Seite nicht mehr nachvollzogen werden kann, welcher Anwender und welche (oder welcher Teil der) Anwendung in einer bestimmten Session läuft. Das ist zwar im Normalbetrieb nicht so wichtig, wenn es aber zu Problemen kommt, dann kann diese fehlende Information die Fehlersuche schwer beeinträchtigen. Drei häufige Szenarien seien hier genannt:

  • Der DB-Server ist plötzlich überlastet. Die Ursache kann zwar bis zu einer bestimmten Session in der Datenbank verfolgt werden, aber nun ist noch nicht klar, wer diese Session besitzt und welche Aufgabe er gerade ausführen will.
  • Ein Anwender beklagt sich über zu lange Antwortzeiten in einem bestimmten Anwendungsteil. Von den 500 offenen Sessions auf der DB kann aber nicht identifiziert werden, in welcher dieser Sessions der Anwender aktiv ist, und daher kann keine gezielte Fehlerverfolgung (z.B. mittels Tracing) durchgeführt werden.
  • Zur Erfüllung von Sicherheitsrichtlinien sollen Informationen über die Aktivitäten von Anwendern in der Datenbank gesammelt werden (Auditing). Das Oracle RDBMS kann das zwar von Haus aus, wenn aber die Verbindung nur über einen einzigen Useraccount läuft, fehlen wesentliche Informationen.

Softwareentwickler sollten daher schon im eigenen Interesse Ihre Anwendungen von Anfang an so instrumentieren, daß ein DBA bei Problemen auf der Datenbank gezielt Informationen sammeln kann.

Weiterlesen