使用ODBC Trace或Oracle Trace查找錯誤原因？

Question

我有第三方Windows服務，它控制/監視設備並更新Oracle數據庫。他們的服務偶爾會報告有關數據庫中的行/列的錯誤，但是不會給出底層的數據庫錯誤，並且他們的服務需要重新啓動並且一切正常。目前的懷疑是來自我們的應用程序/服務的讀/寫這些相同的表/行的東西會干擾 - 即某種阻塞/鎖定。我懷疑他們的系統中存在某種泄漏，因爲它每週發生一次，但我們的系統從不需要像這樣重新啓動。

我試圖讓DBA在Oracle（10g）中運行一個跟蹤運行，但是這使得我們的應用程序無法訪問Oracle數據庫。我們的系統使用Oracle ODP客戶端或Microsoft客戶端（較舊的程序）以及同一服務器（Web應用程序或服務）或其他控制工作站訪問Oracle中的Oracle。第三方服務通過此服務器上的ODBC連接到Oracle。我也嘗試運行一個ODBC跟蹤（因爲那隻會是來自第三方服務的活動），但根本沒有得到任何跟蹤文件。

所以我試圖找到一種方法來獲取ODBC跟蹤工作或我需要注意的東西，以便Oracle跟蹤不會殺死我的服務器。

我正在尋找甲骨文正在返回到第三方服務的一個無法理解的錯誤，所以我可以告訴我們是否干涉他們以某種方式訪問​​數據。

Answer 1

如果數據庫中的某個塊損壞「錯誤」，則應該在警報日誌中顯示爲ORA-01578錯誤。我會在歸檔日誌中搜索ORA-錯誤，然後將其與所報告的客戶端錯誤上的時間戳進行比較。這是對「壞」定義的假設。發佈確切的錯誤消息會更好。

數據庫中的毛毯跟蹤是一件棘手的事情，因爲它往往會影響整個應用程序的性能。將它擱置一整個星期可能是不可行的。我還發現在一種情況下（不能記住確切的情況），開啓跟蹤修復了錯誤。

我以前用過的一種方法是添加sql語句來改變會話並打開sqltrace。這取決於以某種方式修改代碼的能力。取決於應用程序，這可能或不可能。

另一種方法是使用DBA來識別會話並打開該會話的sql跟蹤。此外，如果您可以識別有問題的SQL語句和參數值，則可以在服務外複製問題。

我發現大多數ORM都避免傳遞ORA-錯誤。但是，它通常會在相關的ORM錯誤中登錄到應用程序服務器層。

我已經使用這些方法和這些方法的變體來解決應用程序中的錯誤。我希望這是有用的。