Oracle提交和回滚处理

     1.Commit（提交）

     作为一名开发人员，你应该深入了解COMMIT期间会做些什么。COMMIT通常是一个非常快的操作，而不论事务大小如何。

     你可能认为，一个事务越大（换句话说，它影响的数据越多），COMMIT需要的时间就越长。不是这样的。不论事务有多大，COMMIT的响应时间一般都很“平”（flat，可以理解为无高低变化）。这是因为COMMIT并没有太多的工作去做，不过它所做的确实至关重要。

     有些人认为限制事务的大小，一块一块地提交要比一次性提交要节省系统资源，其实 频繁的进行事务提交比一次性提交效率要低。我们已经知道，如果不使用绑定变量，而且频繁地完成硬解析，这会严重地降低并发性，原因是存在库缓存竞争和过量的CPU占用。即使转而使用绑定变量，如果过于频繁地软解析，也会带来大量的开销。COMMIT就是这样的一种操作（需要进行软解析），最好根据业务需求来确定事务的大小，而不是错误地为了减少数据库上的资源使用而“压缩”事务。

     那么，为什么COMMIT的响应时间相当“平”，而不论事务大小呢？在数据库中执行COMMIT之前，困难的工作都已经做了。我们已经修改了数据库中的数据，所以99.9%的工作都已经完成。例如，已经发生了以下操作：

     a. 已经在SGA中生成了undo块。

     b. 已经在SGA中生成了已修改数据块。

     c. 已经在SGA中生成了对于前两项的缓存redo。

     d. 取决于前三项的大小，以及这些工作花费的时间，前面的每个数据（或某些数据）可能已经刷新输出到磁盘。(比如redo信息会每隔3S刷新输出一次)

     e. 已经得到了所需的全部锁。

 

     执行COMMIT时，余下的工作只是：

     a. 为事务生成一个SCN。如果你还不熟悉SCN，起码要知道，SCN是Oracle使用的一种简单的计时机制，用于保证事务的顺序，并支持失败恢复。SCN还用于保证数据库中的读一致性和检查点。可以把SCN看作一个钟摆，每次有人COMMIT时，SCN都会增1.

     b. LGWR将所有余下的缓存重做日志条目写到磁盘，并把SCN记录到在线重做日志文件中。这一步就是真正的COMMIT。如果出现了这一步，即已经提交。事务条目会从V$TRANSACTION中“删除”，这说明我们已经提交。

     c. V$LOCK中记录着我们的会话持有的锁，这些所都将被释放，而排队等待这些锁的每一个人都会被唤醒，可以继续完成他们的工作。

     d. 如果事务修改的某些块还在缓冲区缓存中，则会以一种快速的模式访问并“清理”。块清除（Block cleanout）是指清除存储在数据库块首部的与锁相关的信息。实质上讲，我们在清除块上的事务信息，这样下一个访问这个块的人就不用再这么做了。我们采用一种无需生成重做日志信息的方式来完成块清除，这样可以省去以后的大量工作.

 

     可以看到，处理COMMIT所要做的工作很少。其中耗时最长的操作要算LGWR执行的活动（一般是这样），因为这些磁盘写是物理磁盘I/O。不过，这里LGWR花费的时间并不会太多，之所以能大幅减少这个操作的时间，原因是LGWR一直在以连续的方式刷新输出重做日志缓冲区的内容。在你工作期间，LGWR并非缓存这你做的所有工作；实际上，随着你的工作的进行，LGWR会在后台增量式地刷新输出重做日志缓冲区的内容。这样做是为了避免COMMIT等待很长时间来一次性刷新输出所有的redo。

 

 

     2.Rollback

     Rollback其实就是commit的逆操作，rollback主要做如下事情：

     a. 撤销已做的所有修改。其完成方式如下：从undo段读回数据，然后实际上逆向执行前面所做的操作，并将undo条目标记为已用。如果先前插入了一行，ROLLBACK会将其删除。如果更新了一行，回滚就会取消更新。如果删除了一行，回滚将把它再次插入。

     b. 会话持有的所有锁都将释放，如果有人在排队等待我们持有的锁，就会被唤醒。

     

     与此不同，COMMIT只是将重做日志缓冲区中剩余的数据刷新到磁盘。与ROLLBACK相比，COMMIT完成的工作非常少。这里的关键是，除非不得已，否则不会希望回滚。回滚操作的开销很大，因为你花了大量的时间做工作，还要花大量的时间撤销这些工作。除非你有把握肯定会COMMIT你的工作，否则干脆什么也别做。听上去这好像是一个常识，这是当然的了，既然不想COMMIT，又何苦去做所有这些工作！不过，我经常看到这样一些情况：开发人员使用一个“真正”的表作为临时表，在其中填入数据，得到这个表的报告，如何回滚，并删除表中的临时数据。下一节我会讨论真正的临时表，以及如何避免这个问题。