26

我有一系列脚本在托管 oracle 10g 的 AIX 服务器上作为 nohup 并行运行。这些脚本是由其他人编写的，旨在同时执行。所有脚本都在表上执行更新。我收到错误消息，

ORA-00060: 等待资源时检测到死锁

当我为此搜索时，我发现 http://www.dba-oracle.com/t_deadly_perpetual_embrace_locks.htm

即使脚本同时对同一个表执行更新，它们也会对由WHERE子句确定的表的不同记录执行更新，并且它们之间没有记录重叠。

那么这会导致错误吗？

无论在表的何处执行更新，都会发生此错误吗？

我是否应该始终避免对表进行并发更新？

PL/SQL successfully completed奇怪的是，在上面引用的错误之后，我还在 nohup.out 日志上找到了 。

这是否意味着 oracle 已从死锁中恢复并成功完成更新，或者我应该连续重新运行这些脚本吗？欢迎任何帮助。

提前致谢。

4

4 回答 4

32

我最近正在努力解决类似的问题。事实证明，数据库缺少外键索引。这导致 Oracle 锁定了比要求更多的记录，这很快导致了高并发期间的死锁。

这是一篇优秀的文章，其中包含许多关于如何修复死锁的详细信息、建议和详细信息： http ://www.oratechinfo.co.uk/deadlocks.html#unindex_fk

于 2010-10-25T14:55:04.123 回答
13

您不仅可以在行锁上遇到死锁，例如看到这个。脚本可能会竞争其他资源，例如索引块。

过去，我通过设计并行性来解决这个问题，即不同的实例正在处理不太可能影响彼此靠近的块的部分工作负载；例如，对于一个大表的更新，而不是使用类似的东西来设置并行从属MOD(n,10)，我会使用TRUNC(n/10)这意味着每个从属都在一组连续的数据上工作。

当然，还有更好的方法来拆分作业以实现并行性，例如DBMS_PARALLEL_EXECUTE。

不知道为什么你得到“PL/SQL 成功完成”，也许你的脚本正在处理异常？

于 2010-06-19T12:57:14.870 回答
5

我也遇到了这个问题。我不知道实际发生的事情的技术细节。但是，在我的情况下，根本原因是 Oracle 数据库中存在级联删除设置，而我的 JPA/Hibernate 代码也在尝试执行级联删除调用。所以我的建议是确保你确切地知道发生了什么。

于 2011-02-03T02:54:41.390 回答
1

我正在测试一个在块中有多个UPDATE语句的函数。IF-ELSE

UPDATE我正在测试所有可能的路径，因此每次在再次运行该函数之前，我都会使用“手动”语句将表重置为之前的值。

我注意到问题会在这些UPDATE声明之后发生；

我在用于重置表COMMIT;的语句之后添加了一个，从而解决了问题。UPDATE

所以，请注意，问题不在于函数本身......

于 2019-04-07T07:23:12.217 回答