oracle 事务基本原理

恢复

  前一章介绍了RAC的备份，并且也谈到：我们不是为了备份而备份，而是为了恢复而备份。一个备份策略是否有效，并不依赖到底是冷备份还是热备份，也不在于采用的是物理备份还是逻辑备份，更不是取决于完全备份还是增量备份。这些内容只是从不同侧面影响备份”效率”，但实际企业更关注的是”效果”，也就是按照企业对宕机时间、数据损失容忍能力，备份策略是否能经得住各种极端环境的检验，换句话说就是在各种场景下，你的备份能够恢复到什么程度？会有多少数据损失？这就是本章和下一章要重点介绍的内容。

  这本书用两章内容介绍恢复，这一章介绍最经典的恢复技术-基于备份的恢复，包括完全恢复和不完全恢复。但是这种恢复动作比较大，需要关闭数据库，如果采用不完全恢复，还会有数据损失。因此Oracle 10g还提供了许多技巧性的恢复手段，能够避免宕机时间和减少数据损失，这些内容将在第10章中介绍。

  在学习具体的恢复技术之前，我们需要先知道Oracle为什么能够恢复？

Oracle事务基本原理

  要想灵活地运用Oracle恢复技术，就需要了解Oracle对于事务的处理原理。接下来我们会通过图9-1详细讨论Oracle对于事务的内部处理机制。我们以一个语句为例，来了解Oracle的内部处理流程。

SQL> insert into table my_table values(1);  
SQL> commit;  
Commit complete.

  用户进程连接到数据库，数据库会为这个用户进程创建一个服务器进程（也叫影子进程）；这个进程就像用户进程的影子，替用户完成各种操作。

  用户发出了第一个insert语句，向指定表中插入一条记录。

  因为每条记录最终都要保存到一个数据块中，因此，Oracle会检查这个目标数据块是否已经存在于Data Buffer Cache中，如果不存在，影子进程就要负责把这个数据块从磁盘文件读取到SGA中。

  影子进程就要修改这个数据块内容，把新的记录插进去；但是在这之前还需要构造Undo数据块，以备回滚；同时还要生成这两个操作的Redo记录，并把Redo记录放在Log Buffer Cache中。

  第一个insert语句的操作完成；用户可以继续输入其他语句。

  用户输入commit，要提交这个插入操作。

  LGWR进程被触发，把Log Buffer中的日志记录到当前联机日志文件中。

  一旦LGWR的写操作成功，用户就会收Commit complete的提示。用户就可以确认，本次修改已经被保存了，Oracle承诺所有Commit complete的事务不会丢失。

  到目前为止，用户的插入操作已经成功了，用户可以认为他的插入已经被记录到了数据文件中。但实际上我们还没有看到数据写（也就是DBWR进程）的活动。

  Oracle在运行过程中，所有对于数据的修改都是在内存中进行的。Oracle每要修改一个记录必须先把记录所在的数据块加载到内存中，然后在内存中进行修改。但是提交（Commit）时，只是把Redo Log Buffer中的日志写到磁盘，修改的数据块不会立即写回磁盘。也就是说，Redo Log Buffer中的事务信息会被LGWR进程非常频繁地写到磁盘上，而修改的数据块只是被DBWR进程定期地写到磁盘上。

  LGWR把Redo Log Buffer中的事务信息写到联机日志文件中的算法，和DBWR把Data Buffer Cache中的数据写到数据文件中的算法完全不同。这是因为这两个Buffer的目的本身就不一样。Log Buffer的目的是临时的缓存事务变化，然后尽快地把这些变化写到一个安全的地方去（联机日志文件）；而Data Buffer Cache的目标是尽可能地把数据块放在内存中久一点、再久一点，这样可以改进那些频繁访问的数据块的性能。这么做是基于性能的考虑，Oraclce是采用”延迟写”的算法定期批量地把数据块写回磁盘。对于代表本次修改操作的Redo记录必须要先被保存下来（Write Ahead Logging）。

  由于LGWR的活动和DBWR的活动不是同步的，因此，任意一个时间点上，那些已经提交的、被记录到联机日志文件中的事务，对应的数据文件中的数据可能是未提交的。同样，任何一个时刻，写到数据文件中的数据有可能是未提交的数据。这并不意外，Oracle会跟踪哪些事务提交与否，并确保数据的一致性读。当发生意外失败时，Oracle也能够判断事务提交与否，并根据Redo和Undo信息完成事务的回滚。

  因此在数据库运行过程中，内存的内容总是比磁盘数据新。当数据库正常关闭时（SHUTDOWN IMMEDIATE、SHUTDOWN NORMAL、SHUTDOWN TRANSACTIONAL），Oracle会把SGA内容全部写回磁盘后才关闭数据库，这时内存和磁盘就完全同步了。所以正常关闭数据库后数据不会丢失。但是如果数据库是异常关闭（SHUTDOWN ABORT或者断电），内存数据来不及同步到磁盘，这时就产生了数据不一致，Oracle再次打开数据库时，就需要进行恢复。

  Oracle的Redo机制保证了数据库恢复的可行性，在修改数据块之前，代表本次修改操作的Redo记录必须要先被保存下来（Write Ahead Logging），然后才真正修改数据记录。在处理COMMIT语句时，Oracle会在Log Biffer产生一条COMMIT记录，为了保证事务的持久化，所有的Redo记录和这一条COMMIT记录都要被写到磁盘的联机日志文件（Log Force At Commit），但是数据块（Data Block）不必写回磁盘。如果当前联机日志空间不够，还会触发日志切换（Log Switch），旧日志的检查点必须完成才能被覆盖。如果采用的是归档模式，这个日志还必须完成了归档才能被覆盖。

  这一节只是笼统地介绍了事务，接下来我们要进行深入探讨，不过我们的探讨只局限于和数据库恢复有关的内容。

转载自：http://book.51cto.com/art/201108/287801.htm
参考：http://blog.csdn.net/zhaowenzhong/article/details/8776853
http://m.blog.csdn.net/blog/veeasy/7777687