Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:sqlnet_trace

Übersicht SQL*Net Probleme

Um sich an die Oracle Datenbank anzumelden haben Sie zwei Optionen:

SQL*Plus oder ähnliches auf den gleichen Rechner wie die Datenbank

Ist SQL*Plus auf den gleichen Rechner wie die Datenbank installiert, kann auf die laufende Instance ( den Server Prozess der Datenbank) OHNE das SQL*Net Protokoll, d.h. ohne Netzwerk auf die Datenbank zugreifen werden (Aufruf „sqlplus username/password“).

Dazu muss in der Umgebung die Variable ORACLE_SID=<SID DER DB> (SID ist so etwas wie der Name der Datenbank) gesetzt werden, dann können Sie sich mit Name/Passwort anmelden.

Über die Umgebungsvariable ORACLE_SID weiß dann das SQL*Plus (oder ähnliche auf C/C++ basierende Programme) wo es hin muss und sucht im Speicher der lokalen Maschine nach der DB.

Ist die ORACLE_SID nicht oder aber falsch gesetzt, bekommen Sie auch die Fehlermeldung „ORA-12560 TNS protocol adapter error“.

SQL*Plus baut die Verbindung über das Netzwerk zur Datenbank auf

Damit sich ein Client, wie SQL*Plus oder ein Java Programm, über das Netzwerk an der Datenbank anmelden kann, läuft auf der Datenbank Maschine ein sogenannter Listener Prozess, meist auf dem Port 1521, bei SAP oft gerne aber auch ein andere Port wie 1527 / 1522.

Dieser Listener Prozess registriert die Anfrage des Client an eine Datenbank und startet auf der Datenbank Maschine einen Prozess ( den Server Prozess), der mit der Datenbank „redet“ und mit dem Client kommuniziert.

Dieser Prozess führt auch das eigentliche SQL durch. Der Listener wird nur am Anfang benötigt, danach spielt der Listener in der aufgebauten Kommunikation keine Rolle.

Wie findet nun aber der Client zur Datenbank?

Dazu wird zum Beispiel SQL*Plus mit dem Usernamen/Passwort@DatenbankAlias aufgerufen. ( „sqlplus username/password@tnsalias“ )

Der tnsalias oder DatenbankAlias beschreibt dem SQL*Net Protokoll, wie die Verbindung aufgebaut werden soll, vor allen wohin sich der Client verbinden soll und an welche Datenbank.

Diesen DatenbankAlias muss man sich wie einen Namensauflösung vorstellen. Wie der Name aufgelöst werden soll, sagen dem SQL*Net Protokoll die beiden Dateien sqlnet.ora und tnsnames.ora.

Steht in der sqlnet.ora, dass für die Namensauflösung die Datei tnsnames.ora verwendet werden soll (Parameter: NAMES.DIRECTORY_PATH= (TNSNAMES) ) wird die Datei tnsnames.ora ausgewertet und dort nach dem DatenbankAlias gesucht. Dieser Alias muss nicht wie die DB heißen!

Fallstricke:

#1

Ist die Umgebungsvariable LOCAL in der lokalen Umgebung gesetzt, dann wird als DatenbankAlias der Wert von LOCAL verwendet und eine Anmeldung ist auch ohne Angabe des TNSAlias mit „sqlplus username/password“ möglich, scheinbar ohne den TNSAlias.

#2

Es wird die falsche tnsnames.ora Datei von SQL*Plus verwendet oder erst gar nicht diese Datei gefunden (passiert gerne wenn mehrere Oracle Installation auf den Rechner existieren).

Lösung:
Global auf dem System die Umgebungsvariable TNS_ADMIN setzen und auf das richtige Verzeichnis für die sqlnet.ora/tnsname.ora zeigen lassen.

Dies hilft sehr oft bei unverständlichen Verbindungsproblemen mit OLEDB oder ODBC. Es wird verhindert, dass sich hier, je nach angemeldeten User oder Job Umgebung (System Prozesse!), die lokalen Pfade anders interpretiert werden und die Steuerdateien dann nicht gefunden werden!

Dies ist auch die Lösung für das Problem, das die die tnsalias namen nicht automatisch im ODBC oder OLEDB Connection Dialog angezeigt werden!

Für 64bit System die einen 32bit treiber benötigen siehe Installation eines 32 Bit ODBC Treibers unter Windows 7 / 2008 64bit

#Test

Ein Testen erfolgt mit dem Programm „tnsping >DatenbankAlias>“, hier in der Ausgabe auf die Pfadangabe zur sqlnet.ora achten (ein Art ping für das sql*net Protokoll).

#3 FW

Für die Verbindung muss zu Beginn der Listener Port, meist 1521, auf der FW offen sein, und die FW muss so clever sein zu erkennen, dass der SQL*Plus Client mit dem Serverprozess später dann über einen höheren Port kommunizieren.

Der Client „redet“ allerdings nicht dauernd mit dem Serverprozess auf der DB, ist auf der Leitung mal mehr als ca. 1 h Funkstille denkt die Firewall, die Verbindung existiert nicht mehr, die nächste Abfrage wird dann abgeblockt und es gibt einen SQLNet ORA-125 Fehler auf dem Client.

Lösung:
Falls der FW Hersteller keinen SQL*Net Proxy zur Verfügung stellen will/kann:

Die gnadenlose Lösung wäre es alle 10 Minuten mit einem „select * from dual“ die Verbindung künstlich am Leben zu halten. ( in der gleichen Session!). Ansonsten wird es nur helfen, die Programm / Job Logik so zu ändern, dass für jeden Abfrageblock eine neue Session zur DB aufgebaut wird.

SQL Net Trace anlegen

Können keine Standard Fehler erkannt werden, hilft oft nur noch das Tracing von SQL*Net zu aktivieren. Ablauf:

  • Mit tnsping testen, wo die aktuelle sqlnet.ora liegt
  • sqlnet.ora editieren
  • Testen
  • Wieder ausschalten

SQL*Net Trace Client

Parameter in der sqlnet.ora setzen und damit SQL*NET Trace einschalten

TRACE_LEVEL_CLIENT = SUPPORT
TRACE_UNIQUE_CLIENT = on
TRACE_DIRECTORY_CLIENT = c:\temp
TRACE_FILE_CLIENT = sqlnet_
TRACE_TIMESTAMP_CLIENT=ON

#
# AB 11g werden die Trace Dateien in das DIAG Verzeichnis geschrieben
# Windows Default C:\Documents and Settings\<username>\Oracle
#

ADR_BASE = D:\temp

Unter der DB Version 11g lassen sich die traces hier finden: $ORACLE_BASE/diag/clients/user_oracle/host_$NUMBER/trace

Nicht vergessen wieder auszuschalten!!

Tnsping Trace:

Parameter in der sqlnet.ora

TNSPING.TRACE_LEVEL=SUPPORT
TNSPING.TRACE_DIRECTORY= c:\temp

Diese Einstellung kann eingeschaltet beleiben da nur ein Log bei TNSPing erzeugt wird und diese recht klein ist.

SQL*Net Trace Server

TRACE_LEVEL_SERVER=16
TRACE_FILE_SERVER=srv_.trc
TRACE_DIRECTORY_SERVER=/tmp
TRACE_UNIQUE_SERVER=TRUE
 
# one way TO find the trace files easyer:
DIAG_ADR_ENABLED=OFF

SQL*Net Trace mit trcasst auswerten

Mit dem Programm trcasst kann der Trace ebenfalls ausgewertet werden.

trcasst
 
Verwendung: trcasst [options] <filename>
     [options]  Standardwerte sind -odt -e0 -s
     <filename>  immer das letzte Argument
   -o[c|d][u|t][q]  Net Services- und TTC-Informationen
     [c]  Zusammenfassung der Net Services-Informationen
     [d]  Detaillierte Net Services-Informationen
     [u]  Zusammenfassung der TTC-Informationen
     [t]  Detaillierte TTC-Informationen
     [q]  SQL-Befehle
   -s  Statistiken
   -e[0|1|2]  Fehlerinformationen, Standard ist 0
     [0]  NS-Fehlernummern ⁿbersetzen
     [1]  Fehlerⁿbersetzung
     [2]  Fehlernummern ohne Übersetzung
   -l[a|i <connection_id>]  Verbindungsinformationen
     [a]  Auflisten aller Verbindungen in einer Trace-Datei
     [i <connection_id>]  Decodieren einer angegebenen Verbindung
 

Weitere Infos

Support:

  • Using and Disabling the Automatic Diagnostic Repository (ADR) with Oracle Net for 11g
  • Examples of Troubleshooting Slow Oracle Net Connections (Doc ID 1076022.1)
  • Oracle Net Diagnostics (Doc ID 834822.1)
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
"Autor: Gunther Pipperr"
dba/sqlnet_trace.txt · Zuletzt geändert: 2014/05/02 13:41 von Gunther Pippèrr