Niedawno klient, który używał naszego sterownika ODBC SQL Server do łączenia Oracle z SQL Server, napotkał problem, który okazał się trudny do rozwiązania.
Klient otrzymywał dziennik Menedżera sterowników ODBC za każdym razem, gdy był używany DG4ODBC, co powodowało spadek wydajności — rejestrowanie wywołań ODBC wiąże się z kosztami wydajności. Klient sprawdził plik odbcinst.ini pod kątem wpisów umożliwiających rejestrowanie; te wpisy nie były obecne.
Aby rozwiązać ten problem, użyliśmy narzędzia strace, aby odkryć, co działo się „za kulisami”, gdy używany był DG4ODBC.
Ponieważ DG4ODBC jest biblioteką, a nie aplikacją, musieliśmy dołączyć strace do procesu nasłuchującego Oracle (aplikacja „nadrzędna” DG4ODBC), aby śledzić operacje związane z DG4ODBC.
Plik śledzenia pokazał, która kopia odbcinst.ini umożliwiała rejestrowanie.
Oto kroki, które podjęliśmy, aby dołączyć strace do programu nasłuchującego 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
(W osobnym oknie terminala):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
To, co Oracle zrobiło „pod maską”, jest teraz rejestrowane w /tmp/mytracefile. Następnie użyliśmy ctrl-c, aby zatrzymać strace i wyszukaliśmy plik sql.log (plik dziennika Menedżera sterowników ODBC) w /tmp/mytracefile. W naszym przypadku pokazało to:
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 
