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