Crash/Instance Recovery与Media Recovery的本质区别

2012/08/07 by Leave a Comment

Crash/Instance Recovery与Media Recovery的本质区别在于：

Crash/Instance Recovery针对需要恢复的实例从增量检查点(incremental checkpoint)开始apply redo应用重做日志。由于日志覆盖的先提条件是完成相关日志的logfile switch checkpoint，且从定义上说归档日志总是落后于实例的检查点，所以对于crash/instance recovery崩溃或实例恢复总是只需要访问读取在线的重做日志(online redo logfile)。

 

介质恢复Media Recovery从旧数据文件的检查点开始apply redo引用重做日志，这些旧的数据文件可能来源于备份。 介质恢复情况下需要用到归档重做日志，因此RMAN或DBA(用户管理的备份)也需要将备份相关的归档日志还原出来。

 

Crash/Instance Recovery总是保证仅当所有的持久重做数据被应用之后才算恢复完成。 在Oracle保证所有已提交的事务都已经被包含恢复的情况下，才认为崩溃实例完成了恢复工作。

 

相反，介质恢复有不完全恢复(incomplete recovery)和部分恢复(partial recovery)的提法，以实现恢复数据库(db)到某个时间点的一致性。

 

 

Crash/Instance Recovery与Media Recovery的相同点在于：

 

Crash/Instance Recovery与Media Recovery都是传统的前滚恢复方式(rolling forward)，原理上都是对持久redo log数据的重演。 不管是Crash/Instance Recovery还是Media Recovery的前滚，都需要继之以事务回滚以便回滚未提交的事务，虽然前滚完成后数据库即可以打开而不用等回滚完成，但是仅在回滚完成的时候我们认为数据库是真正一致的。

 

扩展阅读：

了解你所不知道的SMON功能(五):Recover Dead transaction
深入了解Oracle前滚恢复rolling forward(一)
了解你所不知道的SMON功能(六):Instance Recovery

Filed Under: Oracle, Oracle Internal Research内部原理研究 Tagged With: , ,

深入了解Oracle前滚恢复rolling forward(一)

2012/04/22 by 5 Comments

偶然的一次，网友在t.askmac.cn ASK Maclean Home提问了关于11.2 上一个ORA-600问题的解决途径，我们这里不讨论该ORA-600[kcratr_nab_less_than_odr]错误， 比这个错误本身更有趣的是 该600 trace中记录了一段对于前滚恢复rolling upgrade描述十分详细的KST trace。

 

 

很多网友肯定要问什么是KST? KST是9i以后引入的内部诊断机制Tracing Facility，每一个Oracle 进程都维护SGA中的一小块Trace buffer，并将自身的默认启用的一些event事件信息写入到Trace Buffer中(这些事件默认包括10280, 10401, 10441, 10442, 10425, 10427, 10429, 10434, 10666)，可以使用内部视图x$trace观察这些信息，默认Trace Buffer不写到磁盘上，而只在SGA中维护，当Trace Buffer用完时将被重用。

 

了解了 KST的知识后，我们可以从容地阅读下面这段TRACE了：

 

 

 

Trace Bucket Dump Begin: default bucket for process 19 (osid: 29785)
TIME(*=approx):SEQ:COMPONENT:FILE@LINE:FUNCTION:SECT/DUMP: [EVENT#:PID:SID] DATA

 

以上是KST Trace的 头部
COMPONENT 组件名 例如 db_trace 、CACHE_RCV，这里的CACHE_RCV意为 cache recovery，实际上是我们所说的前滚rolling forward。
FILE@LINE    指oracle内核代码的文件名和行数 例如:kst.c、kcv.c，这些都是oracle的核心C代码名
FUNCTION      指oracle内核函数名  例如kcvcrv()、kctrec()
[EVENT#:PID:SID]  即   EVENT ID:PID:SID
DATA      实际的操作内容

 

我们选择性地阅读KST TRACE的内容：

 

 

2012-02-07 13:40:52.755567 :800005B3:CACHE_RCV:kcv.c@15475:kcvcrv(): kcvcrv: Entering kcvcrv()2012-02-07 13:40:52.755609 :800005B4:KFNU:kfn.c@2200:kfnPrepareASM(): kfnPrepareASM force=0 state_kfnsg=0x7
2012-02-07 13:40:52.772999*:800005B5:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 1 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.826001*:800005B6:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 2 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.862014*:800005B7:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 3 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.909981*:800005B8:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 4 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.945933*:800005B9:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 5 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.993824*:800005BA:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 6 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.005829*:800005BB:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 7 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.041893*:800005BC:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 8 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.065779*:800005BD:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 9 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.089760*:800005BE:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 10 - cpscn 0x0000.018b76b2, rsflg 0

 

 

kcvcrv的全称是 [K]ernel [C]ache [R]ecovery [C]rash [R]ecovery [V]erify ， kcvcrv内核函数在crash recovery的过程中显得极为重要，它总是发生在当一个前台进程试图启动脏关闭(dirty shutdown)的数据库的时候。kcvcrv 的工作包括检验所有的数据文件头并验证控制文件中的数据文件记录以确认是否需要介质恢复。这个步骤必要地验证仅仅crash recovery是否足以让数据库恢复到一致状态(consistent)，相信大家已经耳熟能详 crash recovery 、 instance recovery 、 media recovery 三者的区别。 若kcvcrv发现 data files数据文件、control files控制文件亦或者redo log file在线日志文件存在corrupted 或者 丢失，或者实际上是从之前的备份中还原过来的，那么kcvcrv会强制用户必须使用media recovery才能将数据库恢复到一致，无法通过crash recovery实现恢复。注意 kcvcrv的检测并不是完全的，它主要是检测 数据文件头的checkpoint scn 和 控制文件中data files的checkpoint scn是否一致，以确保 这些数据文件完成了shutdown instance时的最后一次FULL Checkpoint。 kcvcrv并不能检测出除数据文件头部外的datafile body是否存在介质讹误。

 

kcvcrv需要对control file读写才能完成其必要的任务，所以它会启动一个控制文件读写事务 read-write control file transaction。通过检验控制文件中每个数据文件的记录以确认数据文件是否有被重新同步的必要。 当然kcvcrv会跳过哪些OFFLINE和read-only的数据文件，因为这些文件不存在recovery的必要。

在确认crash recovery的必要性后，kcvcrv还会主导启动并行的恢复工作(parallel recovery)，注意parallel recovery只在多CPU且参数recovery_parallelism不为零的环境下有效， kcvcrv会创建并初始化Oracle中的PQ Slave 并行子进程以便恢复实例。 默认的子进程数Slave Processes等于(CPU的总数-1)，这是因为需要为recovery coordinator process恢复协调进程保留一个CPU。并且需要kcvcrv分配一个recovery state object给并行恢复 协调进程与其Slave子进程。

 

最后kcvcrv还会调用另一个关键内核函数 kctrec ( Kernel Cache Threads )， kctrec会在所有打开的redo thread上实施进一步的thread recovery。

 

 

2012-02-07 13:40:53.366569 :80000687:KFNU:kfn.c@2200:kfnPrepareASM(): kfnPrepareASM force=0 state_kfnsg=0x7
2012-02-07 13:40:53.366569*:80000688:CACHE_RCV:kcv.c@16365:kcvcrv(): kcvcrv: Calling kctrec()
2012-02-07 13:40:53.366569*:80000689:CACHE_RCV:kct.c@4163:kctrec(): kctrec: Entering kctrec()
2012-02-07 13:40:53.413557*:8000068A:CACHE_RCV:kct.c@4271:kctrec(): kctrec: thread 1 cf thread ckpt: logseq 1468, block 2,scn 25917106

 

常见的 kcvcrv 调用堆栈 stack call如下：

 

kcratr_odr_check  <- kcratr <- kctrec <- kcvcrv <- kcfopd <- adbdrv
kcliarq <- kclrinit <- kcbrst <- kcrpci <- kcratr <- kctrec <- kcvcrv <- kcfopd <- adbdrv

kfgrpIterInit()<-kfis_sageonly_anygroup()<-krr_init_rrx()<-kcra_scan_redo()<-kcra_dump_redo()+2246<-kcra_dump_redo_internal()+1752<-kco_image_corrupt()<-kcoapl()<-kcbr_apply_change()<-kcbr_mapply_change()<-kcbrapply()<-kcbr_apply_pending()<-kcbr_media_apply()<-krp_serial_apply()<-krr_do_media_recovery()<-krddmr()<-krd_do_media_rcv()<-krd_implicit_rcv()<-kcvcrv()<-kcfopd()<-adbdrv()

Filed Under: Oracle Tagged With: , ,

沪ICP备14014813号-2

沪公网安备 31010802001379号