我有第三方Windows服务，它控制/监控设备并更新Oracle数据库。他们的服务偶尔会报告有关数据库中的行/列的错误，但不会给出底层数据库错误，并且需要重新启动它们的服务，一切都很好。当前的怀疑是我们的应用程序/服务中读/写那些相同的表/行的东西是干扰的 - 即某种阻塞/锁定。我怀疑他们的系统中存在某种泄漏，因为它每周发生一次，但我们的系统从不需要像这样重新启动。
我试图让DBA在Oracle（10g）中运行跟踪运行，但这使我们的应用程序无法访问Oracle数据库。我们的系统使用Oracle ODP客户端或Microsoft客户端（旧程序）和同一服务器（Web应用程序或服务）或其他控制工作站访问.NET中的Oracle。第三方服务通过此服务器上的ODBC连接到Oracle。我还尝试运行ODBC跟踪（因为那只是来自第三方服务的活动），但根本没有在跟踪文件中获得任何内容。
所以我试图找到一种方法来使ODBC跟踪工作或我需要注意什么，以便Oracle跟踪不会杀死我的服务器。
我正在寻找Oracle返回到第三方服务的非法错误，因此我可以判断我们是否在某种程度上干扰了他们对数据的访问。
答案 0 :(得分：0)
如果数据库中的某个块已损坏“错误”，则此错误应显示在警报日志中。我将在归档日志中搜索ORA-错误，然后将其与报告的客户端错误上的时间戳进行比较。这就是假设“坏”的定义。最好发布确切的错误消息。
数据库中的毯子跟踪是一件很棘手的事情，因为它会影响整个应用程序的性能。将其保留一整周可能不太可行。我还发现了一个案例（无法记住确切的情况），其中启用跟踪修复了错误。
我过去使用的一种方法是添加sql语句来改变会话并打开sqltrace。这取决于以某种方式修改代码的能力。根据应用情况，这可能是也可能是不可能的。
另一种方法是使用DBA来识别会话并为该会话启用sql跟踪。此外，如果您可以识别有问题的sql语句和参数值，则可以在服务之外复制问题。
我发现大多数ORM都避免将ORA错误传回去。但是，它通常会在应用程序服务器层中记录，并显示相关的ORM错误。
我已经使用这些方法和这些方法的变体来解决应用程序中的错误。我希望这很有用。