浅谈Oracle前滚恢复

今天我们不探讨ORA-600[kcratr_nab_less_than_odr]错误，11.2上ORA-600问题比错误本身更有意思的是记录了对于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需要对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子进程。

 

写的不好，多多包涵。