Recentemente, um cliente que estava usando nosso driver ODBC do SQL Server para conectar o Oracle ao SQL Server, relatou o seguinte erro para nós:
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 erro "catchall" pode acontecer se:
- O ambiente não está configurado corretamente (por exemplo, LD_LIBRARY_PATH não aponta para os diretórios da biblioteca unixODBC ou ODBCSYSINI não aponta para o diretório que contém a cópia de odbc.ini onde o DSN ODBC de destino está definido.)
- Uma biblioteca DG4ODBC de 64 bits está sendo usada com bibliotecas ODBC de 32 bits e vice-versa.
- O SID especificado em sua configuração DG4ODBC não está sendo executado no host especificado em tnsnames.ora.
No entanto, após investigação, nenhuma dessas questões se aplicava. Suspeitamos que a causa fosse um problema de configuração incorreta do Oracle, porque, embora a depuração DG4ODBC estivesse habilitada, nenhum arquivo de depuração DG4ODBC estava sendo gerado, ou seja, o Oracle não estava chegando ao ponto de carregar a biblioteca DG4ODBC.
Nesses casos, solicitamos os arquivos de configuração do Oracle do cliente, para que possamos reproduzir sua configuração, pois pode ser difícil identificar um colchete ausente ou mal colocado em um arquivo .ora.
Não conseguimos reproduzir o erro do cliente, os arquivos de configuração fornecidos funcionaram perfeitamente para nós.
O próximo passo foi usar
strace
para olhar "sob o capô" em quais arquivos de configuração estavam sendo carregados quando o ouvinte Oracle estava sendo iniciado. Para isso, solicitamos ao cliente que:- Inicie duas sessões de shell como usuário Oracle.
- No shell 1, pare o ouvinte Oracle.
- Inicie o ouvinte com este comando:
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- No shell 2, inicie o SQL*PLus e execute uma instrução SQL no link do banco de dados DG4ODBC/SQL Server.
- No shell 2, pare o ouvinte Oracle.
O log de rastreamento, /tmp/easysoft.log, expôs o problema subjacente. Inicialmente, o listener Oracle foi capaz de carregar e ler 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
No entanto, a configuração do Oracle do cliente era:o usuário A iniciou o ouvinte, que se tornou o usuário B. O que revelou foi que o usuário B não tinha permissões de acesso suficientes para carregar esse arquivo .ora:
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1 EACCES (Permission denied)
Em última análise, essa foi a causa do "ORA 02063" do cliente.