今天是2014-05-27，实在无聊顺便研究一下x$kccle的内容吧。如下全部是自己分析和实验结果，真实可靠。 1、如何获得v$log的底层表？我们可以通过autotrace完成查看如： sql set autotrace trace expsql set linesize 200sql select * from v$log;execution pl
今天是2014-05-27，实在无聊顺便研究一下x$kccle的内容吧。如下全部是自己分析和实验结果，真实可靠。
1、如何获得v$log的底层表？我们可以通过autotrace完成查看如：
sql> set autotrace trace expsql> set linesize 200sql> select * from v$log;execution plan----------------------------------------------------------plan hash value: 2536105608--------------------------------------------------------------------------------------------| id | operation | name | rows | bytes | cost (%cpu)| time |--------------------------------------------------------------------------------------------| 0 | select statement | | 1 | 197 | 0 (0)| 00:00:01 || 1 | nested loops | | 1 | 197 | 0 (0)| 00:00:01 ||* 2 | fixed table full | x$kccle | 1 | 148 | 0 (0)| 00:00:01 ||* 3 | fixed table fixed index| x$kccrt (ind:1) | 1 | 49 | 0 (0)| 00:00:01 |--------------------------------------------------------------------------------------------predicate information (identified by operation id):--------------------------------------------------- 2 - filter(le.ledup0 and le.inst_id=userenv('instance')) 3 - filter(rt.inst_id=userenv('instance') and le.lethr=rt.rtnum)sql>
可以知道当我们在查看v$log视图的时候，其实就是查看的x$kccle视图字段信息。查看该视图如下：
sql> desc x$kccle name null? type ----------------------------------------- -------- ---------------------------- addr raw(8) indx number inst_id number 实例号 lenum number 类似group_number lesiz number logfile的size，是操作系统的blocks数目 leseq number v$log中的sequence# lehws number lebsz number block size（操作系统的块） lenab number leflg number 表示日志的状态信息 lethr number v$log中的thread# lelff number 下一个logfile lelfb number 前一个logfile lelos varchar2(16) low scn类似v$log first_change# lelot varchar2(20) low time类似v$log first_time lenxs varchar2(16) nex scn 类似v$log中下一个logfile的low first_change#相同 lenxt varchar2(20) nex time类似v$log中下一个logfile的low first_time 相同 lepvs varchar2(16) prev scn, 与上一个logfile的low scn learf number archive link forward learb number archive link backward lefnh number lefnt number ledup number 等同于v$log中memberssql>
下面对比一下：
sql> select * from v$log; group# thread# sequence# bytes members arc status first_change# first_time---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------ 1 1 2944 104857600 1 yes inactive 121424676 21-may-14 2 1 2945 104857600 1 no current 121427428 21-may-14 3 1 2943 104857600 1 yes inactive 121421889 21-may-14sql> sql> select inst_id,lenum,lesiz,leseq,lehws,lebsz,lebsz*lesiz log_size,lenab,leflg,lethr,lelff,lelfb,lelos from x$kccle; inst_id lenum lesiz leseq lehws lebsz log_size lenab leflg lethr lelff lelfb lelos---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- 1 1 204800 2944 2 512 104857600 190256 1 1 2 0 121424676 1 2 204800 2945 1 512 104857600 4294967295 8 1 3 1 121427428 1 3 204800 2943 2 512 104857600 190256 1 1 0 2 121421889sql> sql> select inst_id,lenum,leseq,lethr,lelot,lenxs,lenxt,lepvs,learf,learb,lefnh,lefnt,ledup from x$kccle; inst_id lenum leseq lethr lelot lenxs lenxt lepvs learf learb lefnh lefnt ledup---------- ----- ----- ---------- -------------------- ---------------- -------------------- ---------------- ---------- ---------- ---------- ---------- ---------- 1 1 2944 1 05/21/2014 11:26:42 121427428 05/21/2014 11:26:55 121421889 0 0 1 1 1 1 2 2945 1 05/21/2014 11:26:55 281474976710655 121424676 0 0 2 2 1 1 3 2943 1 05/21/2014 11:26:30 121424676 05/21/2014 11:26:42 121419052 0 0 3 3 1sql>
现在单独关注一下leflg字段，当该值为8说明是正在使用的logfile group：
dump出控制文件中的log file信息如下：
sql> select * from v$log; group# thread# sequence# bytes blocksize members arc status first_change# first_tim next_change# next_time---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ --------- 1 1 19 52428800 512 2 no current 1013368 27-may-14 2.8147e+14 2 1 17 52428800 512 2 no active 1013348 27-may-14 1013365 27-may-14 3 1 18 52428800 512 2 no active 1013365 27-may-14 1013368 27-may-14sql> oradebug setmypidstatement processed.sql> oradebug dump controlf 12 statement processed.
注意：也可以使用alter system set events ‘immediate trace name controlf level 12';完成控制文件的dump操作：
log file records*************************************************************************** (size = 72, compat size = 72, section max = 16, section in-use = 3, last-recid= 17, old-recno = 0, last-recno = 0) (extent = 1, blkno = 10, numrecs = 16)log file #1: name #5: /u01/app/oracle/oradata/rhys/onlinelog/o1_mf_1_9r1z70w0_.log name #6: /u01/app/oracle/fast_recovery_area/rhys/onlinelog/o1_mf_1_9r1z70z2_.log thread 1 redo log links: forward: 2 backward: 0 siz: 0x19000 seq: 0x00000013 hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 2 archive links: fwrd: 0 back: 0 prev scn: 0x0000.000f7675 low scn: 0x0000.000f7678 05/27/2014 17:54:08 next scn: 0xffff.ffffffff 01/01/1988 00:00:00log file #2: name #3: /u01/app/oracle/oradata/rhys/onlinelog/o1_mf_2_9r1z726s_.log name #4: /u01/app/oracle/fast_recovery_area/rhys/onlinelog/o1_mf_2_9r1z7291_.log thread 1 redo log links: forward: 3 backward: 1 siz: 0x19000 seq: 0x00000011 hws: 0x2 bsz: 512 nab: 0x14 flg: 0x0 dup: 2 archive links: fwrd: 0 back: 0 prev scn: 0x0000.000f75ec low scn: 0x0000.000f7664 05/27/2014 17:54:01 next scn: 0x0000.000f7675 05/27/2014 17:54:05log file #3: name #1: /u01/app/oracle/oradata/rhys/onlinelog/o1_mf_3_9r1z73jf_.log name #2: /u01/app/oracle/fast_recovery_area/rhys/onlinelog/o1_mf_3_9r1z73lp_.log thread 1 redo log links: forward: 0 backward: 2 siz: 0x19000 seq: 0x00000012 hws: 0x2 bsz: 512 nab: 0x4 flg: 0x0 dup: 2 archive links: fwrd: 0 back: 0 prev scn: 0x0000.000f7664 low scn: 0x0000.000f7675 05/27/2014 17:54:05 next scn: 0x0000.000f7678 05/27/2014 17:54:08
对应一下：
sql> select inst_id,lenum,leseq,lethr,lelot,lenxs,lenxt,lepvs,learf,learb,lefnh,lefnt,ledup from x$kccle; inst_id lenum leseq lethr lelot lenxs lenxt lepvs learf learb lefnh lefnt ledup---------- ----- ----- ---------- -------------------- ---------------- -------------------- ---------------- ---------- ---------- ---------- ---------- ---------- 1 1 19 1 05/27/2014 17:54:08 281474976710655 1013365 0 0 5 6 2 1 2 17 1 05/27/2014 17:54:01 1013365 05/27/2014 17:54:05 1013228 0 0 3 4 2 1 3 18 1 05/27/2014 17:54:05 1013368 05/27/2014 17:54:08 1013348 0 0 1 2 2sql> select inst_id,lenum,lesiz,leseq,lehws,lebsz,lebsz*lesiz log_size,lenab,leflg,lethr,lelff,lelfb,lelos from x$kccle; inst_id lenum lesiz leseq lehws lebsz log_size lenab leflg lethr lelff lelfb lelos---------- ----- ---------- ----- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- 1 1 102400 19 1 512 52428800 4294967295 8 1 2 0 1013368 1 2 102400 17 2 512 52428800 20 0 1 3 1 1013348 1 3 102400 18 2 512 52428800 4 0 1 0 2 1013365sql>
拿group3做一个分析：如下：
log file #3:（代表第三个group）
name #1: /u01/app/oracle/oradata/rhys/onlinelog/o1_mf_3_9r1z73jf_.log（第一个日志文件）
name #2: /u01/app/oracle/fast_recovery_area/rhys/onlinelog/o1_mf_3_9r1z73lp_.log（第二个日志文件）
thread 1（线程1x$kccle.lethr） redo log links: forward: 0（对应x$kccle的lelff为0) backward: 2(对应x$kccle的lelfb为2)
siz: 0x19000(对应x$kccle的lesiz转为10进制正好是102400）： seq: 0x00000012（转为10进制为18对应x$kccle的leseq）： hws: 0x2（对应x$kccle的lehws为2） bsz: 512（数据块对应x$kccle的lebsz）
nab: 0x4（对应lenab为4） flg: 0x0（对应x$kccle的leflg） dup: 2（对应x$kccle的ledup）
archive links: fwrd: 0（前一个链表x$kccle的learf) back: 0 (对应x$kccle的learb）prev scn: 0x0000.000f7664（转为10进制scn为1013348，对应lepvs)
low scn: 0x0000.000f7675 05/27/2014 17:54:05(对应x$kccle的lelos）
next scn: 0x0000.000f7678 05/27/2014 17:54:08（对应x$kccle的lenxt）
由此可知x$kccle正式抓取的是控制文件中的内容，这也是为什么数据块在mount状态下，可以查看v$log的原因了。