通常对undo 有一个误解，认为undo 用于数据库物理地恢复到执行语句或事务之前的样子，但实际上并非如此。数据库只是逻辑地恢复到原来的样子，所有修改都被逻辑地取消，但是数据结构以及数据库块本身在回滚后可能大不相同。原因在于：在所有多用户系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要功能之一就是协调对数据的并发访问。也许我们的事务在修改一些块，而一般来讲往往会有许多其他的事务也在修改这些块。因此，不能简单地将一个块放回到我们的事务开始前的样子，这样会撤销其他人（其他事务）的工作！ 9.3 redo 和 undo 如何协作？ 有意思的是，尽管 undo 信息存储在undo 表空间或undo 段中，但也会受到redo 的保护。换句话说，会把 undo 数据当成是表数据或索引数据一样，对undo 的修改会生成一些redo，这些 redo 将计入日志。为什么会这样呢？稍后在讨论系统崩溃时发生的情况时将会解释它，到时你会明白了。将 undo 数据增加到undo 段中，并像其他部分的数据一样在缓冲区缓存中得到缓存。另外这些 redo 信息还用于在实例恢复时重建 SGA 内存的状态。 9.3.1 COMMIT 做什么？ COMMIT 通常是一个非常快的操作，而不论事务大小如何。你可能认为，一个事务越大（换句话说，它影响的数据越多），COMMIT 需要的时间就越长。不是这样的。不论事务有多大，COMMIT 的响应时间一般都很“平”（flat，可以理解为无高低变化）。这是因为COMMIT 并没有太多的工作去做，不过它所做的确实至关重要。 这一点很重要，之所以要了解并掌握这个事实，原因之一是：这样你就能心无芥蒂地让事务有足够的大小。一种错误的信念认为分批提交可以节省稀有的系统资源，而实际上这只是增加了资源的使用。如果只在必要时才提交（即逻辑工作单元结束时），不仅能提高性能，还能减少对共享资源的竞争（日志文件、各种内部闩等）。 分批提交 COMMIT 的开销存在两个因素： l 显然会增加与数据库的往返通信。如果每个记录都提交，生成的往返通信量就会大得多。 l 每次提交时，必须等待 redo 写至磁盘。这会导致“等待”。在这种情况下，等待称为“日志文件同步”（log file sync）。 为什么 COMMIT 的响应时间相当“平”，而不论事务大小呢？在数据库中执行COMMIT之前，困难的工作都已经做了。我们已经修改了数据库中的数据，所以99.9%的工作都已经完成。例如，已经发生了以下操作： l 已经在SGA 中生成了 ...
