Utiliser et comprendre les traces ODBC

Le traçage ODBC fournit un moyen de visualiser les appels entre une application le gestionnaire de pilotes ODBC et le pilote ODBC. Les appels ODBC sont écrits dans un fichier texte qui peut ensuite être examiné pour plus de détails sur le comportement de l'application ODBC et le pilote. Dans SAS, il est également possible de visualiser ces traces en utilisant la bonne option SASTRACE. Ces traces ODBC sont utile lors du débogage des messages d'erreur et autres types de problèmes pour déterminer leur cause. De par mon expérience au support SAS, je peux vous affirmer qu’une bonne analyse de problème ODBC ou SAS/ACCESS passe de façon presque inévitable par l’activation des logs ODBC, que ce soit au niveau du gestionnaire ODBC que dans le module SAS/ACCESS. Comment activer et désactiver le traçage sur Windows, UNIX et Linux Sous Windows, le traçage ODBC est activé par le biais de l'Administrateur ODBC. Pour activer le traçage, c'est simple : Sous Unix et Linux, le traçage est activé dans le fichier odbc.ini ou par l'intermédiaire de l'outil Administrateur ODBC Linux. Pour activer le traçage dans le fichier odbc.ini: En utilisant un éditeur de texte, ouvrez le fichier odbc.ini où se trouve votre source de données (par exemple /opt/odbc/odbc.ini) Votre fichier contient une section intitulée avec [ODBC] tels que: Entrez un emplacement et le nom du fichier de sortie où le fichier de trace ODBC sera créé : Pour activer le traçage, définissez l’option TRACE comme ci-dessous : Enregistrez et fermez le fichier. Le traçage est maintenant activé. Une fois que vous avez reproduit le comportement que vous tracez, le traçage ODBC doit être désactivé. Pour ce faire, ré-ouvrir le fichier odbc.ini et définir Comment activer le traçage dans SAS L’option SASTRACE génère des informations de trace à partir d'un moteur de SGBD. Dans votre session SAS, positionnez l’option suivante : La sortie est écrit dans le journal SAS, tel que spécifié dans l'option sastraceloc=saslog; Pourquoi désactiver  le traçage après avoir mené ses investigations ? Le traçage est un outil très utile, alors pourquoi le désactiver au lieu de laisser le traçage activé tout le temps? Bonne question, non ? Pourquoi ne pas laisser le traçage activé de façon permanente ? Vous auriez un journal en cours d'exécution de chaque appel ODBC fait sur votre machine. Cependant, il y a un inconvénient qui l'emporte sur le bénéfice. Le traçage écrit chaque appel ODBC dans un fichier texte et cela nécessite des ressources important. Cela signifie que les performances de votre application ODBC seront sérieusement affectées par le traçage. Aussi, laisser le traçage activé va sensiblement ralentir les performances de votre application et utiliser plus de ressources processeur sur votre machine. En outre, la taille du fichier de sortie se développera rapidement au point d'exiger d'espace de stockage. Pour ces raisons, le traçage ne doit être activé le temps d'analyser un problème ou pour réaliser un ensemble de mesures spécifiques. Dans quel cas les traces ODBC peuvent vous aider ? Le traçage est une façon de déboguer des problèmes lorsque vous ne pouvez pas déterminer la source d'un problème ou d’une erreur. L’analyse des traces ODBC peut être utilisée pour affiner un problème et déterminer son origine (pilote, application, base de données ou  même réseau). Par exemple, le traçage peut contribuer à la mise au point des messages d'erreur, la corruption de données, ou encore les problèmes de performance. Vous verrez, dans la suite de cet article, que l’activation des sastrace permet de résoudre ou comprendre bien des problématiques SAS/ACCESS. Analysons un exemple de message d’erreur ODBC : Une erreur provenant du pilote ODBC ressemblerait à : Enfin, une erreur provenant du gestionnaire de pilotes ODBC ressemblerait à ceci: Connaître l'origine du message d'erreur peut vous aider à déterminer comment débuter votre débogage. Le site du support DataDirect est une excellente source pour la recherche de messages d'erreur. Si, avec SAS, vous êtes face à des problèmes de  corruption des données ou de performance, l’origine peut se trouver dans SAS, dans le pilote ODBC, ou encore dans la base de données. Gardez en ête que des problèmes de performance (ralentissements, par exemple) sont aussi souvent causée par des problèmes de réseau. Donc, la première étape de ces types de problèmes, comme avec tous les débogages, est de déterminer la source du problème. Enfin, de nombreuses bases de données renvoient des codes d'erreur natifs lorsque cela est possible. Par exemple, la base de données Oracle retourne une série de codes d'erreur commençant par les lettres ORA ou PLS, entre autres. Comment lire une trace ODBC ? Le journal de trace ODBC affiche chaque fonction ODBC appelé  par l’application. La connaissance de la spécification de l’API ODBC vous aidera à déchiffrer le journal de trace généré. Chaque fonction ODBC accepte un ensemble de paramètres. Voici un exemple de la façon dont une fonction ODBC est visible dans le journal de suivi : Quelques petites explications sont les bienvenues :

• Process Name - Le nom du processus en cours de suivi
• XXX - L'ID du processus en cours
• YYY - L'identifiant du thread courant
• ENTER - EXIT : Entrée ou sortie de la fonction ODBC
• ODBC Function : La fonction de l’API ODBC en cours d'exécution par l'application
• RetCode : Un code de retour fourni par le pilote ODBC qui détermine l'état de la fonction exécutée
• DataType : Les données de l'argument qui est passé ou renvoyé lors de l'exécution de la fonction ODBC

Voici un exemple d'exécution de la fonction SQLExecDirect en utilisant une application ODBC appelé ODBC Test : Selon la spécification ODBC, la fonction SQLExecDirect prend 3 arguments: SQLExecDirect exécute une instruction préparée. SQLExecDirect est le meilleur moyen de présenter une requête SQL pour une exécution unique. Comparont maintenant les arguments que voyons dans notre journal de log ODBC pour étudier l'information transmise à la fonction SQLExecDirect :  Messages d'erreur Le [] immédiatement à la gauche du message d'erreur informe l'utilisateur lorsque le message d'erreur a été généré. Le message d'erreur sera soit renvoyé par l'un des composants ODBC, à savoir le conducteur ou pilote gestionnaire ODBC, ou par le magasin de données, à savoir Oracle, Sybase, DB2, etc. Le [Vendor] est le distributeur du composant ODBC référencé dans le message d'erreur. Par exemple, Datadirect ou microsoft. Un autre exemple, cette fois obtenue dans SAS, lors d'une tentative de création de bibliothèque, via une commande libname : Nous avons ici une erreur remonté dans SAS en provenance du gestionnaire ODBC. Quand vous essayez de déterminer la fonction ODBC en erreur, cherchez dans votre sastrace ou votre fichier de log ODBC, le code retour SQL_ERROR ou le message d'erreur retourné par l'application. Une fois  le message d'erreur  trouvée, vérifiez les arguments transmis pour chaque fonction ODBC. Sont-ils corrects  ? Gardez la spécification ODBC sous le coude pour confirmer l'exactitude des valeurs d'argument. Un exemple : Nous sommes face à un cas simple. En me basant sur le message d'erreur retourné, la table "em" référencé dans l'instruction SQL exécutée n'existe pas dans la base de données. Oracle Plusieurs causes : Le nom de la table peut être incorrecte, les noms de table peut-être sensibles à la casse, ou il peut exister dans un catalogue ou d'un schéma différent de la valeur par défaut. Si tel est le cas, vous auriez besoin de le qualifier dans la requête.