हाल ही में, एक ग्राहक जो Oracle को SQL सर्वर से जोड़ने के लिए हमारे SQL सर्वर ODBC ड्राइवर का उपयोग कर रहा था, उसे एक समस्या का सामना करना पड़ा जिसकी तह तक जाना मुश्किल साबित हुआ।
जब भी DG4ODBC का उपयोग किया गया था, ग्राहक को ODBC ड्राइवर मैनेजर लॉग मिल रहा था, जिसके परिणामस्वरूप प्रदर्शन पर असर पड़ता है - ODBC कॉल लॉगिंग की एक प्रदर्शन लागत होती है। लॉगिंग सक्षम करने वाली प्रविष्टियों के लिए ग्राहक ने odbcinst.ini फ़ाइल की जाँच की थी; ये प्रविष्टियां मौजूद नहीं थीं।
इस समस्या को हल करने में मदद करने के लिए, हमने यह पता लगाने के लिए स्ट्रेस टूल का उपयोग किया कि "पर्दे के पीछे" क्या चल रहा था जब DG4ODBC उपयोग में था।
क्योंकि DG4ODBC एक एप्लिकेशन के बजाय एक लाइब्रेरी है, हमें DG4ODBC से जुड़े ऑपरेशनों का पता लगाने के लिए Oracle श्रोता प्रक्रिया (DG4ODBC के "पैरेंट" एप्लिकेशन) में स्ट्रेस संलग्न करना पड़ा।
ट्रेस फ़ाइल ने दिखाया कि odbcinst.ini की कौन सी प्रति लॉगिंग को सक्षम कर रही थी।
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
(एक अलग टर्मिनल विंडो में):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Oracle ने "हुड के नीचे" जो किया है वह अब /tmp/mytracefile में कैद हो गया है। फिर हमने स्ट्रेस को रोकने के लिए ctrl-c का उपयोग किया और /tmp/mytracefile में sql.log (ODBC ड्राइवर मैनेजर लॉग फ़ाइल) की खोज की। हमारे मामले में, यह दिखाया गया:
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 
