Použití strace jako nástroje pro ladění DG40DBC v systému Linux

Nedávno se u zákazníka, který používal náš SQL Server ODBC ovladač k připojení Oracle k SQL Serveru, objevil problém, který se ukázal být obtížně řešitelný.

Zákazník dostával protokol ODBC Driver Manager při každém použití DG4ODBC, což mělo za následek snížení výkonu – protokolování hovorů ODBC má náklady na výkon. Zákazník zkontroloval soubor odbcinst.ini pro záznamy, které umožňují protokolování; tyto položky nebyly přítomny.

Abychom tento problém vyřešili, použili jsme nástroj strace, abychom zjistili, co se dělo „v zákulisí“, když bylo používáno DG4ODBC.

Protože DG4ODBC je spíše knihovna než aplikace, museli jsme připojit strace k procesu naslouchání Oracle ("nadřazená" aplikace DG4ODBC), abychom mohli sledovat operace spojené s DG4ODBC.

Trasovací soubor ukázal, která kopie odbcinst.ini umožňovala protokolování.

Toto jsou kroky, které jsme podnikli pro připojení strace k posluchači 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

(V samostatném okně terminálu):

$ ./sqlplus / as sysdba

$ select * from mytable@mylink;

To, co Oracle udělal „pod kapotou“, je nyní zachyceno v /tmp/mytracefile. Potom jsme použili ctrl-c k zastavení strace a hledali sql.log (soubor protokolu ODBC Driver Manager) v /tmp/mytracefile. V našem případě to ukázalo:

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