For nylig oplevede en kunde, der brugte vores SQL Server ODBC-driver til at forbinde Oracle til SQL Server, et problem, som viste sig at være svært at komme til bunds i.
Kunden fik en ODBC Driver Manager-log, hver gang DG4ODBC blev brugt, med et deraf følgende træk på ydeevnen - logning af ODBC-opkald har en ydeevneomkostning. Kunden havde tjekket filen odbcinst.ini for poster, der muliggør logning; disse poster var ikke til stede.
For at hjælpe med at løse dette problem brugte vi strace-værktøjet til at opdage, hvad der foregik "bag kulisserne", da DG4ODBC var i brug.
Fordi DG4ODBC er et bibliotek snarere end en applikation, var vi nødt til at knytte strace til Oracle-lytterprocessen (DG4ODBC's "forældre"-applikation) for at spore de operationer, der er forbundet med DG4ODBC.
Sporingsfilen viste, hvilken kopi af odbcinst.ini der aktiverede logning.
Dette er de trin, vi tog for at knytte spor til Oracle-lytteren:
$ 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
(I et separat terminalvindue):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Hvad Oracle har gjort "under motorhjelmen" er nu fanget i /tmp/mytracefile. Vi brugte derefter ctrl-c til at stoppe strace og søgte efter sql.log (logfilen til ODBC Driver Manager) i /tmp/mytracefile. I vores tilfælde viste dette:
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