Använder strace som ett DG40DBC-felsökningsverktyg på Linux

Nyligen upplevde en kund som använde vår SQL Server ODBC-drivrutin för att ansluta Oracle till SQL Server ett problem som visade sig vara svårt att komma till botten med.

Kunden fick en ODBC Driver Manager-logg närhelst DG4ODBC användes, med en följd av prestanda – loggning av ODBC-samtal har en prestationskostnad. Kunden hade kontrollerat odbcinst.ini-filen för poster som möjliggör loggning; dessa poster var inte närvarande.

För att lösa det här problemet använde vi strace-verktyget för att upptäcka vad som pågick "bakom kulisserna" när DG4ODBC användes.

Eftersom DG4ODBC är ett bibliotek snarare än en applikation, var vi tvungna att koppla strace till Oracle-lyssnarprocessen (DG4ODBC:s "förälder"-applikation) för att spåra operationerna som är associerade med DG4ODBC.

Spårningsfilen visade vilken kopia av odbcinst.ini som aktiverade loggning.

Det här är stegen vi tog för att fästa spår till Oracle-lyssnaren:

$ 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 ett separat terminalfönster):

$ ./sqlplus / as sysdba

$ select * from mytable@mylink;

Vad Oracle har gjort "under huven" fångas nu i /tmp/mytracefile. Vi använde sedan ctrl-c för att stoppa strace och sökte efter sql.log (loggfilen för ODBC Driver Manager) i /tmp/mytracefile. I vårt fall visade detta:

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