Onlangs meldde een klant die ons SQL Server ODBC-stuurprogramma gebruikte om Oracle met SQL Server te verbinden, de volgende fout aan ons:
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
Deze "catchall"-fout kan optreden als:
- De omgeving is niet correct ingesteld (bijv. LD_LIBRARY_PATH verwijst niet naar de unixODBC-bibliotheekdirectory's, of ODBCSYSINI verwijst niet naar de directory met de kopie van odbc.ini waarin de doel-ODBC-DSN is gedefinieerd.) >
- Er wordt een 64-bits DG4ODBC-bibliotheek gebruikt met 32-bits ODBC-bibliotheken en omgekeerd.
- De SID die is opgegeven in uw DG4ODBC-configuratie, wordt niet uitgevoerd op de host die is opgegeven in tnsnames.ora.
Bij onderzoek waren echter geen van deze problemen van toepassing. We vermoedden dat de oorzaak een verkeerde configuratie van Oracle was, want hoewel DG4ODBC-foutopsporing was ingeschakeld, werden er geen DG4ODBC-foutopsporingsbestanden gegenereerd, d.w.z. Oracle kwam niet zo ver als het laden van de DG4ODBC-bibliotheek.
In dergelijke gevallen vragen we de Oracle-configuratiebestanden van de klant op, zodat we hun instellingen kunnen reproduceren, aangezien het moeilijk kan zijn om een ontbrekend of verkeerd geplaatst haakje in een .ora-bestand te herkennen.
We konden de fout van de klant niet reproduceren, de meegeleverde configuratiebestanden werkten perfect voor ons.
De volgende stap was het gebruik van strace om "onder de motorkap" te kijken welke configuratiebestanden werden geladen toen de Oracle-listener werd gestart. Om dit te doen, hebben we de klant gevraagd om:
- Start twee shell-sessies als de Oracle-gebruiker.
- In shell 1 stop je de Oracle-luisteraar.
- Start de luisteraar met dit commando:
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- Start in shell 2 SQL*PLus en voer een SQL-statement uit tegen de DG4ODBC/SQL Server-databaselink.
- Stop in shell 2 de Oracle-luisteraar.
Het strace-logboek, /tmp/easysoft.log, legde het onderliggende probleem bloot. Aanvankelijk kon de Oracle-luisteraar listener.ora laden en lezen:
53049 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 De Oracle-configuratie van de klant was echter:gebruiker A startte de listener, die gebruiker B werd. Wat onthulde was dat gebruiker B niet voldoende toegangsrechten had om dat .ora-bestand te laden:
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1
EACCES (Permission denied) Dit was uiteindelijk de oorzaak van de "ORA 02063" van de klant.