Recientemente, un cliente que estaba usando nuestro controlador ODBC de SQL Server para conectar Oracle a SQL Server, nos informó el siguiente error:
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
Este error "catchall" puede ocurrir si:
- El entorno no está configurado correctamente (por ejemplo, LD_LIBRARY_PATH no apunta a los directorios de la biblioteca unixODBC, o ODBCSYSINI no apunta al directorio que contiene la copia de odbc.ini donde se define el DSN de ODBC de destino).
- Se utiliza una biblioteca DG4ODBC de 64 bits con bibliotecas ODBC de 32 bits y viceversa.
- El SID especificado en su configuración DG4ODBC no se está ejecutando en el host especificado en tnsnames.ora.
Sin embargo, después de la investigación, ninguno de estos problemas se aplicó. Sospechábamos que la causa era un problema de configuración incorrecta de Oracle, porque aunque la depuración de DG4ODBC estaba habilitada, no se generaban archivos de depuración de DG4ODBC, es decir, Oracle no llegaba a cargar la biblioteca DG4ODBC.
En tales casos, solicitamos los archivos de configuración de Oracle del cliente para que podamos reproducir su configuración, ya que puede ser difícil detectar un corchete faltante o fuera de lugar en un archivo .ora.
No pudimos reproducir el error del cliente, los archivos de configuración proporcionados funcionaron perfectamente para nosotros.
El siguiente paso fue usar strace para mirar "debajo del capó" qué archivos de configuración se estaban cargando cuando se iniciaba el oyente de Oracle. Para ello, le pedimos al cliente que:
- Inicie dos sesiones de shell como usuario de Oracle.
- En el shell 1, detenga el oyente de Oracle.
- Inicie el oyente con este comando:
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- En el shell 2, inicie SQL*PLus y ejecute una instrucción SQL en el enlace de la base de datos DG4ODBC/SQL Server.
- En el shell 2, detenga el oyente de Oracle.
El registro de strace, /tmp/easysoft.log, expuso el problema subyacente. Inicialmente, el oyente de Oracle podía cargar y leer 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 Sin embargo, la configuración de Oracle del cliente era:el usuario A inició el escucha, que se convirtió en el usuario B. Lo que strace reveló fue que el usuario B no tenía suficientes permisos de acceso para cargar ese archivo .ora:
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1
EACCES (Permission denied) En última instancia, esta fue la causa del "ORA 02063" del cliente.
