oracle redo undo.docVIP

通常对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中生成了undo块。 l???????? 已经在SGA中生成了已修改数据块。 l???????? 已经在SGA中生成了对于前两项的缓存redo。 l???????? 取决于前三项的大小，以及这些工作花费的时间，前面的每个数据（或某些数据）可能已经刷新输出到磁盘。 l???????? 已经得到了所需的全部锁。 执行COMMIT时，余下的工作只是： l???????? 为事务生成一个SCN。如果你还不熟悉SCN，起码要知道，SCN是Oracle使用的一种简单的计时机制，用于保证事务的顺序，并支持失败恢复。SCN还用于保证数据库中的读一致性和检查点。可以把SCN看作一个钟摆，每次有人COMMIT时，SCN都会增1. l???????? LGWR将所有余下的缓存重做日志条目写到磁盘，并把SCN记录到在线重做日志文件中。这一步就是真正的COMMIT。如果出现了这一步，即已经提交。事务条目会从V$TRANSACTION中“删除”，这说明我们已经提交。 l???????? V$LOCK中记录这我们的会话持有的锁，这些所都将被释放，而排队等待这些锁的每一个人都会被唤醒，可以继续完成他们的工作。 l???????? 如果事务修改的某些块还在缓冲区缓存中，则会以一种快速的模式访问并“清理”。块清除（Block cleanout）是指清除存储在数据库块首部的与锁相关的信息。实质上讲，我们在清除块上的事务信息，这样下一个访问这个块的人就不用再这么做了。我们采用一种无需生成重做日志信息的方式来完成块清除，这样可以省去以后的大量工作（在下面的“块清除”一节中将更全面地讨论这个问题）。 ? 可以看到，处理COMMIT所要做的工作很少。其中耗时最长的操作要算LGWR执行的活动（一般是这样），因为这些磁盘写是物理磁盘I/O。不过，这里LGWR花费的时间并不会太多，之所以能大幅减少这个操作的时间，原因是LGWR一直在以连续的方式刷新输出重做日志缓冲区的内容。在你工作期间，LGWR并非缓存这你做的所有工作；实际上，随着你的工作的进行，LGWR会在后台增量式地刷新输出重做日志缓冲区的内容。这样做是为了避免COMMIT等待很长时间来一次性刷新输出所有的redo。 因此，即使我们