Database
 sql >> Base de données >  >> RDS >> Database

Enquête sur une erreur ORA 028513 DG4ODBC

La connexion d'Oracle à SQL Server est l'un des cas d'utilisation les plus courants du pilote ODBC Easysoft SQL Server. Soutenir cette combinaison ne consiste pas seulement à fournir une assistance pour la mise en place de notre chauffeur. Cela signifie également aider à résoudre les problèmes de configuration Oracle qui empêchent Oracle Heterogeneous Services d'aller jusqu'au chargement de notre pilote.

Récemment, un client du pilote SQL Server ODBC nous a signalé l'erreur suivante :

ORA-28513: internal error in heterogeneous remote agent

Le client a pu nous fournir un journal de suivi DG4ODBC, qui nous a dit deux choses :

  1. Les fichiers de configuration Oracle (.ora) ont été configurés correctement. Si ces fichiers contiennent une erreur (par exemple, une parenthèse manquante ou superflue), aucun journal de trace DG4ODBC ne sera généré.
  2. DG4ODBC n'essayait même pas de charger le gestionnaire de pilotes unixODBC.

Dans des situations comme celles-ci où le journal Oracle DG4ODBC n'identifie pas le problème (il contiendra normalement toujours plus d'informations que l'erreur ORA-NNNNN signalée par l'application), et la journalisation ODBC n'est pas encore possible, nous atteignons pour strace ou truss . Par exemple :

  1. Démarrez deux sessions shell en tant qu'utilisateur Oracle.
  2. Dans le shell 1, arrêtez l'écouteur Oracle.
  3. Démarrez l'écouteur avec cette commande :
    strace -f -o /tmp/easysoft.log -s 512 lsnrctl start

    —Ou—

    truss -wall -rall -o /tmp/easysoft.log lsnrctl start
  4. 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.
  5. Dans le shell 2, arrêtez l'écouteur Oracle.

Cependant, l'outil de traçage de la bibliothèque système (truss dans le cas du client) n'a toujours pas révélé la cause du problème.

Au final, il s'est avéré que le client définissait le ORA_NLS10 variable d'environnement, et un effet secondaire de cette opération était d'empêcher DG4ODBC de fonctionner. Comme la variable n'avait pas besoin d'être définie sur cette machine, la désactiver et la supprimer d'un fichier de profil était la solution au problème du client.