ORA-30036 间歇性发生答案

【问题标题】：ORA-30036 happen intermittentlyORA-30036 间歇性发生
【发布时间】：2015-04-30 15:47:14
【问题描述】：

我有一个存储过程，可以进行非常大的更新。有时作业失败并出现错误ORA-30036 Unable to extend segment by 8 in undo tablespace 'undotbs2'

但几个小时后，我们重新运行了这项工作并成功完成。

我检查并发现 undotbs2 已经将 AUTOEXTENSIBLE 设置为 YES，大小为 3 GB，所以我猜 undo 表空间已经有相当大的大小，并且已经打开了自动空间管理。

我的问题是，为什么我们重新运行后它会成功完成？是不是因为同时有其他事务在使用undotbs2？对于这个错误，Oracle 提到“另一种方法是等到活动事务提交。”，“活动事务”是指除了存储过程之外发生的其他事务/sql 吗？

Oracle 版本为 11.2.0.1.0

谢谢

【问题讨论】：

表空间/数据文件是自动扩展的，但它是否达到了它的最大大小（来自dba_data_files.maxbytes，或dba_tablespaces.maxsize），并且不能超过3GB？是的，其他会话可能正在使用它（这就是“其他事务”所指的内容），但在增加大小限制之前，可能值得找出其他正在运行的内容以及正在使用空间的内容。

【解决方案1】：

看起来您的 UNDO 表空间已到达它MAXSIZE。如果您有一个冗长的事务与其他冗长的事务一起进行，则可能会发生这种情况。

Oracle 使用UNDO 表空间来保存事务发出ROLLBACK 后恢复数据所需的信息。也就是说，它的使用取决于在任何给定时刻有多少活动事务，以及每个事务正在更改多少信息。

正如您所经历的那样，表空间的最终使用/大小可能是非常随机的。

解决方案可能是：

【讨论】：

是的，这是一个漫长的交易。不同的消息来源还提到在两者之间添加COMMIT 可能会导致ORA-01555 snapshot too old 错误。你能解释一下这个现象吗？
Here 很好地解释了当长时间运行的事务导致 ORA-01555 错误时发生的事情。
还有一件事——我认为频繁提交不会解决ORA-01555，因为这与长时间运行的查询或打开很长时间的 CURSOR 相当相关。除非您在每次 COMMIT 后关闭并重新打开 CURSOR，否则仅发出 COMMIT 不会使 ORA-01555 消失。