oracle - 使用 ODBC Trace 或 Oracle Trace 查找错误原因？

Question

我有一个第三方 Windows 服务，它控制/监视设备并更新 Oracle 数据库。他们的服务偶尔会报告关于数据库中的行/列“坏”的错误，但不会给出底层数据库错误，他们的服务需要重新启动，一切正常。当前的怀疑是我们的应用程序/服务中读取/写入相同表/行的某些内容正在干扰 - 即某种阻塞/锁定。我怀疑他们的系统中存在某种泄漏，因为它大约每周发生一次，但我们的系统从不需要像这样重新启动。

我试图让 DBA 在 Oracle (10g) 中运行跟踪，但这设法使我们的应用程序无法访问 Oracle 数据库。我们的系统在 .NET 中访问 Oracle，使用 Oracle ODP 客户端或 Microsoft 客户端(旧程序)并在同一服务器上(Web 应用程序或服务)或从其他控制工作站访问。第三方服务通过此服务器上的 ODBC 连接到 Oracle。我还尝试运行 ODBC 跟踪(因为这只是来自第三方服务的事件)，但在跟踪文件中根本没有得到任何信息。

所以我试图找到一种方法来让 ODBC 跟踪工作或我需要注意什么，以便 Oracle 跟踪不会杀死我的服务器。

我正在寻找 Oracle 返回给第三方服务的严重错误，以便我可以判断我们是否以某种方式干扰了他们对数据的访问。

Answer 1

如果数据库中的一个块被损坏“坏”，这应该在警报日志中显示为 ORA-01578 错误。我会在存档日志中搜索 ORA 错误，然后将其与报告的客户端错误的时间戳进行比较。这是对“坏”定义的假设。最好发布确切的错误消息。

数据库中的一揽子跟踪是一件棘手的事情，因为它往往会影响整个应用程序的性能。将它保持一整周可能是不可行的。我还发现在一种情况下(不记得确切的情况)，打开跟踪修复了错误。

我过去使用的一种方法是添加 sql 语句来更改 session 并打开 sqltrace。这是基于以某种方式修改代码的能力。根据应用程序，这可能或不可能。

另一种方法是与 DBA 一起识别 session 并为该 session 打开 sql 跟踪。此外，如果您可以识别出有问题的 sql 语句和参数值，您就可以在服务之外复制问题。

我发现大多数 ORM 都避免将 ORA- 错误传回。然而，它通常与相关的 ORM 错误一起记录在应用程序服务器层中。

我已经使用这些方法和这些方法的变体来解决应用程序中的错误。我希望这是有用的。