Onlangs ondervond een klant die ons SQL Server ODBC-stuurprogramma gebruikte om Oracle met SQL Server te verbinden, een probleem dat moeilijk te achterhalen was.
De klant kreeg een ODBC Driver Manager-log wanneer DG4ODBC werd gebruikt, met als gevolg een rem op de prestaties - het loggen van ODBC-oproepen heeft prestatiekosten. De klant had het bestand odbcinst.ini gecontroleerd op vermeldingen die logging mogelijk maken; deze inzendingen waren niet aanwezig.
Om dit probleem op te lossen, hebben we de strace-tool gebruikt om te ontdekken wat er "achter de schermen" gebeurde toen DG4ODBC in gebruik was.
Omdat DG4ODBC een bibliotheek is in plaats van een toepassing, moesten we een streepje toevoegen aan het Oracle-luisterproces (de "bovenliggende" toepassing van DG4ODBC) om de bewerkingen te traceren die verband houden met DG4ODBC.
Het traceerbestand liet zien welk exemplaar van odbcinst.ini logging inschakelde.
Dit zijn de stappen die we hebben genomen om strace aan de Oracle-luisteraar toe te voegen:
$ 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
(In een apart terminalvenster):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Wat Oracle "onder de motorkap" heeft gedaan, is nu vastgelegd in /tmp/mytracefile. We gebruikten vervolgens ctrl-c om strace te stoppen en zochten naar sql.log (het ODBC Driver Manager-logbestand) in /tmp/mytracefile. In ons geval toonde dit:
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