Redo的原理:
我们知道,用户数据通常在Buffer Cache中修改,Oracle通过高速缓存来提高数据操作的性能。当用户在Buffer Cache中修改数据时,Oracle并不会立即将变更数据写出到数据文件上,因为独立的离散写出效率会很低。到目前为止,计算机系统中最容易出现瓶颈的仍然是磁盘的I/O操作,Oracle这样做的目的是为了减少IO的压力,当修改过的数据达到一定数量之后,可以进行高效地批量写出。
大部分传统数据库(当然包括Oracle)在处理数据修改时都遵循no-force-at-commit策略。也就是说,在提交时并不强制写。那么为了保证数据在数据库发生故障时(例如:断电)可以恢复,Oracle引入了Redo机制,通过连续的、顺序的日志条目的写出将随机的、分散的数据块的写出推延。这个推延使得数据的写出可以获得批量效应等性能提升。
同Redo Log Buffer类似,Redo Log File也是循环使用的,Oracle允许使用最少两个日志组。缺省的,数据库创建时会建立3个日志组。
sys@NEI> select group#,members,status from v$log;
GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 1 INACTIVE
2 1 CURRENT
3 1 INACTIVE
当一个日志文件写满之后,会切换到另外一个日志文件,这个切换过程称为Log Switch。Log Switch会触发一个检查点,促使DBWR进程将写满的日志文件保护的变更数据写回数据库。在检查点完成之前,日志文件是不能被重用的。
由于Redo机制对于数据的保护,当数据库发生故障时,Oracle就可以通过Redo重演进行数据恢复。那么一个非常重要的问题是,恢复应该从何开始呢?如果读取的Redo过多,那么必然导致恢复的时间过长,在生产环境中,我们必须保证恢复时间尽量的短。
Oracle通过检查点(Checkpoint)来缩减恢复时间。检查点只是一个数据库事件,它存在的根本意义在于减少恢复时间。
当检查点发生时(此时的SCN被称为Checkpoint SCN)Oracle会通知DBWR进程,把修改过的数据,也就是此Checkpoint SCN之前的脏数据(Dirty Duffer)从Buffer Cache写入磁盘,在检查点完成后CKPT进程会相应地更新控制文件和数据文件头,记录检查点信息,标识变更。
在检查点完成之后,此检查点之前修改过的数据都已经写回磁盘,重做日志文件中的相应重做记录对于崩溃/实例恢复不再有用。如果此后数据库崩溃,那么恢复只需要从最后一次完成的检查点开始恢复即可。如果数据库运行在归档模式(所有生产数据库,都建议运行在归档模式),日志文件在重用之前必须写出到归档日志文件,归档日志在介质恢复时可以用来恢复数据库故障。
- The End -