Récemment, un client qui utilisait notre pilote ODBC SQL Server pour connecter Oracle à SQL Server, nous a signalé l'erreur suivante :
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
Cette erreur "catchall" peut se produire si :
- L'environnement n'est pas défini correctement (par exemple, LD_LIBRARY_PATH ne pointe pas vers les répertoires de la bibliothèque unixODBC, ou ODBCSYSINI ne pointe pas vers le répertoire contenant la copie de odbc.ini où le DSN ODBC cible est défini.)
- Une bibliothèque DG4ODBC 64 bits est utilisée avec des bibliothèques ODBC 32 bits et vice versa.
- Le SID spécifié dans votre configuration DG4ODBC ne s'exécute pas sur l'hôte spécifié dans tnsnames.ora.
Cependant, après enquête, aucune de ces questions ne s'appliquait. Nous soupçonnions que la cause était un problème de mauvaise configuration d'Oracle, car bien que le débogage DG4ODBC ait été activé, aucun fichier de débogage DG4ODBC n'était généré, c'est-à-dire qu'Oracle n'allait pas jusqu'à charger la bibliothèque DG4ODBC.
Dans de tels cas, nous demandons les fichiers de configuration Oracle du client afin de pouvoir reproduire leur configuration, car il peut être difficile de repérer une parenthèse manquante ou mal placée dans un fichier .ora.
Nous n'avons pas pu reproduire l'erreur du client, les fichiers de configuration fournis ont parfaitement fonctionné pour nous.
L'étape suivante consistait à utiliser strace pour regarder "sous le capot" quels fichiers de configuration étaient chargés au démarrage de l'écouteur Oracle. Pour ce faire, nous avons demandé au client :
- Démarrez deux sessions shell en tant qu'utilisateur Oracle.
- Dans le shell 1, arrêtez l'écouteur Oracle.
- Démarrez l'écouteur avec cette commande :
strace -f -o /tmp/easysoft.log -s 512 lsnrctl start
- Dans le shell 2, démarrez SQL*PLus et exécutez une instruction SQL sur le lien de base de données DG4ODBC / SQL Server.
- Dans le shell 2, arrêtez l'écouteur Oracle.
Le journal strace, /tmp/easysoft.log, a exposé le problème sous-jacent. Initialement, l'écouteur Oracle pouvait charger et lire 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 Cependant, la configuration Oracle du client était :l'utilisateur A a démarré l'écouteur, qui est devenu l'utilisateur B. Ce que strace a révélé, c'est que l'utilisateur B n'avait pas les autorisations d'accès suffisantes pour charger ce fichier .ora :
53051 open("/u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora", O_RDONLY) = -1
EACCES (Permission denied) En fin de compte, c'était la cause du "ORA 02063" du client.
