Oracle事务基本原理.docVIP

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的事务不会丢失。? 图9-1? Oracle内部事务处理流程 到目前为止，用户的插入操作已经成功了，用户可以认为他的插入已经被记录到了数据文件中。但实际上我们还没有看到数据写（也就是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），旧日志的检查点必须完成才能被覆盖。如果采用的是归档模式，这个日志还必