Di recente, un cliente che stava utilizzando il nostro driver ODBC di SQL Server per connettere Oracle a SQL Server, ha riscontrato un problema che si è rivelato difficile da risolvere.
Il cliente riceveva un registro ODBC Driver Manager ogni volta che veniva utilizzato DG4ODBC, con un conseguente rallentamento delle prestazioni:la registrazione delle chiamate ODBC ha un costo in termini di prestazioni. Il cliente ha verificato la presenza di voci che abilitano la registrazione nel file odbcinst.ini; queste voci non erano presenti.
Per risolvere questo problema, abbiamo utilizzato lo strumento strace per scoprire cosa stava succedendo "dietro le quinte" quando DG4ODBC era in uso.
Poiché DG4ODBC è una libreria anziché un'applicazione, abbiamo dovuto allegare strace al processo listener Oracle (l'applicazione "principale" di DG4ODBC) per tracciare le operazioni associate a DG4ODBC.
Il file di traccia mostrava quale copia di odbcinst.ini stava abilitando la registrazione.
Questi sono i passaggi che abbiamo adottato per collegare strace al listener 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
(In una finestra terminale separata):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Ciò che Oracle ha fatto "sotto il cofano" è ora acquisito in /tmp/mytracefile. Abbiamo quindi utilizzato ctrl-c per interrompere strace e cercato sql.log (il file di registro di ODBC Driver Manager) in /tmp/mytracefile. Nel nostro caso, questo ha mostrato:
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 
