Redo的机制与内部原理小结

Redo的机制与内部原理小结

参考资料: 《ORALCE内核技术揭秘》

http://www.cnblogs.com/sopost/p/3589731.html

         http://blog.csdn.net/tianlesoftware/article/details/6286330

     

 

 

一、    什么是redo

 

Oracle 的redo是为确保已经提交的事务不会丢失而建立的一个机制。 因为这种健全的机制，才能让我们在数据库crash时，恢复数据，保证数据不丢失。

 

redo的机制分为三个部分（归档暂且不提）

1.       online redo log

 

online redo log 是物理文件，默认与数据文件存储在同一位置，online redo log是循环使用的，Oracle允许使用最少两个日志组。缺省的，数据库创建时会建立3个日志组。

当一个日志文件写满之后，会切换到另外一个日志文件，这个切换过程称为Log Switch。Log Switch会触发一个检查点，促使DBWR进程将写满的日志文件保护的变更数据写回数据库。在检查点完成之前，日志文件是不能被重用的。

 

2.       redo log buffer

 

Redo Log Buffer位于SGA之中，是一块循环使用的内存区域，其保存数据库变更的相关信息。这些信息以重做条目（Redo Entries）形式存储（Redo Entries也经常称为Redo Records）。Redo Entries包含重构、重做数据库变更的重要信息，这些变更包括INSERT、UPDATE、DELETE、CREATE、ALTER或者DROP等。

 

3.       LGWR

 

LGWR是oracle重要的后台进程，负责不断把Redo Log Buffer的内容写出到Redo Log File中。

为了让LGWR 尽快将LOG BUFFER 中的数据写入REDO LOG 文件，以便于腾出更多的空闲空间，Oracle 数据库设计了LGWR 写的触发条件：

1.用户提交

2.有1/3重做日志缓冲区未被写入磁盘

3.有大于1M的重做日志缓冲区未被写入磁盘

4.每隔3 秒钟

    5. DBWR 需要写入的数据的SCN大于LGWR记录的SCN，DBWR 触发LGWR写入。

 

 

二、    Redo的作用

 

Redo的作用是恢复，重新将丢失的数据在做一遍。

 

ORACLE 在处理数据修改时都遵循no-force-at-commit策略。也就是说，在提交时并不强制写，可以最大的保证数据不丢失。那么为了保证数据在数据库发生故障时（例如：断电）可以恢复，Oracle引入了Redo机制，通过连续的、顺序的日志条目的写出将随机的、分散的数据块的写出推延。这个推延使得数据的写出可以获得批量效应等性能提升。

 

 

 

三、    实例恢复

恢复分两种：

（1）    Crash recovery

（2）    Media recovery

 

 

这两种的区别是：

1.Crash Recovery 是在启动时DB 自动完成，而MediaRecovery 需要DBA 手工的完成。

2.Crash Recovery 使用online redo log，Media Recovery 使用archived log 和 online redo log。

3.Media Recovery 可能还需要从备份中Restore datafile。

 

具体参考：http://blog.csdn.net/tianlesoftware/article/details/6286330

四、    IMU与非IMU

我们现在知道了redo机制的组成与作用，那么redo的内部是怎么运行的呢？

从ORACLE 10g 开始增加了一种机制：In Memory Undo,简称IMU。它对redo内部的原理、流程进行了不小的改动，但同时，ORACLE还会在一些时候让进程仍然使用非IMU机制，也就是说，现在的ORACLE(当前版本为12C)IMU和非IMU都是一起使用的。简单来说，IMU对于redo的影响，就是减少了redo recorder的数量。

 举个例子，当用户发出DML语句，想要修改某个块中的数据时，比如用户执行如下命令：

     Update vage name=’aaaaa’ where id=1;

假设这条语句要修改的行是4号文件4899号块中的第一行（0号行），原值为AAAAA。

在非IMU机制下，一条redo recorder的流程如图所示:

流程如下

1.       服务器进程从共享池保存的SQL语句中提取文本里的目标值aaaaa，并传送的PGA中；

2.       从buffer中读取AAAAA及在PGA生成的所有redo change信息到LOG BUFFER。这一步是生成UNDO对应的redo数据，因为是第一条redo change，所以在它之前还要在log buffer生成redo recorder header

3.       从PGA中将目标值aaaaa传送到log buffer中

4.       Redo recorder生成完毕，先修undo块buffer

5.       从PGA中将目标值aaaaa传送到buffer catch中，此步骤完成后，update命令结束

6.       当LGWR活动时，或在用户提交时，执行此步骤，将事务redo recorder所在的redo块写到redo文件中

 

在IMU机制下的流程：

 

1.       与非IMU下的一模一样

2.       从表快当中读取前映像值AAAAA，并传送到共享池的undo IMU区。

此步骤的形成的结果就是：将undo信息暂时存放在共享池的IMU区，可以改造redo数据的流程，将多条redo recorder    合成一条

3.       在共享池中的私有redo区中生成redo change。此步骤等于将本应在log buffer中生成的redo change先移到共享池中

4.       从私有区中读取目标值aaaaa到buffer中，覆盖原值AAAAA。

 

 

在IMU下，修改命令只执行到这里。修改命令运行期间，不会向log buffer中传送数据，而是在共享池中分配一块专门的缓存。

 

在IMU下，很多工作延迟到了提交时完成，流程如下：

 

1.       从undo imu区将前映像复制到undo的 buffer中

2.       写redo change到log buffer(表快)

3.       写redo change到 log buffer（undo块）

注意的是：表快在update命令时就被修改了，而undo块在commit执行时才被修改

4.       将log buffer中的所有信息一次性写入到redo文件中。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28719622/viewspace-2124901/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28719622/viewspace-2124901/