Използване на strace като DG40DBC инструмент за отстраняване на грешки в Linux

Наскоро клиент, който използваше нашия SQL Server ODBC драйвер, за да свърже Oracle към SQL Server, изпита проблем, който се оказа труден за откриване.

Клиентът получаваше дневник на ODBC Driver Manager всеки път, когато се използва DG4ODBC, с последващо забавяне на производителността — регистрирането на ODBC повиквания има цена за производителност. Клиентът е проверил файла odbcinst.ini за записи, които позволяват регистриране; тези записи не присъстваха.

За да помогнем за разрешаването на този проблем, използвахме инструмента strace, за да открием какво се случва „зад кулисите“, когато се използваше DG4ODBC.

Тъй като DG4ODBC е библиотека, а не приложение, трябваше да прикачим strace към процеса на слушател на Oracle (приложението „родител“ на DG4ODBC), за да проследим операциите, свързани с DG4ODBC.

Файлът за проследяване показва кое копие на odbcinst.ini позволява регистрирането.

Това са стъпките, които предприехме, за да прикачим strace към слушателя на 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

(В отделен прозорец на терминала):

$ ./sqlplus / as sysdba

$ select * from mytable@mylink;

Това, което Oracle направи "под капака", сега се записва в /tmp/mytracefile. След това използвахме ctrl-c, за да спрем strace и потърсихме sql.log (регистрационният файл на ODBC Driver Manager) в /tmp/mytracefile. В нашия случай това показва:

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