【发布时间】：2011-06-04 06:52:59
【问题描述】：
我不是 DBA，我只是想了解一下 Oracle 的多版本并发模型。
当启动一个 DML 操作时，MVCC 协议的第一步是绑定一个 undo 段。问题是为什么一个撤消段只能服务于一个活动事务？
感谢您的宝贵时间~~
【问题讨论】：
-
对不起。由于我的错误点击，我在完成之前提交了我的问题。
【发布时间】：2011-06-04 06:52:59
【问题描述】：
多版本并发可能是涉及 Oracle 时要掌握的最重要的概念。程序员即使不想成为 DBA，也能理解它。
除此之外还有几个方面，但它们都归结为效率：撤消管理是开销，因此最大限度地减少专用于它的周期数有助于提高数据库的整体性能。
- 一个事务可以由许多语句组成并产生很多撤消：它可能插入一行，它可能删除三万行。最好在开始时分配一个空的 UNDO 块，而不是不断寻找有足够空间的部分填充块。
- 因此，共享撤消块将需要内核以更精细的粒度跟踪使用情况，这只会增加复杂性。
- 当事务完成时，撤消被释放（除非，见下一点）。事务使用的块越少，需要重置的锁存器就越少。另外，如果块是共享的，我们将不得不释放块的碎片，这只是更多的努力。
- MVCC 的关键在于读取一致性。这意味着运行时间较长的查询返回的所有记录都将显示为查询开始时的状态。因此，如果我在 EMP 表上发出一个 SELECT 语句，它需要 15 分钟才能运行，并且在中途你提交了所有工资的更新，我不会看到你的更改，数据库通过从你的事务使用的块中检索撤消数据来做到这一点.同样，当所有撤消数据都放在一个或两个块中时，这会容易得多。
【讨论】：
-
我认为第 4 点不太正确。其他会话将使用第一个会话更新创建的撤消来保持读取一致性，但不能保证在这些查询处于活动状态时不会重用这些撤消块。重复使用此类撤消会导致臭名昭著的“快照太旧”错误。
“为什么一个撤消段只能服务于一个活动事务？”
这只是一个设计决策。这就是撤消段的设计方式。我想这样做是为了解决以前的回滚机制可能出现的一些问题。
回滚（仍然可用，但不推荐使用撤消）包括由 DBA 显式创建回滚段，并且可以将多个事务分配给单个回滚段。这有一些缺点，最明显的是，如果分配给给定段的一个事务生成足够的回滚数据，该段已满（并且不能再扩展），那么使用同一段的其他事务将无法执行任何会生成的操作回滚数据。
我推测新撤消功能的一个设计目标是防止这种事务间依赖。因此，他们设计了这种机制，以便 DBA 调整大小并创建撤消表空间，但其中的段管理由 Oracle 内部完成。这允许每个事务使用专用段。如果表空间已满（并且无法自动扩展），它们仍然可能相互造成问题，但在段级别，一个事务不可能给另一个事务造成问题。
【讨论】：