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