Di recente, un cliente che utilizzava il nostro driver ODBC di SQL Server per connettere Oracle a SQL Server, ci ha segnalato il seguente errore:
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
Questo errore "catchall" può verificarsi se:
- L'ambiente non è impostato correttamente (ad es. LD_LIBRARY_PATH non punta alle directory della libreria unixODBC o ODBCSYSINI non punta alla directory contenente la copia di odbc.ini dove è definito il DSN ODBC di destinazione.)
- Una libreria DG4ODBC a 64 bit viene utilizzata con librerie ODBC a 32 bit e viceversa.
- Il SID specificato nella tua configurazione DG4ODBC non è in esecuzione sull'host specificato in tnsnames.ora.
Tuttavia, dopo l'indagine, nessuno di questi problemi si è applicato. Sospettavamo che la causa fosse un problema di configurazione errata di Oracle, perché sebbene il debug DG4ODBC fosse abilitato, non venivano generati file di debug DG4ODBC, ovvero Oracle non riusciva a caricare la libreria DG4ODBC.
In questi casi, richiediamo i file di configurazione Oracle del cliente, in modo da poter riprodurre la loro configurazione, poiché può essere difficile individuare una parentesi mancante o fuori posto in un file .ora.
Non siamo stati in grado di riprodurre l'errore del cliente, i file di configurazione forniti hanno funzionato perfettamente per noi.
Il passo successivo è stato usare strace per guardare "sotto il cofano" quali file di configurazione venivano caricati quando veniva avviato Oracle Listener. Per fare ciò, abbiamo chiesto al cliente di:
- Avvia due sessioni di shell come utente Oracle.
- Nella shell 1, arresta il listener Oracle.
- Avvia il listener con questo comando:
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- Nella shell 2, avvia SQL*PLus ed esegui un'istruzione SQL sul collegamento al database DG4ODBC / SQL Server.
- Nella shell 2, arresta il listener Oracle.
Il registro strace, /tmp/easysoft.log, ha esposto il problema sottostante. Inizialmente, il listener Oracle è stato in grado di caricare e leggere listener.ora:
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 Tuttavia, la configurazione Oracle del cliente era:l'utente A ha avviato il listener, che è diventato l'utente B. Ciò che strace ha rivelato è che l'utente B non disponeva di autorizzazioni di accesso sufficienti per caricare quel file .ora:
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1
EACCES (Permission denied) In definitiva, questa è stata la causa dell'"ORA 02063" del cliente.
