Gần đây, một khách hàng đang sử dụng trình điều khiển SQL Server ODBC của chúng tôi để kết nối Oracle với SQL Server, đã gặp phải một sự cố khó giải quyết.
Khách hàng nhận được nhật ký Trình quản lý trình điều khiển ODBC bất cứ khi nào DG4ODBC được sử dụng, dẫn đến việc kéo theo hiệu suất - việc ghi nhật ký các cuộc gọi ODBC có chi phí hiệu suất. Khách hàng đã kiểm tra tệp odbcinst.ini để tìm các mục nhập cho phép ghi nhật ký; những mục này không có mặt.
Để giúp giải quyết vấn đề này, chúng tôi đã sử dụng công cụ strace để khám phá những gì đang diễn ra ở "hậu trường" khi DG4ODBC được sử dụng.
Bởi vì DG4ODBC là một thư viện chứ không phải là một ứng dụng, chúng tôi phải đính kèm quá trình nghe Oracle (ứng dụng "mẹ" của DG4ODBC) để theo dõi các hoạt động liên quan đến DG4ODBC.
Tệp theo dõi cho thấy bản sao nào của odbcinst.ini đang cho phép ghi nhật ký.
Đây là các bước chúng tôi đã thực hiện để đính kèm lạc vào trình nghe 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
(Trong một cửa sổ đầu cuối riêng biệt):
$ ./sqlplus / as sysdba $ select * from mytable@mylink;
Những gì Oracle đã làm "chui" bây giờ được ghi lại trong / tmp / mytracefile. Sau đó, chúng tôi sử dụng ctrl-c để ngăn chặn và tìm kiếm sql.log (tệp nhật ký Trình quản lý trình điều khiển ODBC) trong / tmp / mytracefile. Trong trường hợp của chúng tôi, điều này cho thấy:
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