Recientemente, un cliente que estaba usando nuestro controlador ODBC de SQL Server para conectar Oracle a SQL Server, experimentó un problema que resultó difícil de resolver.
El cliente obtenía un registro de ODBC Driver Manager cada vez que se usaba DG4ODBC, lo que repercutía negativamente en el rendimiento:el registro de llamadas ODBC tiene un costo de rendimiento. El cliente había revisado el archivo odbcinst.ini en busca de entradas que permitieran el registro; estas entradas no estaban presentes.
Para ayudar a resolver este problema, usamos la herramienta strace para descubrir qué estaba pasando "detrás de escena" cuando se usaba DG4ODBC.
Debido a que DG4ODBC es una biblioteca en lugar de una aplicación, tuvimos que adjuntar strace al proceso de escucha de Oracle (la aplicación "principal" de DG4ODBC) para rastrear las operaciones asociadas con DG4ODBC.
El archivo de seguimiento mostró qué copia de odbcinst.ini estaba habilitando el registro.
Estos son los pasos que tomamos para adjuntar strace al oyente de 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
(En una ventana de terminal separada):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Lo que Oracle ha hecho "bajo el capó" ahora se captura en /tmp/mytracefile. Luego usamos ctrl-c para detener strace y buscamos sql.log (el archivo de registro de ODBC Driver Manager) en /tmp/mytracefile. En nuestro caso, esto mostró:
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 
