ORACLE例項恢復過程詳細分析--使用dump、BBED等多種工具結合分析
---友情提示，內容較多，可以從博文左上的+目錄選擇小節方便閱讀。
實驗思路： --實驗相關TRACE檔案：http://download.csdn.net/detail/q947817003/6646723
1.資料庫OPEN,，做DML操作不提交，檢視檢查點。
2.SHUTDOWN ABORT並重啟到MOUNT並查詢檢查點
3.DUMP控制檔案檢視CHECKPOINT_CHANGE#/RBA
4.DUMP資料檔案檢視CHECKPOINT_CHANGE#/RBA，與DUMP控制檔案對比
5.DUMP REDO日誌檔案，檢視、對比CHECKPOINT_CHANGE#/RBA
6.使用BBED檢視資料檔案頭中的CHECKPOINT_CHANGE#/RBA
7.執行EVENT事件的語句，OPEN資料庫，再DUMP控制檔案
8.分析OPEN時，通過ALERT日誌檢視的恢復過程--前滾
9.分析OPEN時，EVENT事件生成的TRACE中檢視恢復過程--前滾
10.OPEN資料庫時，通過ALERT日誌及EVENT事件生成的TRACE中資訊解析例項恢復的回滾
11.分析OPEN後的控制檔案資訊
參考資料及感謝：
guoyJoe http://blog.csdn.net/guoyJoe/article/details/9034425
dbsnake http://www.dbsnake.com/oracle-instance-recovery-end-point.html
實驗結論有：
1.控制檔案提供恢復所需當前REDO日誌的RBA資訊，當前REDO日誌提供具體的用於恢復的日誌內容，最終是將日誌內容應用於資料檔案。--例項恢復三者不能缺。
2.資料庫OPEN時開始例項恢復，先應用日誌內容，應用完後從alert日誌中來看是已經可以連線至資料庫，此時如果UNDO未完成，就有使用者發出操作，資料庫程式會將回滾後的資料傳送至使用者--可能會有等待。
3.重要的一點，資料檔案、當前REDO日誌檔案、控制檔案正常時例項恢復無需DBA干預，自動完成哈哈。
4.如果當前REDO日誌丟了，只能做不完全恢復了。
關於例項恢復起止點：--來自dbsnake
可能會出現On Disk RBA比Low Cache RBA小的情況，如果Oracle發現存在這種情況，則會強制寫redo。
On Disk RBA只是表示Instance Recovery的時候至少要恢復到On Disk RBA，它只是真正的current redo log file的最尾端一個前映象。
例項恢復的起點是：Low Cache RBA和Thread Checkpoint RBA中的較大值；例項恢復的終點就是current redo log file的最尾端。On-Disk RBA是要最低恢復到的位置--事實上是隻要On-Disk RBA後還有日誌塊就要恢復完的。
Oracle在做例項恢復的時候是受隱含引數_two_pass的控制，其預設為true，這表示要Oracle做例項恢復的時候是採用Two Pass Recovery，即要掃描current redo log file兩次。
Two Pass Recovery的核心是在做例項恢復時要去掉那些已經被寫入資料檔案的資料塊所對應的redo record，Oracle稱這些redo record為Block Written Record (BWR)。
###################################################################
BYS@ bys3>set time on
13:18:17 BYS@ bys3>select * from a; --此表在USER表空間。
B
----------
55
8
0
3
13:18:21 BYS@ bys3>delete a;
4 rows deleted.
13:18:36 BYS@ bys3>select * from a;
no rows selected
再開啟一個會話（同一會話切換使用者會提交操作），多種途徑檢視資料庫中檢查點：詳見：http://blog.csdn.net/q947817003/article/details/11590735
SYS@ bys3>set time on
13:18:44 SYS@ bys3>col name for a35
13:18:52 SYS@ bys3>select dbid,name,checkpoint_change# from v$database;
DBID NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
3358363031 BYS3 1991217
13:18:59 SYS@ bys3>select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile;
FILE# NAME CHECKPOINT_CHANGE# CPTIME
---------- ----------------------------------- ------------------ -------------------
1 /u01/oradata/bys3/system01.dbf 1991217 2013-12-02 13:17:26
2 /u01/oradata/bys3/sysaux01.dbf 1991217 2013-12-02 13:17:26
3 /u01/oradata/bys3/undotbs01.dbf 1991217 2013-12-02 13:17:26
4 /u01/oradata/bys3/user01.dbf 1991217 2013-12-02 13:17:26
13:19:25 SYS@ bys3>select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
----------------------------------- ------------------
/u01/oradata/bys3/system01.dbf 1991217
/u01/oradata/bys3/sysaux01.dbf 1991217
/u01/oradata/bys3/undotbs01.dbf 1991217
/u01/oradata/bys3/user01.dbf 1991217
當前當前REDO日誌使用情況：
13:19:57 SYS@ bys3>col member for a30
13:20:01 SYS@ bys3>select a.member,a.type,b.thread#,b.sequence#,b.bytes/1024/1024 MB,b.status,b.archived from v$logfile a,v$log b where a.group#=b.group#;
MEMBER TYPE THREAD# SEQUENCE# MB STATUS ARC
------------------------------ ------- ---------- ---------- ---------- ---------------- ---
/u01/oradata/bys3/redo01.log ONLINE 1 106 50 INACTIVE YES
/u01/oradata/bys3/redo02.log ONLINE 1 107 50 CURRENT NO
/u01/oradata/bys3/redo03.log ONLINE 1 105 50 INACTIVE YES
###################################################################
ORACLE instance shut down.
13:22:11 SYS@ bys3>
alert日誌： --推薦個小方法：把alert日誌做一個軟連結到ORACLE使用者家目錄，檢視方便。
[oracle@bys3 ~]$ cat alert_bys3.log
Mon Dec 02 13:22:09 2013
Shutting down instance (abort)
License high water mark = 4
USER (ospid: 846): terminating the instance
Instance terminated by USER, pid = 846
Mon Dec 02 13:22:11 2013
Instance shutdown complete
######################################
重啟資料庫到MOUNT，從資料庫中檢視資料庫中檢查點、控制檔案及資料檔案頭檢查點，一致則無需介質恢復
資料庫MOUNT狀態下直接在資料庫中使用SQL語句查詢：
SYS@ bys3>select status from v$instance;
STATUS
------------
MOUNTED
SYS@ bys3>select dbid,name,checkpoint_change# from v$database; --資料庫全域性-檢查點 SCN，在控制檔案中
DBID NAME CHECKPOINT_CHANGE#
---------- --------- ------------------
3358363031 BYS3 1991217
SYS@ bys3>select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile; --checkpoint scn,表示該資料檔案最近一次執行檢查點操作時的SCN，在控制檔案中。
FILE# NAME CHECKPOINT_CHANGE# CPTIME
---------- ----------------------------------- ------------------ -------------------
1 /u01/oradata/bys3/system01.dbf 1991217 2013-12-02 13:17:26
2 /u01/oradata/bys3/sysaux01.dbf 1991217 2013-12-02 13:17:26
3 /u01/oradata/bys3/undotbs01.dbf 1991217 2013-12-02 13:17:26
4 /u01/oradata/bys3/user01.dbf 1991217 2013-12-02 13:17:26
SYS@ bys3>select name,checkpoint_change# from v$datafile_header; --CHECKPOINT_CHANGE#表示該資料檔案最近一次執行檢查點操作時的SCN，在資料檔案頭
NAME CHECKPOINT_CHANGE#
----------------------------------- ------------------
/u01/oradata/bys3/system01.dbf 1991217
/u01/oradata/bys3/sysaux01.dbf 1991217
/u01/oradata/bys3/undotbs01.dbf 1991217
/u01/oradata/bys3/user01.dbf 1991217
###################################################################
SYS@ bys3>alter session set events 'immediate trace name controlf level 12';
Session altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_980.trc
檢視TRACE檔案： --擷取部分內容
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/14/2013 14:23:19
DB Name "BYS3"
Database flags = 0x00404001 0x00001200
Controlfile Creation Timestamp 11/14/2013 14:23:21
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 11/14/2013 14:23:19
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xb200000
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.001e6231
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Max log members = 5, Max data members = 1
Arch list: Head=2, Tail=2, Force scn: 0x0000.001b6c94scn: 0x0000.00000000
Activation ID: 3358374039
SCN compatibility 1
Auto-rollover enabled
Controlfile Checkpointed at scn: 0x0000.001e6286 12/02/2013 13:17:28 ---這是增量檢查點的位置SCN -1991302
thread:0 rba:(0x0.0.0)
###############
可以看到檢查點的資訊：Database checkpoint: Thread=1 scn: 0x0000.001e6231
換算為十進位制的SCN為： ---與上一步查詢對應
SYS@ bys3>select to_number('1e6231','xxxxxxxxx') from dual;
TO_NUMBER('1C8E12','XXXXXXXXX')
-------------------------------
1991217
###############
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 4, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 4)
THREAD #1 - status:0x2 flags:0x0 dirty:104 ---髒塊數量104
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0) ---資料檔案檢查點 Scn以及stop scn值據說來自於當前REDO日誌
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37 --ON DISK SCN
resetlogs scn: 0x0000.00000001 11/14/2013 14:23:19
heartbeat: 833133356 mount id: 3360007946
################
在檢查點程式記錄部分，記錄了Dirty Buffer的數量是104.
包含Low Cache RBA和On Disk RBA的資訊，
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0)
-- low cache rba:(0x6b.3.0): 例項恢復的起點：107號日誌，第3個塊，第0個位元組
--on disk rba:(0x6b.197.0)： 例項恢復的終點：107號日誌，第407個塊，第0個位元組 --最前面結論是例項恢復終點實際為current redo log file的最尾端，但是在控制檔案、日誌中記錄的是這個on disk rba
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37
資料庫恢復的檢查點終點是SCN--0x0000.001e638d，十進位制是：1991565。
On-Disk RBA的SCN是1991565，這是例項恢復的終點。
資料庫的恢復SCN範圍也就由此確定，即SCN範圍：增量檢查點：1991302--On-Disk RBA，用SCN表示即：1991302 ===>>>1991565
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 4,
last-recid= 7, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 7, numrecs = 100)
DATA FILE #1: DATA FILE #2: DATA FILE #3: 和DATA FILE #3差不多，並且在本實驗中不涉及，精簡篇幅就省略了。
DATA FILE #4:
name #8: /u01/oradata/bys3/user01.dbf
creation size=6400 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 4, index=5 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26 ---cnt:167是檢查點計數，來自資料檔案。--與下一步DUMP資料檔案中SYSTEM表空間資料檔案的CTL CNT對應。一致說明來自同一版本，而不是備份。
Stop scn: 0xffff.ffffffff 12/02/2013 13:16:13 --STOP SCN是FFFF，資料檔案的STOP SCP不等於Checkpoint SCN。意味著資料庫上一次關閉未執行完全檢查點，是異常關閉。故需要例項恢復。
Creation Checkpointed at scn: 0x0000.000034f9 11/14/2013 14:26:26
thread:1 rba:(0x1.ce8a.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
########################
這裡在第1步做DML操作時，所在的是USER表空間。
DATA FILE #4: 中的檢查點資訊如下：
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26
--控制檔案中儲存的資料檔案檢查點SCN＝1e6231 轉成10進製為1991217，與前文吻合
Stop scn: 0xffff.ffffffff 12/11/2012 22:53:05
--結束的SCN填無窮大，說明是異常關機的，重啟資料庫必須做例項恢復
###################################################################
SYS@ bys3>alter system set events 'immediate trace name file_hdrs level 3'; --最好和上一步DUMP控制檔案在不同的會話
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
----------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1010.trc
DATA FILE #1:
name #4: /u01/oradata/bys3/system01.dbf
creation size=64000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26 -----------CKPT CNT 167與上一步DUMP控制檔案中對應
Stop scn: 0xffff.ffffffff 12/02/2013 13:16:13 ------- --STOP SCN是FFFF，資料檔案的STOP SCP不等於Checkpoint SCN。意味著資料庫上一次關閉未執行完全檢查點，是異常關閉。故需要例項恢復。
Creation Checkpointed at scn: 0x0000.00000015 11/14/2013 14:24:22
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3358363031=0xc82c8d97, Db Name='BYS3'
Activation ID=0=0x0
Control Seq=8489=0x2129, File size=64000=0xfa00
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000015 11/14/2013 14:24:22
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x318f5cd7 scn: 0x0000.00000001
prev reset logs count:0x0 scn: 0x0000.00000000
recovered at 12/02/2013 13:17:26
status:0x2004 root dba:0x00400208 chkpt cnt: 167 ctl cnt:166 -----------CKPT CNT 167, CTL CNT 166與上一步DUMP控制檔案中對應
###################################################
Tablespace #4 - USERS rel_fn:4
Creation at scn: 0x0000.000034f9 11/14/2013 14:26:26
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x318f5cd7 scn: 0x0000.00000001
prev reset logs count:0x0 scn: 0x0000.00000000
recovered at 12/02/2013 13:17:26
status:0x4 root dba:0x00000000 chkpt cnt: 168 ctl cnt:167
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001e6231 12/02/2013 13:17:26 -------檢查點 scn: 0x0000.001e6231與前文吻合
thread:1 rba:(0x6b.2.10) --------REDO日誌的地址0x6b.2.10--－> 107號日誌，第2號塊，第16個位元組
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Backup Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp 01/01/1988 00:00:00
Platform Information: Creation Platform ID: 10
Current Platform ID: 10 Last Platform ID: 10
DUMP OF TEMP FILES: 1 files in database
第3步中：《《注意：
從控制檔案中得到重做日誌恢復起始地址如下：
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0)
-- low cache rba:(0x6b.3.0):
例項恢復的起點：107號日誌，第3個塊，第0個位元組
--on disk rba:(0x6b.197.0)：
例項恢復的終點：107號日誌，第407個塊，第0個位元組 --具體是不是終點，最後討論
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37
資料庫恢復的檢查點終點是SCN--0x0000.001e638d，十進位制是：1991565。
On-Disk RBA的SCN是1991565，這是例項恢復的終點。
資料庫的恢復SCN範圍也就由此確定，即SCN範圍：最後檢查點：1991217--On-Disk RBA，用SCN表示即：1991217 ===>>>1991565》》
--說明：
例項恢復的起點是Low Cache RBA和Thread Checkpoint RBA中的最大值，例項恢復的終點就是current redo log file的最尾端而不是On-Disk RBA。On-Disk RBA是要最低恢復到的位置。
這樣，本實驗中例項恢復的起始的重做日誌是以控制檔案中的low cache rba:(0x6b.3.0)開始恢復，而不是從檔案頭的thread:1 rba:(0x6b.2.10)
########################################################################
SYS@ bys3>alter system dump logfile '/u01/oradata/bys3/redo02.log';
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1906.trc
REDO日誌DUMP最後一個REDO RECORD 的一部分CHANGE #1： --不知道如何解讀，留白吧？？？
REDO RECORD - Thread:1 RBA: 0x00006b.00000194.0084 LEN: 0x0418 VLD: 0x09 ---與上一步的對應
SCN: 0x0000.001e638c SUBSCN: 1 12/02/2013 13:21:37
CHANGE #1 TYP:2 CLS:1 AFN:1 DBA:0x004007e1 OBJ:288 SCN:0x0000.001e6386 SEQ:2 OP:11.5 ENC:0 RBL:0
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0009.017.00000642 uba: 0x00c00cac.00f9.28
Block cleanout record, scn: 0x0000.001e638b ver: 0x01 opt: 0x02, entries follow...
itli: 2 flg: 2 scn: 0x0000.001e6386
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x004007e1 hdba: 0x004007e0
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 1 ckix: 182
ncol: 19 nnew: 6 size: -7
col 4: [ 7] 78 71 0c 02 0e 16 26
col 5: *NULL*
col 6: [ 7] 78 71 0c 02 0e 17 26
col 7: [21]
c0 06 60 3d 13 34 56 13 34 56 13 34 56 13 34 56 13 34 56 1e 0b
col 9: [ 1] 80
col 10: [ 1] 80
###################################################################
blocksize=8192
listfile=bbedfile.txt
mode=edit
[oracle@bys3 ~]$ cat bbedfile.txt
1 /u01/oradata/bys3/system01.dbf 524288000
2 /u01/oradata/bys3/sysaux01.dbf 340787200
3 /u01/oradata/bys3/undotbs01.dbf 209715200
4 /u01/oradata/bys3/user01.dbf 52428800
[oracle@bys3 ~]$ bbed parfile=par.bbd
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Sun Dec 1 22:29:18 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
************ !!! For Oracle Internal Use only !!! ***************
BBED> set file 4 block 1
FILE# 4
BLOCK# 1
BBED> map /v
File: /u01/oradata/bys3/user01.dbf (4)
Block: 1 Dba:0x01000001
------------------------------------------------------------
Data File Header
struct kcvfh, 860 bytes @0
struct kcvfhbfh, 20 bytes @0
struct kcvfhhdr, 76 bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, 8 bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, 8 bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, 8 bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, 36 bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, 36 bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, 16 bytes @316
sword kcvfhtsn @332
ub2 kcvfhtln @336
text kcvfhtnm[30] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, 8 bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 8 bytes @384
ub4 kcvfhbbc @392
ub4 kcvfhncb @396
ub4 kcvfhmcb @400
ub4 kcvfhlcb @404
ub4 kcvfhbcs @408
ub2 kcvfhofb @412
ub2 kcvfhnfb @414
ub4 kcvfhprc @416
struct kcvfhprs, 8 bytes @420
struct kcvfhprfs, 8 bytes @428
ub4 kcvfhtrt @444
ub4 tailchk @8188
BBED> print kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001e6231
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x31a859e6
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000006b
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
BBED> set offset 500
OFFSET 500
BBED> dump /v ---@500開始，4位元組表示日誌序號，4位元組表示塊號，2位元組表示日誌塊中第幾個位元組，表示的是資料檔案頭的RBA資訊
從資料塊中計算出的RBA資訊與print kcvfhckp中的一致，就不重複算了。
關於日誌塊大小，詳見：http://blog.csdn.net/q947817003/article/details/11350359
File: /u01/oradata/bys3/user01.dbf (4)
Block: 1 Offsets: 500 to 1011 Dba:0x01000001
-------------------------------------------------------
6b000000 02000000 10000400 02000000 l k...............
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
省略。。。。
<16 bytes per line>
這裡CHKPOINT_SCN資訊是：
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001e6231
ub2 kscnwrp @488 0x0000
這三行就是檢查點的SCN資訊，kscnbas--0x001c8e12，kscnwrp--0x0000ub4 --實驗有效的4個byte： 0x0000
scn計算方法：SCN=(SCN_WRP * 4294967296) + SCN_BAS --SCN的詳細介紹及計算：http://blog.csdn.net/q947817003/article/details/11590983
所以此處的SCN就是：0x0000.001e6231；10進位制SCN號為：1991217
RBA資訊是：
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000006b --序號，
ub4 kcrbabno @504 0x00000002 --塊號
ub2 kcrbabof @508 0x0010 --位元組號
換算為十進位制表示為：107號日誌，2號塊，16位元組
與上一步DUMP資料檔案資訊得出的一致：
thread:1 rba:(0x6b.2.10)
--重做日誌的地址0x6b.2.10--－> 107號日誌，第2號塊，第16個位元組
###################################################################
關於下面用到的10013/10015事件，分別是在Startup時跟蹤事務恢復，在事務恢復後做Dump回退段頭資訊。
EVENT事件詳見http://blog.csdn.net/q947817003/article/details/16359765
說明：--在這裡用這兩個語句不知道到底能不能DUMP出詳細的REDO應用及回滾資訊，從生成的TRACE檔案來看有這方面資訊，好像不太詳細。。。
SYS@ bys3>alter session set events '10013 trace name context forever,level 1';
Session altered.
SYS@ bys3>alter session set events '10015 trace name context forever,level 1';
Session altered.
SYS@ bys3>alter database open;
Database altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
----------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1955.trc
另開一會話在OPEN資料庫後立刻執行：
SYS@ bys3>alter session set events 'immediate trace name controlf level 12';
Session altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_2108.trc
在OPEN過程中，ORACLE檢查以下兩項： 詳見：http://blog.csdn.net/haibusuanyun/article/details/11271107
1.檢查資料檔案頭中檢查點計數（checkpoint CNT）是否與控制檔案中檢查點計數（checkpoint CNT）一致。以此確定資料檔案是否來自恢復檔案。
2.如果檢查點計數檢查通過，資料庫進行第二次檢查，檢查資料檔案頭的開始SCN和控制檔案中記錄的該檔案的結束SCN是否一致，如果控制檔案中記錄的結束SCN等於資料檔案頭的開始SCN，不需要例項恢復。
以上兩次檢查通過後，開啟資料庫，鎖定資料檔案，並將每個資料檔案的結束SCN設定為無窮大。
##################################################################
Mon Dec 02 20:35:20 2013
alter database open
Beginning crash recovery of 1 threads --開始例項恢復
Started redo scan --開始掃描REDO日誌
Completed redo scan --完成掃描REDO日誌
read 202 KB redo, 104 data blocks need recovery --需要恢復的資料塊104塊，REDO日誌202KB，按low cache rba--on disk rba來算是407-3=404個日誌塊，一個日誌塊大小是512位元組，正好202KB。
Started redo application at
Thread 1: logseq 107, block 3 --這裡可以看到，是從107號日誌第3塊開始應用REDO-與第3步中low cache rba:(0x6b.3.0)吻合
Recovery of Online Redo Log: Thread 1 Group 2 Seq 107 Reading mem 0
Mem# 0: /u01/oradata/bys3/redo02.log --所使用REDO日誌檔案，與第一步查詢吻合。
Completed redo application of 0.16MB
Completed crash recovery at
Thread 1: logseq 107, block 407, scn 2011565 --完成例項恢復的位置，與第3步中on disk rba:(0x6b.197.0)吻合
104 data blocks read, 104 data blocks written, 202 redo k-bytes read --例項恢復涉及資訊統計
Mon Dec 02 20:35:20 2013
LGWR: STARTING ARCH PROCESSES ----可以看到 例項恢復完成後，ARCH程式啟動
Mon Dec 02 20:35:21 2013
ARC0 started with pid=19, OS id=2112
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 advanced to log sequence 108 (thread open)
Thread 1 opened at log sequence 108
Current log# 3 seq# 108 mem# 0: /u01/oradata/bys3/redo03.log
Successful open of redo thread 1 ----可以看到 例項恢復完成後，REDO日誌啟動
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Dec 02 20:35:22 2013
SMON: enabling cache recovery
Mon Dec 02 20:35:22 2013
ARC1 started with pid=20, OS id=2116
Mon Dec 02 20:35:22 2013
ARC2 started with pid=21, OS id=2122
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Mon Dec 02 20:35:23 2013
ARC3 started with pid=22, OS id=2126
還有段ALERT日誌涉及回滾放在下一小節
################################################################
Thread 1 checkpoint: logseq 107, block 2, scn 1991217
cache-low rba: logseq 107, block 3 --這一段資訊與MOUNT時DUMP控制檔案的一樣
on-disk rba: logseq 107, block 407, scn 1991565
start recovery at logseq 107, block 3, scn 0 --例項恢復起點： MOUNT時DUMP控制檔案的low cache rba:(0x6b.3.0)
*** 2013-12-02 20:35:20.739
Started writing zeroblks thread 1 seq 107 blocks 407-414
*** 2013-12-02 20:35:20.745
Completed writing zeroblks thread 1 seq 107
==== Redo read statistics for thread 1 ====
Total physical reads (from disk and memory): 4096Kb
-- Redo read_disk statistics --這個應該是例項恢復期間REDO讀寫統計
Read rate (ASYNC): 202Kb in 0.22s => 0.90 Mb/sec --REDO的速度-202KB與ALERT日誌中對應
Longest record: 17Kb, moves: 0/287 (0%)
Longest LWN: 18Kb, moves: 0/99 (0%), moved: 0Mb
Last redo scn: 0x0000.001e638c (1991564) --最後一個REDO的SCN：與On-Disk RBA的SCN是1991565差1
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 1
Average hash chain = 104/104 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1120/1224 = 0.9
----------------------------------------------
*** 2013-12-02 20:35:20.749
KCRA: start recovery claims for 104 data blocks
*** 2013-12-02 20:35:20.781
KCRA: blocks processed = 104/104, claimed = 104, eliminated = 0
*** 2013-12-02 20:35:20.783
Recovery of Online Redo Log: Thread 1 Group 2 Seq 107 Reading mem 0
*** 2013-12-02 20:35:20.815
Completed redo application of 0.16MB --與ALERT中對照
*** 2013-12-02 20:35:20.944
Completed recovery checkpoint --可以看到 例項恢復完後做了檢查點
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 1
Average hash chain = 104/104 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1224/1224 = 1.0
----------------------------------------------
Recovery sets nab of thread 1 seq 107 to 407 with 8 zeroblks
##################################################################
ALERT日誌中回滾資訊：
[1955] Successfully onlined Undo Tablespace 2. --
Undo initialization finished serial:0 start:985058364 end:985058674 diff:310 (3 seconds) --從這句看應該是有回滾操作，能力有限，沒更好解釋。。。
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
Archived Log entry 77 added for thread 1 sequence 107 ID 0xc82cb897 dest 1:
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Mon Dec 02 20:35:24 2013
QMNC started with pid=23, OS id=2130
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Completed: alter database open
#############################
EVENT事件生成的TRACE中資訊
*** 2013-12-02 20:35:22.989
Acq rollback segment SYSTEM
Rec rollback segment _SYSSMU1_3056155133$
Recovering transaction (1, 21) --看這裡好像是SYSTEM回滾段做的事務恢復
Marking transaction (1, 21) dead
Rec rollback segment _SYSSMU2_3692097322$
Rec rollback segment _SYSSMU3_3366438251$
Rec rollback segment _SYSSMU4_3660460897$
Rec rollback segment _SYSSMU5_1917899003$
Rec rollback segment _SYSSMU6_3107841501$
Rec rollback segment _SYSSMU7_1420906157$
Rec rollback segment _SYSSMU8_2178365988$
Rec rollback segment _SYSSMU9_1689884801$
Rec rollback segment _SYSSMU10_3239467560$
*** 2013-12-02 20:35:23.225
Recovering transaction (1, 21) ----這個好像是回滾的第一步中未提交的事務，不知道具體如何查詢驗證
Marking transaction (1, 21) dead
Acq rollback segment _SYSSMU1_3056155133$
Acq rollback segment _SYSSMU2_3692097322$
Acq rollback segment _SYSSMU3_3366438251$
Acq rollback segment _SYSSMU4_3660460897$
Acq rollback segment _SYSSMU5_1917899003$
Acq rollback segment _SYSSMU6_3107841501$
Acq rollback segment _SYSSMU7_1420906157$
Acq rollback segment _SYSSMU8_2178365988$
Acq rollback segment _SYSSMU9_1689884801$
Acq rollback segment _SYSSMU10_3239467560$
kwqmnich: current time:: 12: 35: 23: 0
kwqmnich: instance no 0 repartition flag 1
kwqmnich: initialized job cache structure
*** 2013-12-02 20:35:24.574
ktsmgtur(): TUR was not tuned for 25928 secs
ktsmg_advance_slot(): MMNL advances slot after 25928 seconds
################################################################################
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/14/2013 14:23:19
DB Name "BYS3"
Database flags = 0x00404001 0x00001200
Controlfile Creation Timestamp 11/14/2013 14:23:21
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 11/14/2013 14:23:19
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xb200000
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.001eb1b0 --檢查點已經更新
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Max log members = 5, Max data members = 1
Arch list: Head=3, Tail=3, Force scn: 0x0000.001b6c94scn: 0x0000.00000000
Activation ID: 3358374039
SCN compatibility 1
Auto-rollover enabled
Controlfile Checkpointed at scn: 0x0000.001eb212 12/02/2013 20:35:25
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 4, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 4)
THREAD #1 - status:0x2 flags:0x0 dirty:43
low cache rba:(0x6c.3.0) on disk rba:(0x6c.76.0) --on disk rba已經遞增
on disk scn: 0x0000.001eb212 12/02/2013 20:35:24 --on disk scn已經遞增
resetlogs scn: 0x0000.00000001 11/14/2013 14:23:19
heartbeat: 833141767 mount id: 3360007946
實驗思路： --實驗相關TRACE檔案：http://download.csdn.net/detail/q947817003/6646723
1.資料庫OPEN,，做DML操作不提交，檢視檢查點。
2.SHUTDOWN ABORT並重啟到MOUNT並查詢檢查點
3.DUMP控制檔案檢視CHECKPOINT_CHANGE#/RBA
4.DUMP資料檔案檢視CHECKPOINT_CHANGE#/RBA，與DUMP控制檔案對比
5.DUMP REDO日誌檔案，檢視、對比CHECKPOINT_CHANGE#/RBA
6.使用BBED檢視資料檔案頭中的CHECKPOINT_CHANGE#/RBA
7.執行EVENT事件的語句，OPEN資料庫，再DUMP控制檔案
8.分析OPEN時，通過ALERT日誌檢視的恢復過程--前滾
9.分析OPEN時，EVENT事件生成的TRACE中檢視恢復過程--前滾
10.OPEN資料庫時，通過ALERT日誌及EVENT事件生成的TRACE中資訊解析例項恢復的回滾
11.分析OPEN後的控制檔案資訊
參考資料及感謝：
guoyJoe http://blog.csdn.net/guoyJoe/article/details/9034425
dbsnake http://www.dbsnake.com/oracle-instance-recovery-end-point.html
實驗結論有：
1.控制檔案提供恢復所需當前REDO日誌的RBA資訊，當前REDO日誌提供具體的用於恢復的日誌內容，最終是將日誌內容應用於資料檔案。--例項恢復三者不能缺。
2.資料庫OPEN時開始例項恢復，先應用日誌內容，應用完後從alert日誌中來看是已經可以連線至資料庫，此時如果UNDO未完成，就有使用者發出操作，資料庫程式會將回滾後的資料傳送至使用者--可能會有等待。
3.重要的一點，資料檔案、當前REDO日誌檔案、控制檔案正常時例項恢復無需DBA干預，自動完成哈哈。
4.如果當前REDO日誌丟了，只能做不完全恢復了。
關於例項恢復起止點：--來自dbsnake
可能會出現On Disk RBA比Low Cache RBA小的情況，如果Oracle發現存在這種情況，則會強制寫redo。
On Disk RBA只是表示Instance Recovery的時候至少要恢復到On Disk RBA，它只是真正的current redo log file的最尾端一個前映象。
例項恢復的起點是：Low Cache RBA和Thread Checkpoint RBA中的較大值；例項恢復的終點就是current redo log file的最尾端。On-Disk RBA是要最低恢復到的位置--事實上是隻要On-Disk RBA後還有日誌塊就要恢復完的。
Oracle在做例項恢復的時候是受隱含引數_two_pass的控制，其預設為true，這表示要Oracle做例項恢復的時候是採用Two Pass Recovery，即要掃描current redo log file兩次。
Two Pass Recovery的核心是在做例項恢復時要去掉那些已經被寫入資料檔案的資料塊所對應的redo record，Oracle稱這些redo record為Block Written Record (BWR)。
###################################################################
1.資料庫正常執行，多種途徑檢視資料庫中檢查點
在普通使用者下執行DML操作不提交BYS@ bys3>set time on
13:18:17 BYS@ bys3>select * from a; --此表在USER表空間。
B
----------
55
8
0
3
13:18:21 BYS@ bys3>delete a;
4 rows deleted.
13:18:36 BYS@ bys3>select * from a;
no rows selected
再開啟一個會話（同一會話切換使用者會提交操作），多種途徑檢視資料庫中檢查點：詳見：http://blog.csdn.net/q947817003/article/details/11590735
SYS@ bys3>set time on
13:18:44 SYS@ bys3>col name for a35
13:18:52 SYS@ bys3>select dbid,name,checkpoint_change# from v$database;
DBID NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
3358363031 BYS3 1991217
13:18:59 SYS@ bys3>select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile;
FILE# NAME CHECKPOINT_CHANGE# CPTIME
---------- ----------------------------------- ------------------ -------------------
1 /u01/oradata/bys3/system01.dbf 1991217 2013-12-02 13:17:26
2 /u01/oradata/bys3/sysaux01.dbf 1991217 2013-12-02 13:17:26
3 /u01/oradata/bys3/undotbs01.dbf 1991217 2013-12-02 13:17:26
4 /u01/oradata/bys3/user01.dbf 1991217 2013-12-02 13:17:26
13:19:25 SYS@ bys3>select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
----------------------------------- ------------------
/u01/oradata/bys3/system01.dbf 1991217
/u01/oradata/bys3/sysaux01.dbf 1991217
/u01/oradata/bys3/undotbs01.dbf 1991217
/u01/oradata/bys3/user01.dbf 1991217
當前當前REDO日誌使用情況：
13:19:57 SYS@ bys3>col member for a30
13:20:01 SYS@ bys3>select a.member,a.type,b.thread#,b.sequence#,b.bytes/1024/1024 MB,b.status,b.archived from v$logfile a,v$log b where a.group#=b.group#;
MEMBER TYPE THREAD# SEQUENCE# MB STATUS ARC
------------------------------ ------- ---------- ---------- ---------- ---------------- ---
/u01/oradata/bys3/redo01.log ONLINE 1 106 50 INACTIVE YES
/u01/oradata/bys3/redo02.log ONLINE 1 107 50 CURRENT NO
/u01/oradata/bys3/redo03.log ONLINE 1 105 50 INACTIVE YES
###################################################################
2.模擬斷電--shutdown abort，並重啟到MOUNT 查詢檢查點
13:20:02 SYS@ bys3>shutdown abort; ----13:22:11執行完此命令ORACLE instance shut down.
13:22:11 SYS@ bys3>
alert日誌： --推薦個小方法：把alert日誌做一個軟連結到ORACLE使用者家目錄，檢視方便。
[oracle@bys3 ~]$ cat alert_bys3.log
Mon Dec 02 13:22:09 2013
Shutting down instance (abort)
License high water mark = 4
USER (ospid: 846): terminating the instance
Instance terminated by USER, pid = 846
Mon Dec 02 13:22:11 2013
Instance shutdown complete
######################################
重啟資料庫到MOUNT，從資料庫中檢視資料庫中檢查點、控制檔案及資料檔案頭檢查點，一致則無需介質恢復
資料庫MOUNT狀態下直接在資料庫中使用SQL語句查詢：
SYS@ bys3>select status from v$instance;
STATUS
------------
MOUNTED
SYS@ bys3>select dbid,name,checkpoint_change# from v$database; --資料庫全域性-檢查點 SCN，在控制檔案中
DBID NAME CHECKPOINT_CHANGE#
---------- --------- ------------------
3358363031 BYS3 1991217
SYS@ bys3>select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile; --checkpoint scn,表示該資料檔案最近一次執行檢查點操作時的SCN，在控制檔案中。
FILE# NAME CHECKPOINT_CHANGE# CPTIME
---------- ----------------------------------- ------------------ -------------------
1 /u01/oradata/bys3/system01.dbf 1991217 2013-12-02 13:17:26
2 /u01/oradata/bys3/sysaux01.dbf 1991217 2013-12-02 13:17:26
3 /u01/oradata/bys3/undotbs01.dbf 1991217 2013-12-02 13:17:26
4 /u01/oradata/bys3/user01.dbf 1991217 2013-12-02 13:17:26
SYS@ bys3>select name,checkpoint_change# from v$datafile_header; --CHECKPOINT_CHANGE#表示該資料檔案最近一次執行檢查點操作時的SCN，在資料檔案頭
NAME CHECKPOINT_CHANGE#
----------------------------------- ------------------
/u01/oradata/bys3/system01.dbf 1991217
/u01/oradata/bys3/sysaux01.dbf 1991217
/u01/oradata/bys3/undotbs01.dbf 1991217
/u01/oradata/bys3/user01.dbf 1991217
###################################################################
3.DUMP控制檔案檢視CHECKPOINT_CHANGE#/RBA
更詳細DUMP控制檔案方式見：http://blog.csdn.net/q947817003/article/details/16370273SYS@ bys3>alter session set events 'immediate trace name controlf level 12';
Session altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_980.trc
檢視TRACE檔案： --擷取部分內容
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/14/2013 14:23:19
DB Name "BYS3"
Database flags = 0x00404001 0x00001200
Controlfile Creation Timestamp 11/14/2013 14:23:21
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 11/14/2013 14:23:19
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xb200000
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.001e6231
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Max log members = 5, Max data members = 1
Arch list: Head=2, Tail=2, Force scn: 0x0000.001b6c94scn: 0x0000.00000000
Activation ID: 3358374039
SCN compatibility 1
Auto-rollover enabled
Controlfile Checkpointed at scn: 0x0000.001e6286 12/02/2013 13:17:28 ---這是增量檢查點的位置SCN -1991302
thread:0 rba:(0x0.0.0)
###############
可以看到檢查點的資訊：Database checkpoint: Thread=1 scn: 0x0000.001e6231
換算為十進位制的SCN為： ---與上一步查詢對應
SYS@ bys3>select to_number('1e6231','xxxxxxxxx') from dual;
TO_NUMBER('1C8E12','XXXXXXXXX')
-------------------------------
1991217
###############
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 4, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 4)
THREAD #1 - status:0x2 flags:0x0 dirty:104 ---髒塊數量104
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0) ---資料檔案檢查點 Scn以及stop scn值據說來自於當前REDO日誌
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37 --ON DISK SCN
resetlogs scn: 0x0000.00000001 11/14/2013 14:23:19
heartbeat: 833133356 mount id: 3360007946
################
在檢查點程式記錄部分，記錄了Dirty Buffer的數量是104.
包含Low Cache RBA和On Disk RBA的資訊，
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0)
-- low cache rba:(0x6b.3.0): 例項恢復的起點：107號日誌，第3個塊，第0個位元組
--on disk rba:(0x6b.197.0)： 例項恢復的終點：107號日誌，第407個塊，第0個位元組 --最前面結論是例項恢復終點實際為current redo log file的最尾端，但是在控制檔案、日誌中記錄的是這個on disk rba
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37
資料庫恢復的檢查點終點是SCN--0x0000.001e638d，十進位制是：1991565。
On-Disk RBA的SCN是1991565，這是例項恢復的終點。
資料庫的恢復SCN範圍也就由此確定，即SCN範圍：增量檢查點：1991302--On-Disk RBA，用SCN表示即：1991302 ===>>>1991565
***************************************************************************
DATA FILE RECORDS
***************************************************************************
(size = 520, compat size = 520, section max = 100, section in-use = 4,
last-recid= 7, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 7, numrecs = 100)
DATA FILE #1: DATA FILE #2: DATA FILE #3: 和DATA FILE #3差不多，並且在本實驗中不涉及，精簡篇幅就省略了。
DATA FILE #4:
name #8: /u01/oradata/bys3/user01.dbf
creation size=6400 block size=8192 status=0xe head=8 tail=8 dup=1
tablespace 4, index=5 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26 ---cnt:167是檢查點計數，來自資料檔案。--與下一步DUMP資料檔案中SYSTEM表空間資料檔案的CTL CNT對應。一致說明來自同一版本，而不是備份。
Stop scn: 0xffff.ffffffff 12/02/2013 13:16:13 --STOP SCN是FFFF，資料檔案的STOP SCP不等於Checkpoint SCN。意味著資料庫上一次關閉未執行完全檢查點，是異常關閉。故需要例項恢復。
Creation Checkpointed at scn: 0x0000.000034f9 11/14/2013 14:26:26
thread:1 rba:(0x1.ce8a.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
########################
這裡在第1步做DML操作時，所在的是USER表空間。
DATA FILE #4: 中的檢查點資訊如下：
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26
--控制檔案中儲存的資料檔案檢查點SCN＝1e6231 轉成10進製為1991217，與前文吻合
Stop scn: 0xffff.ffffffff 12/11/2012 22:53:05
--結束的SCN填無窮大，說明是異常關機的，重啟資料庫必須做例項恢復
###################################################################
4.DUMP資料檔案檢視CHECKPOINT_CHANGE#/RBA，與DUMP控制檔案對比
更詳細DUMP資料檔案方式見：http://blog.csdn.net/q947817003/article/details/16369041SYS@ bys3>alter system set events 'immediate trace name file_hdrs level 3'; --最好和上一步DUMP控制檔案在不同的會話
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
----------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1010.trc
檢視TRACE檔案： --擷取部分內容--
DATA FILE #1:
name #4: /u01/oradata/bys3/system01.dbf
creation size=64000 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:167 scn: 0x0000.001e6231 12/02/2013 13:17:26 -----------CKPT CNT 167與上一步DUMP控制檔案中對應
Stop scn: 0xffff.ffffffff 12/02/2013 13:16:13 ------- --STOP SCN是FFFF，資料檔案的STOP SCP不等於Checkpoint SCN。意味著資料庫上一次關閉未執行完全檢查點，是異常關閉。故需要例項恢復。
Creation Checkpointed at scn: 0x0000.00000015 11/14/2013 14:24:22
thread:1 rba:(0x1.3.10)
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.00000000 prev_range: 0
Online Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Hot Backup end marker scn: 0x0000.00000000
aux_file is NOT DEFINED
Plugged readony: NO
Plugin scnscn: 0x0000.00000000
Plugin resetlogs scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign creation scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Foreign checkpoint scn/timescn: 0x0000.00000000 01/01/1988 00:00:00
Online move state: 0
V10 STYLE FILE HEADER:
Compatibility Vsn = 186646528=0xb200000
Db ID=3358363031=0xc82c8d97, Db Name='BYS3'
Activation ID=0=0x0
Control Seq=8489=0x2129, File size=64000=0xfa00
File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM rel_fn:1
Creation at scn: 0x0000.00000015 11/14/2013 14:24:22
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x318f5cd7 scn: 0x0000.00000001
prev reset logs count:0x0 scn: 0x0000.00000000
recovered at 12/02/2013 13:17:26
status:0x2004 root dba:0x00400208 chkpt cnt: 167 ctl cnt:166 -----------CKPT CNT 167, CTL CNT 166與上一步DUMP控制檔案中對應
###################################################
Tablespace #4 - USERS rel_fn:4
Creation at scn: 0x0000.000034f9 11/14/2013 14:26:26
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x318f5cd7 scn: 0x0000.00000001
prev reset logs count:0x0 scn: 0x0000.00000000
recovered at 12/02/2013 13:17:26
status:0x4 root dba:0x00000000 chkpt cnt: 168 ctl cnt:167
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001e6231 12/02/2013 13:17:26 -------檢查點 scn: 0x0000.001e6231與前文吻合
thread:1 rba:(0x6b.2.10) --------REDO日誌的地址0x6b.2.10--－> 107號日誌，第2號塊，第16個位元組
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Backup Checkpointed at scn: 0x0000.00000000
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
External cache id: 0x0 0x0 0x0 0x0
Absolute fuzzy scn: 0x0000.00000000
Recovery fuzzy scn: 0x0000.00000000 01/01/1988 00:00:00
Terminal Recovery Stamp 01/01/1988 00:00:00
Platform Information: Creation Platform ID: 10
Current Platform ID: 10 Last Platform ID: 10
DUMP OF TEMP FILES: 1 files in database
第3步中：《《注意：
從控制檔案中得到重做日誌恢復起始地址如下：
low cache rba:(0x6b.3.0) on disk rba:(0x6b.197.0)
-- low cache rba:(0x6b.3.0):
例項恢復的起點：107號日誌，第3個塊，第0個位元組
--on disk rba:(0x6b.197.0)：
例項恢復的終點：107號日誌，第407個塊，第0個位元組 --具體是不是終點，最後討論
on disk scn: 0x0000.001e638d 12/02/2013 13:21:37
資料庫恢復的檢查點終點是SCN--0x0000.001e638d，十進位制是：1991565。
On-Disk RBA的SCN是1991565，這是例項恢復的終點。
資料庫的恢復SCN範圍也就由此確定，即SCN範圍：最後檢查點：1991217--On-Disk RBA，用SCN表示即：1991217 ===>>>1991565》》
--說明：
例項恢復的起點是Low Cache RBA和Thread Checkpoint RBA中的最大值，例項恢復的終點就是current redo log file的最尾端而不是On-Disk RBA。On-Disk RBA是要最低恢復到的位置。
這樣，本實驗中例項恢復的起始的重做日誌是以控制檔案中的low cache rba:(0x6b.3.0)開始恢復，而不是從檔案頭的thread:1 rba:(0x6b.2.10)
########################################################################
5.DUMP REDO日誌檔案 --在第一步已經確定了當前日誌是redo02.log
更詳細方法，見：http://blog.csdn.net/q947817003/article/details/16370203SYS@ bys3>alter system dump logfile '/u01/oradata/bys3/redo02.log';
System altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1906.trc
REDO日誌DUMP最後一個REDO RECORD 的一部分CHANGE #1： --不知道如何解讀，留白吧？？？
REDO RECORD - Thread:1 RBA: 0x00006b.00000194.0084 LEN: 0x0418 VLD: 0x09 ---與上一步的對應
SCN: 0x0000.001e638c SUBSCN: 1 12/02/2013 13:21:37
CHANGE #1 TYP:2 CLS:1 AFN:1 DBA:0x004007e1 OBJ:288 SCN:0x0000.001e6386 SEQ:2 OP:11.5 ENC:0 RBL:0
KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0009.017.00000642 uba: 0x00c00cac.00f9.28
Block cleanout record, scn: 0x0000.001e638b ver: 0x01 opt: 0x02, entries follow...
itli: 2 flg: 2 scn: 0x0000.001e6386
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x004007e1 hdba: 0x004007e0
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 1 ckix: 182
ncol: 19 nnew: 6 size: -7
col 4: [ 7] 78 71 0c 02 0e 16 26
col 5: *NULL*
col 6: [ 7] 78 71 0c 02 0e 17 26
col 7: [21]
c0 06 60 3d 13 34 56 13 34 56 13 34 56 13 34 56 13 34 56 1e 0b
col 9: [ 1] 80
col 10: [ 1] 80
###################################################################
6：使用BBED檢視資料檔案頭CHECKPOINT_CHANGE#及rba
[oracle@bys3 ~]$ cat par.bbdblocksize=8192
listfile=bbedfile.txt
mode=edit
[oracle@bys3 ~]$ cat bbedfile.txt
1 /u01/oradata/bys3/system01.dbf 524288000
2 /u01/oradata/bys3/sysaux01.dbf 340787200
3 /u01/oradata/bys3/undotbs01.dbf 209715200
4 /u01/oradata/bys3/user01.dbf 52428800
[oracle@bys3 ~]$ bbed parfile=par.bbd
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Sun Dec 1 22:29:18 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
************ !!! For Oracle Internal Use only !!! ***************
BBED> set file 4 block 1
FILE# 4
BLOCK# 1
BBED> map /v
File: /u01/oradata/bys3/user01.dbf (4)
Block: 1 Dba:0x01000001
------------------------------------------------------------
Data File Header
struct kcvfh, 860 bytes @0
struct kcvfhbfh, 20 bytes @0
struct kcvfhhdr, 76 bytes @20
ub4 kcvfhrdb @96
struct kcvfhcrs, 8 bytes @100
ub4 kcvfhcrt @108
ub4 kcvfhrlc @112
struct kcvfhrls, 8 bytes @116
ub4 kcvfhbti @124
struct kcvfhbsc, 8 bytes @128
ub2 kcvfhbth @136
ub2 kcvfhsta @138
struct kcvfhckp, 36 bytes @484
ub4 kcvfhcpc @140
ub4 kcvfhrts @144
ub4 kcvfhccc @148
struct kcvfhbcp, 36 bytes @152
ub4 kcvfhbhz @312
struct kcvfhxcd, 16 bytes @316
sword kcvfhtsn @332
ub2 kcvfhtln @336
text kcvfhtnm[30] @338
ub4 kcvfhrfn @368
struct kcvfhrfs, 8 bytes @372
ub4 kcvfhrft @380
struct kcvfhafs, 8 bytes @384
ub4 kcvfhbbc @392
ub4 kcvfhncb @396
ub4 kcvfhmcb @400
ub4 kcvfhlcb @404
ub4 kcvfhbcs @408
ub2 kcvfhofb @412
ub2 kcvfhnfb @414
ub4 kcvfhprc @416
struct kcvfhprs, 8 bytes @420
struct kcvfhprfs, 8 bytes @428
ub4 kcvfhtrt @444
ub4 tailchk @8188
BBED> print kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001e6231
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x31a859e6
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000006b
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
BBED> set offset 500
OFFSET 500
BBED> dump /v ---@500開始，4位元組表示日誌序號，4位元組表示塊號，2位元組表示日誌塊中第幾個位元組，表示的是資料檔案頭的RBA資訊
從資料塊中計算出的RBA資訊與print kcvfhckp中的一致，就不重複算了。
關於日誌塊大小，詳見：http://blog.csdn.net/q947817003/article/details/11350359
File: /u01/oradata/bys3/user01.dbf (4)
Block: 1 Offsets: 500 to 1011 Dba:0x01000001
-------------------------------------------------------
6b000000 02000000 10000400 02000000 l k...............
00000000 00000000 00000000 00000000 l ................
00000000 00000000 00000000 00000000 l ................
省略。。。。
<16 bytes per line>
這裡CHKPOINT_SCN資訊是：
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x001e6231
ub2 kscnwrp @488 0x0000
這三行就是檢查點的SCN資訊，kscnbas--0x001c8e12，kscnwrp--0x0000ub4 --實驗有效的4個byte： 0x0000
scn計算方法：SCN=(SCN_WRP * 4294967296) + SCN_BAS --SCN的詳細介紹及計算：http://blog.csdn.net/q947817003/article/details/11590983
所以此處的SCN就是：0x0000.001e6231；10進位制SCN號為：1991217
RBA資訊是：
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000006b --序號，
ub4 kcrbabno @504 0x00000002 --塊號
ub2 kcrbabof @508 0x0010 --位元組號
換算為十進位制表示為：107號日誌，2號塊，16位元組
與上一步DUMP資料檔案資訊得出的一致：
thread:1 rba:(0x6b.2.10)
--重做日誌的地址0x6b.2.10--－> 107號日誌，第2號塊，第16個位元組
###################################################################
7.執行EVENT事件的語句，OPEN資料庫後立刻DUMP控制檔案
注意事項：要把EVENT事件的語句執行上，不然實驗所需資料不連貫哈哈關於下面用到的10013/10015事件，分別是在Startup時跟蹤事務恢復，在事務恢復後做Dump回退段頭資訊。
EVENT事件詳見http://blog.csdn.net/q947817003/article/details/16359765
說明：--在這裡用這兩個語句不知道到底能不能DUMP出詳細的REDO應用及回滾資訊，從生成的TRACE檔案來看有這方面資訊，好像不太詳細。。。
SYS@ bys3>alter session set events '10013 trace name context forever,level 1';
Session altered.
SYS@ bys3>alter session set events '10015 trace name context forever,level 1';
Session altered.
SYS@ bys3>alter database open;
Database altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
----------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_1955.trc
另開一會話在OPEN資料庫後立刻執行：
SYS@ bys3>alter session set events 'immediate trace name controlf level 12';
Session altered.
SYS@ bys3>select value from v$diag_info where name like 'Default%';
VALUE
------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_2108.trc
在OPEN過程中，ORACLE檢查以下兩項： 詳見：http://blog.csdn.net/haibusuanyun/article/details/11271107
1.檢查資料檔案頭中檢查點計數（checkpoint CNT）是否與控制檔案中檢查點計數（checkpoint CNT）一致。以此確定資料檔案是否來自恢復檔案。
2.如果檢查點計數檢查通過，資料庫進行第二次檢查，檢查資料檔案頭的開始SCN和控制檔案中記錄的該檔案的結束SCN是否一致，如果控制檔案中記錄的結束SCN等於資料檔案頭的開始SCN，不需要例項恢復。
以上兩次檢查通過後，開啟資料庫，鎖定資料檔案，並將每個資料檔案的結束SCN設定為無窮大。
##################################################################
8.分析OPEN時，通過ALERT日誌檢視的恢復過程--前滾
[oracle@bys3 ~]$ cat alert_bys3.logMon Dec 02 20:35:20 2013
alter database open
Beginning crash recovery of 1 threads --開始例項恢復
Started redo scan --開始掃描REDO日誌
Completed redo scan --完成掃描REDO日誌
read 202 KB redo, 104 data blocks need recovery --需要恢復的資料塊104塊，REDO日誌202KB，按low cache rba--on disk rba來算是407-3=404個日誌塊，一個日誌塊大小是512位元組，正好202KB。
Started redo application at
Thread 1: logseq 107, block 3 --這裡可以看到，是從107號日誌第3塊開始應用REDO-與第3步中low cache rba:(0x6b.3.0)吻合
Recovery of Online Redo Log: Thread 1 Group 2 Seq 107 Reading mem 0
Mem# 0: /u01/oradata/bys3/redo02.log --所使用REDO日誌檔案，與第一步查詢吻合。
Completed redo application of 0.16MB
Completed crash recovery at
Thread 1: logseq 107, block 407, scn 2011565 --完成例項恢復的位置，與第3步中on disk rba:(0x6b.197.0)吻合
104 data blocks read, 104 data blocks written, 202 redo k-bytes read --例項恢復涉及資訊統計
Mon Dec 02 20:35:20 2013
LGWR: STARTING ARCH PROCESSES ----可以看到 例項恢復完成後，ARCH程式啟動
Mon Dec 02 20:35:21 2013
ARC0 started with pid=19, OS id=2112
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 advanced to log sequence 108 (thread open)
Thread 1 opened at log sequence 108
Current log# 3 seq# 108 mem# 0: /u01/oradata/bys3/redo03.log
Successful open of redo thread 1 ----可以看到 例項恢復完成後，REDO日誌啟動
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Dec 02 20:35:22 2013
SMON: enabling cache recovery
Mon Dec 02 20:35:22 2013
ARC1 started with pid=20, OS id=2116
Mon Dec 02 20:35:22 2013
ARC2 started with pid=21, OS id=2122
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Mon Dec 02 20:35:23 2013
ARC3 started with pid=22, OS id=2126
還有段ALERT日誌涉及回滾放在下一小節
################################################################
9.分析OPEN時，EVENT事件生成的TRACE中檢視恢復過程--前滾
TRACE檔案內容：Thread 1 checkpoint: logseq 107, block 2, scn 1991217
cache-low rba: logseq 107, block 3 --這一段資訊與MOUNT時DUMP控制檔案的一樣
on-disk rba: logseq 107, block 407, scn 1991565
start recovery at logseq 107, block 3, scn 0 --例項恢復起點： MOUNT時DUMP控制檔案的low cache rba:(0x6b.3.0)
*** 2013-12-02 20:35:20.739
Started writing zeroblks thread 1 seq 107 blocks 407-414
*** 2013-12-02 20:35:20.745
Completed writing zeroblks thread 1 seq 107
==== Redo read statistics for thread 1 ====
Total physical reads (from disk and memory): 4096Kb
-- Redo read_disk statistics --這個應該是例項恢復期間REDO讀寫統計
Read rate (ASYNC): 202Kb in 0.22s => 0.90 Mb/sec --REDO的速度-202KB與ALERT日誌中對應
Longest record: 17Kb, moves: 0/287 (0%)
Longest LWN: 18Kb, moves: 0/99 (0%), moved: 0Mb
Last redo scn: 0x0000.001e638c (1991564) --最後一個REDO的SCN：與On-Disk RBA的SCN是1991565差1
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 1
Average hash chain = 104/104 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1120/1224 = 0.9
----------------------------------------------
*** 2013-12-02 20:35:20.749
KCRA: start recovery claims for 104 data blocks
*** 2013-12-02 20:35:20.781
KCRA: blocks processed = 104/104, claimed = 104, eliminated = 0
*** 2013-12-02 20:35:20.783
Recovery of Online Redo Log: Thread 1 Group 2 Seq 107 Reading mem 0
*** 2013-12-02 20:35:20.815
Completed redo application of 0.16MB --與ALERT中對照
*** 2013-12-02 20:35:20.944
Completed recovery checkpoint --可以看到 例項恢復完後做了檢查點
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 1
Average hash chain = 104/104 = 1.0
Max compares per lookup = 1
Avg compares per lookup = 1224/1224 = 1.0
----------------------------------------------
Recovery sets nab of thread 1 seq 107 to 407 with 8 zeroblks
##################################################################
10.OPEN資料庫時，通過ALERT日誌及EVENT事件生成的TRACE中資訊解析例項恢復的回滾
能力有限，解析不了，留著以後解決吧。ALERT日誌中回滾資訊：
[1955] Successfully onlined Undo Tablespace 2. --
Undo initialization finished serial:0 start:985058364 end:985058674 diff:310 (3 seconds) --從這句看應該是有回滾操作，能力有限，沒更好解釋。。。
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
Archived Log entry 77 added for thread 1 sequence 107 ID 0xc82cb897 dest 1:
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Mon Dec 02 20:35:24 2013
QMNC started with pid=23, OS id=2130
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Completed: alter database open
#############################
EVENT事件生成的TRACE中資訊
*** 2013-12-02 20:35:22.989
Acq rollback segment SYSTEM
Rec rollback segment _SYSSMU1_3056155133$
Recovering transaction (1, 21) --看這裡好像是SYSTEM回滾段做的事務恢復
Marking transaction (1, 21) dead
Rec rollback segment _SYSSMU2_3692097322$
Rec rollback segment _SYSSMU3_3366438251$
Rec rollback segment _SYSSMU4_3660460897$
Rec rollback segment _SYSSMU5_1917899003$
Rec rollback segment _SYSSMU6_3107841501$
Rec rollback segment _SYSSMU7_1420906157$
Rec rollback segment _SYSSMU8_2178365988$
Rec rollback segment _SYSSMU9_1689884801$
Rec rollback segment _SYSSMU10_3239467560$
*** 2013-12-02 20:35:23.225
Recovering transaction (1, 21) ----這個好像是回滾的第一步中未提交的事務，不知道具體如何查詢驗證
Marking transaction (1, 21) dead
Acq rollback segment _SYSSMU1_3056155133$
Acq rollback segment _SYSSMU2_3692097322$
Acq rollback segment _SYSSMU3_3366438251$
Acq rollback segment _SYSSMU4_3660460897$
Acq rollback segment _SYSSMU5_1917899003$
Acq rollback segment _SYSSMU6_3107841501$
Acq rollback segment _SYSSMU7_1420906157$
Acq rollback segment _SYSSMU8_2178365988$
Acq rollback segment _SYSSMU9_1689884801$
Acq rollback segment _SYSSMU10_3239467560$
kwqmnich: current time:: 12: 35: 23: 0
kwqmnich: instance no 0 repartition flag 1
kwqmnich: initialized job cache structure
*** 2013-12-02 20:35:24.574
ktsmgtur(): TUR was not tuned for 25928 secs
ktsmg_advance_slot(): MMNL advances slot after 25928 seconds
################################################################################
11.分析OPEN後的控制檔案資訊--能力有限分析較少
TRACE檔案內容DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/14/2013 14:23:19
DB Name "BYS3"
Database flags = 0x00404001 0x00001200
Controlfile Creation Timestamp 11/14/2013 14:23:21
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 11/14/2013 14:23:19
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xb200000
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.001eb1b0 --檢查點已經更新
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 00000000 00000000 00000000 00000000 00000000
Max log members = 5, Max data members = 1
Arch list: Head=3, Tail=3, Force scn: 0x0000.001b6c94scn: 0x0000.00000000
Activation ID: 3358374039
SCN compatibility 1
Auto-rollover enabled
Controlfile Checkpointed at scn: 0x0000.001eb212 12/02/2013 20:35:25
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 4, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 4)
THREAD #1 - status:0x2 flags:0x0 dirty:43
low cache rba:(0x6c.3.0) on disk rba:(0x6c.76.0) --on disk rba已經遞增
on disk scn: 0x0000.001eb212 12/02/2013 20:35:24 --on disk scn已經遞增
resetlogs scn: 0x0000.00000001 11/14/2013 14:23:19
heartbeat: 833141767 mount id: 3360007946
相關文章
- 【Oracle ASM】關於asm例項與db例項中的磁碟狀態_詳細分析過程OracleASM
- ORACLE事務和例項恢復過程梳理Oracle
- Oracle 例項恢復詳解Oracle
- ORACLE空間管理實驗8：資料塊格式分析--DUMP結合BBEDOracle
- MySQL 崩潰恢復過程分析MySql
- Oracle redo解析之-2、BBED & DUMP工具使用Oracle Redo
- Oracle例項恢復Oracle
- 需求過程化分析方法-例項分享
- Oracle例項恢復和介質恢復Oracle
- Redis 例項分析工具Redis
- Spring BeanFactory例項化Bean的詳細過程SpringBean
- Oracle例項恢復機制Oracle
- oracle database 例項恢復和介質恢復OracleDatabase
- Oracle dbms_lock.sleep()儲存過程使用技巧-場景-分析-例項-可下載Oracle儲存過程
- Oracle BBED 跳過歸檔實現完全恢復Oracle
- 結合ReentrantLock獲得鎖分析AQS,lock過程分析ReentrantLockAQS
- ORACLE中採用rman備份異機恢復資料庫詳細過程Oracle資料庫
- oracle goldengate 恢復過程OracleGo
- 資料庫的備份與恢復分析及例項資料庫
- Oracle 11g 例項恢復Oracle
- oracle例項恢復的學習理解Oracle
- 詳細分析連結串列的資料結構的實現過程（Java 實現）資料結構Java
- RMAN例項備份與恢復詳解
- 三個例項演示 Java Thread Dump 日誌分析Javathread
- raid5條帶分析方法+ 資料恢復過程AI資料恢復
- Oracle bbed工具的使用Oracle
- ORACLE 死鎖分析過程Oracle
- ORACLE AWR報告詳細分析Oracle
- oracle instance recovery例項恢復小記Oracle
- 閉包用法結合例項詳解
- Spring Ioc原始碼分析系列--Bean例項化過程(二)Spring原始碼Bean
- Spring Ioc原始碼分析系列--Bean例項化過程(一)Spring原始碼Bean
- 一次詳細的RAC 節點例項驅逐分析文件
- 一次RAC例項驅逐詳細分析及解決方案
- Oracle 邏輯恢復工具IMPDP詳解Oracle
- STL原始碼之rotate函式結合圖和例項分析原始碼函式
- MySQL恢復過程MySql
- MySQL 使用mysqld_multi部署單機多例項詳細過程MySql