Recentemente, um cliente que estava usando nosso driver ODBC do SQL Server para conectar o Oracle ao SQL Server enfrentou um problema que se mostrou difícil de resolver.
O cliente recebia um log do ODBC Driver Manager sempre que o DG4ODBC era usado, com uma redução resultante no desempenho — o registro de chamadas ODBC tem um custo de desempenho. O cliente verificou o arquivo odbcinst.ini em busca de entradas que habilitam o log; essas entradas não estavam presentes.
Para ajudar a resolver esse problema, usamos a ferramenta strace para descobrir o que estava acontecendo "nos bastidores" quando DG4ODBC estava em uso.
Como o DG4ODBC é uma biblioteca em vez de um aplicativo, tivemos que anexar strace ao processo do ouvinte Oracle (aplicativo "pai" do DG4ODBC) para rastrear as operações associadas ao DG4ODBC.
O arquivo de rastreamento mostrou qual cópia do odbcinst.ini estava habilitando o log.
Estas são as etapas que tomamos para anexar strace ao ouvinte 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
(Em uma janela de terminal separada):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
O que a Oracle fez "nos bastidores" agora é capturado em /tmp/mytracefile. Em seguida, usamos ctrl-c para parar o strace e procuramos por sql.log (o arquivo de log do Gerenciador de Driver ODBC) em /tmp/mytracefile. No nosso caso, isso mostrou:
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 
