Kürzlich hat uns ein Kunde, der unseren SQL Server ODBC-Treiber verwendet hat, um Oracle mit SQL Server zu verbinden, den folgenden Fehler gemeldet:
ORA-28545: error diagnosed by Net8 when connecting to an agent Unable to retrieve text of NETWORK/NCR message 65535 ORA-02063: preceding 2 lines from SQLSERVERLINK
Dieser "Catchall"-Fehler kann auftreten, wenn:
- Die Umgebung ist nicht richtig eingestellt (z. B. zeigt LD_LIBRARY_PATH nicht auf die unixODBC-Bibliotheksverzeichnisse oder ODBCSYSINI zeigt nicht auf das Verzeichnis, das die Kopie von odbc.ini enthält, in der der Ziel-ODBC-DSN definiert ist.)
- Eine 64-Bit-DG4ODBC-Bibliothek wird mit 32-Bit-ODBC-Bibliotheken verwendet und umgekehrt.
- Die in Ihrer DG4ODBC-Konfiguration angegebene SID läuft nicht auf dem in tnsnames.ora angegebenen Host.
Bei der Untersuchung traf jedoch keiner dieser Punkte zu. Wir vermuteten, dass die Ursache ein Oracle-Fehlkonfigurationsproblem war, denn obwohl das DG4ODBC-Debugging aktiviert war, wurden keine DG4ODBC-Debug-Dateien generiert, d. h. Oracle kam nicht so weit, die DG4ODBC-Bibliothek zu laden.
In solchen Fällen fordern wir die Oracle-Konfigurationsdateien des Kunden an, damit wir seine Einrichtung reproduzieren können, da es schwierig sein kann, eine fehlende oder falsch platzierte Klammer in einer .ora-Datei zu erkennen.
Wir konnten den Fehler des Kunden nicht reproduzieren, die mitgelieferten Konfigurationsdateien haben bei uns einwandfrei funktioniert.
Der nächste Schritt war die Verwendung von strace
um "unter die Haube" zu schauen, welche Konfigurationsdateien geladen wurden, als der Oracle-Listener gestartet wurde. Dazu haben wir den Kunden gebeten:
- Starten Sie zwei Shell-Sitzungen als Oracle-Benutzer.
- Beenden Sie in Shell 1 den Oracle-Listener.
- Starten Sie den Listener mit diesem Befehl:
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- Starten Sie in Shell 2 SQL*PLus und führen Sie eine SQL-Anweisung für die DG4ODBC / SQL Server-Datenbankverbindung aus.
- Beenden Sie in Shell 2 den Oracle-Listener.
Das Strace-Protokoll /tmp/easysoft.log deckte das zugrunde liegende Problem auf. Anfänglich konnte der Oracle-Listener listener.ora:
laden und lesen53049 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = 3 53049 read(3, "#/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora Network Configuration File: \n# Generated by Oracle configuration tools.\n\nLISTENER =\n (DESCRIPTION_LIST =\n (DESCRIPTION =\n (ADDRESS = (PROTOCOL = TCP)..., 4096) = 577
Das Oracle-Setup des Kunden war jedoch:Benutzer A startete den Listener, der zu Benutzer B wurde. Strace enthüllte, dass Benutzer B nicht über ausreichende Zugriffsberechtigungen verfügte, um diese .ora-Datei zu laden:
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1 EACCES (Permission denied)
Letztendlich war dies die Ursache für den "ORA 02063" des Kunden.