Récemment, un client qui utilisait notre pilote ODBC SQL Server pour connecter Oracle à SQL Server, a rencontré un problème difficile à résoudre.
Le client recevait un journal du gestionnaire de pilotes ODBC chaque fois que DG4ODBC était utilisé, ce qui réduisait les performances - la journalisation des appels ODBC a un coût en termes de performances. Le client avait vérifié le fichier odbcinst.ini pour les entrées qui permettent la journalisation; ces entrées n'étaient pas présentes.
Pour aider à résoudre ce problème, nous avons utilisé l'outil strace pour découvrir ce qui se passait "dans les coulisses" lorsque DG4ODBC était utilisé.
Étant donné que DG4ODBC est une bibliothèque plutôt qu'une application, nous avons dû attacher strace au processus d'écoute Oracle (l'application "parente" de DG4ODBC) pour tracer les opérations associées à DG4ODBC.
Le fichier de trace indiquait quelle copie de odbcinst.ini activait la journalisation.
Voici les étapes que nous avons suivies pour attacher strace à l'écouteur Oracle :
$ ps -aef | grep tns* oracle 16242 1 0 15:02 ? 00:00:00 /u01/app/oracle/product/11.2.0/xe/bin/tnslsnr LISTENER -inherit $ sudo strace -p 16242 -f -o /tmp/mytracefile
(Dans une fenêtre de terminal séparée):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Ce qu'Oracle a fait "sous le capot" est maintenant capturé dans /tmp/mytracefile. Nous avons ensuite utilisé ctrl-c pour arrêter strace et recherché sql.log (le fichier journal du gestionnaire de pilotes ODBC) dans /tmp/mytracefile. Dans notre cas, cela a montré :
16436 open("/etc/odbcinst.ini", O_RDONLY) = 7
16436 fstat(7, {st_mode=S_IFREG|0644, st_size=1365, ...}) = 0
16436 read(7, "[ODBC]\nTrace=Yes\nTraceFile=/tmp/"..., 4096) = 1365
16436 read(7, "", 4096) = 0
16436 close(7) = 0
16436 open("/u01/app/oracle/.odbcinst.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
16436 open("/tmp/sql.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 7 
