Dem Datenbank-Link auf der Spur

02.
November
2015
Veröffentlicht von: Richard Alexander Meinhardt

In historisch gewachsenen Datenbank-Landschaften mit vielen Datenbanken kommt es häufig vor, dass die einzelnen Datenbanken über Datenbank-Links verbunden sind...

   SID User                 Host                 Global TX ID                   Wait Event
------ -------------------- -------------------- ------------------------------ --------------------------------------------------
    67 FIRMENUSER           FIRMENHOST             FIRMENDB.fe9da486.5.29.6585    SQL*Net message from client

Nun sollten Sie auf der Ziel-Datenbank ebenfalls diesen Select als SYS-Benutzer ausführen:

Ziel:

  SID User                 Host                 Global TX ID                   Wait Event
------ -------------------- -------------------- ------------------------------ --------------------------------------------------
    35 PERSONENUSER           FIRMENHOST             FIRMENDB.fe9da486.5.29.6585    SQL*Net message from client

So eindeutige Ergebnisse gibt es natürlich nur in einer relativ leeren Testumgebung. Wenn Sie beim Global Transaction Select viele Ergebnisse zurück bekommen, sollten Sie diese über die SID einschränken. Die SID müssen Sie allerdings vorher ermitteln.

Erklärung der Spalten:

SID - Dieser Spalte enthält die auf der jeweiligen Instanz zugehörige SID der lokalen Session.

User - Enthält den Benutzer mit dem diese Session gestartet wurde.

Host - Enthält den Remote Host von dem diese Session aus gestartet wurde (bei längeren Ketten von Datenbank-Links ist das nicht zwangsläufig die ursprüngliche Quell.).

Global TX ID - Zeigt die Gobale Transaktions Identifikations Nummer. Diese ist über alle Instanzen gleich und das eindeutigste Kriterium, um den Weg des Datenbank-Links zu verfolgen. Sie beginnt immer mit der SID der Datenbank, auf der die erste Transaktion gestartet wurde.

Wait Event - Hier ist das derzeit aktuelle Wait Event der Session zu sehen.

Durch die SELECTs in diesem Beispiel wissen Sie nun, dass die Session mit der SID 67 in der Quell-Datenbank und die Session mit der SID 35 in der Ziel-Datenbank zusammen gehören und Sie könnten ihre Fehler- oder Performance Analyse starten.

Komplexeres Beispiel

Szenario: Sie haben eine Session die andere Sessions massiv ausbremst. Von dieser Session wissen Sie die SID (417) und wollen nun in Erfahrung bringen woher diese Session stammt. Die erste Analyse hat ergeben, dass es sich um keine direkte Verbindung zur Datenbank handelt, sondern durch einen Datenbank-Link entstand.

In diesem Fall befinden Sie sich auf der Ziel-Datenbank und führen als SYS-Benutzer nun den Global Transaction Select durch.

In unserem Testfall erhalten wir folgendes Ergebnis:

   SID User                 Host                 Global TX ID                   Wait Event
------ -------------------- -------------------- ------------------------------ --------------------------------------------------
   417 STANDORTUSER          FIRMENHOST             PERSONENDB.fa233449.1.22.18169      SQL*Net message from client

Wie wir schon wissen, hat die Problem-Session die SID 417, die Session wurde mit dem User STANDORTUSER vom FIRMENHOST und einer Datenbank mit der SID PERSONENDB erstellt.

Nach kurzer Recherche steht fest, dass es auf dem FIRMENHOST keine Datenbank mit der SID PERSONENDB gibt! Auf den Host FIRMENHOST laufen mehrere Datenbanken. Ohne weiteres Wissen hilft erstmal nur raten und den Global Transaction Select auf jeder Datenbank dort auszuführen welche einen Datenbank-Link auf das schlussendliche Ziel hat, um einen Eintrag mit der gleichen Transaktions-Nummer zu finden.

Dank Murphy's Law werden wir erst auf der letzten Datenbank, die wir prüfen fündig und erhalten folgenden Ausgabe des Global Transaction Selects:

   SID User                 Host                 Global TX ID                   Wait Event
------ -------------------- -------------------- ------------------------------ --------------------------------------------------
    71 FIRMENUSER           PERSONENHOST                PERSONENDB.fa233449.1.22.18169      SQL*Net message from client

Die Global TX ID ist identisch, und somit handelt es sich um die gleiche globale Transaktion. In der Ausgabe sehen wir nun wieder einen neuen Host und einen neuen User. In diesem Fall sind wir scheinbar auch schon am Ende der Suche angekommen, denn es gibt auf dem Host PERSONENHOST eine Instanz mit der SID PERSONENDB.

In ihr setzten wir nun wiederrum als SYS-Benutzer den Global Transaction Select ab und erhalten das folgende Ergebnis:

   SID User                 Host                 Global TX ID                   Wait Event
------ -------------------- -------------------- ------------------------------ --------------------------------------------------
   266 PERSONENUSER           PERSONENHOST                PERSONENDB.fa233449.1.22.18169      SQL*Net message from client

Da die Datenbank-SID in der Global TX ID der Datenbank-SID der Instanz entspricht, auf der wir uns befinden und dies für den Host ebenfalls zutrifft, kann man davon ausgehen, dass wir die ursprüngliche Quelle gefunden haben. Jetzt können Sie über v$session weitere Informationen ermitteln und eine Problem- bzw. Performance Analyse starten.

Hier hadelt es sich natürlich um sehr geradlinige Beispiele, die einfach zu ermitteln sind, da diese Test-Datenbanken kaum Sessions über Datenbank-Links aufweisen. Das Vorgehen zum Nachverfolgen von Transaktionen über Datenbank-Links bleibt in groben Zügen aber immer das selbe.

Datenbank-Link Analyse

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.