使用 ODBC Trace 或 Oracle Trace 查找错误原因？
我有一个第三方 Windows 服务，用于控制/监视设备并更新 Oracle 数据库。他们的服务偶尔会报告数据库中的行/列“坏”的错误，但不会给出底层数据库错误，并且他们的服务需要重新启动，一切都很好。当前的怀疑是我们的应用程序/服务中读取/写入相同表/行的某些内容正在干扰 - 即某种阻塞/锁定。我怀疑他们的系统存在某种泄漏，因为这种情况大约每周发生一次，但我们的系统从来不需要像这样重新启动。
我尝试让 DBA 在 Oracle (10g) 中运行跟踪，但这导致我们的应用程序无法访问 Oracle 数据库。我们的系统使用 Oracle ODP 客户端或 Microsoft 客户端（旧程序）并在同一服务器（Web 应用程序或服务）上或从其他控制工作站访问 .NET 中的 Oracle。第三方服务通过该服务器上的 ODBC 连接到 Oracle。我还尝试运行 ODBC 跟踪（因为这只是来自第三方服务的活动），但根本没有在跟踪文件中获取任何内容。
因此，我试图找到一种方法来使 ODBC 跟踪正常工作，或者我需要注意什么，以便 Oracle 跟踪不会杀死我的服务器。
我正在寻找 Oracle 返回给第三方服务的 unserlying 错误，以便我可以判断我们是否以某种方式干扰了他们对数据的访问。
I have a third party Windows service which controls/monitors equipment and updates an Oracle database. Their services occasionally report an error about a row/column in the database being "bad" but do not give the underlying database error, and their services need to be restarted and everything is fine. The current suspicion is that something from our applications/services which read/write to those same tables/rows are interfering - i.e. some kind of blocking/locking. I suspect that there is some sort of leak in their system since it happens about once a week, but our systems never need any re-starting like this.
I attempted to have the DBA run a trace run in Oracle (10g), but this managed to make our apps unable to access the Oracle database. Our systems access Oracle in .NET, either using the Oracle ODP client or Microsoft client (older programs) and on this same server (either web apps or services) or from other control workstations. The third-party services connects to Oracle via ODBC on this server. I also attempted to run a ODBC trace (since that would only be activity from the third-party service), but didn't get anything in the trace file at all.
So I'm trying to find a way to either get ODBC tracing working or what I need to look out for so that the Oracle trace doesn't kill my server.
I'm looking for the undserlying error which Oracle is returning to the thrid-party service so I can tell if we are interfering with their access to the data in some way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果数据库中的某个块被“坏”损坏，则应在警报日志中显示为 ORA-01578 错误。我会在存档日志中搜索 ORA 错误，然后将其与报告的客户端错误的时间戳进行比较。这是对“坏”定义的假设。最好能发布准确的错误消息。
数据库中的全面跟踪是一件棘手的事情，因为它往往会影响整个应用程序的性能。并且将其保留整整一周可能是不可行的。我还发现在一种情况下（不记得确切的情况）打开跟踪修复了错误。
我过去使用过的一种方法是添加 sql 语句来更改会话并打开 sqltrace。这是基于以某种方式修改代码的能力。根据应用程序，这可能可行，也可能不可能。
另一种方法是与 DBA 合作来识别会话并打开该会话的 sql 跟踪。此外，如果您可以识别有问题的 sql 语句和参数值，您也许能够在服务之外复制问题。
我发现大多数 ORM 都避免将 ORA 错误传回。但是，它通常会与关联的 ORM 错误一起记录在应用程序服务器层中。
我已经使用这些方法和这些方法的变体来解决应用程序中的错误。我希望这有用。
If a block in the database is corrupted "Bad" this should show up in the alert logs as an ORA-01578 error. I would search the archive log for the ORA- error and then compare that with the time stamp on the client error being reported. This is making the assumption of the definition of "Bad". It would be better to have the exact error messages posted.
Blanket tracing in the database is a tricky thing as it will tend to affect the performance of your entire application. And leaving it on for an entire week may not be feasible. I have also found in one case (cant remember the exact circumstance) where turning on tracing fixed the error.
One method I have used in the past is to add the sql statement to alter the session and turn on sqltrace. This is predicated on the ability to modify the code in some way. Depending on the application this may or may not be possible.
Another method would be to work with the DBA to identify the session and turn on sql trace for that session. Also if you can identify the offending sql statements and parameter values you may be able to replicate the problem outside the service.
I have found most ORM's avoid passing the ORA- error back. However it is typically logged in the application server layer with the associated ORM error.
I have used these method and variations of these method to trouble shoot errors in the application. I hope this is useful.