【发布时间】:2012-01-30 15:58:29
【问题描述】:
我有一个第三方 Windows 服务来控制/监控设备并更新 Oracle 数据库。他们的服务偶尔会报告关于数据库中的行/列“坏”的错误,但不会给出底层数据库错误,并且他们的服务需要重新启动并且一切都很好。当前的怀疑是,我们的应用程序/服务中读取/写入这些相同表/行的某些东西正在干扰 - 即某种阻塞/锁定。我怀疑他们的系统中存在某种泄漏,因为它大约每周发生一次,但我们的系统永远不需要像这样重新启动。
我试图让 DBA 在 Oracle (10g) 中运行跟踪,但这设法使我们的应用程序无法访问 Oracle 数据库。我们的系统在 .NET 中使用 Oracle ODP 客户端或 Microsoft 客户端(旧程序)以及在同一服务器(Web 应用程序或服务)上或从其他控制工作站访问 Oracle。第三方服务通过此服务器上的 ODBC 连接到 Oracle。我还尝试运行 ODBC 跟踪(因为这只是来自第三方服务的活动),但在跟踪文件中根本没有得到任何东西。
所以我正在尝试找到一种方法来让 ODBC 跟踪正常工作,或者我需要注意什么,以便 Oracle 跟踪不会杀死我的服务器。
我正在寻找 Oracle 正在返回给第三方服务的潜在错误,以便判断我们是否以某种方式干扰了他们对数据的访问。
【问题讨论】:
-
哎哟!如果 Oracle 跟踪阻止您使用数据库,那么这不是开始的地方吗?您可以证明自己有问题,而您实际上并不知道第三方的错误是他们的错还是“您的错”。
-
哪个第三方没有给出潜在的 ORA 错误?这似乎非常可疑(要么写得不好,要么在某处的某个日志中)
-
也许这些答案之一会有所帮助:stackoverflow.com/questions/492705/…
-
您的 DBA 是否进行了服务器或客户端跟踪?如果它是服务器端跟踪,请尝试使用客户端跟踪,方法是在进行 ODBC 调用的服务器上的 sqlnet.ora 文件中添加 TRACE_LEVEL_CLIENT = 16,并查看 ORACLE_HOME \network 中是否出现任何内容\痕迹\。另外,数据库的警报日志中是否出现任何内容?
-
对于这种类型的 ODBC 跟踪,您需要在 ODBC 管理员的“跟踪”选项卡中启用机器范围的跟踪。您需要在第三方内容启动之前启用此功能,否则您将在输出日志中一无所获。确保您的日志文件路径指向具有大量可用空间的磁盘,因为跟踪会占用大量可用空间。