ORACLE事務和例項恢復過程梳理
1.首先會經過在share pool中的sql語句的解析過程,這一過程只要是針對sql語法,執行計劃這些進行處理,這一部分不細講。
2.接著,到了sql執行後,資料庫從物理檔案讀出資料行相應的資料庫到 buffer cache中(假設此時記憶體不存在相應的資料塊同時不討論鎖的過程),這一過程也涉及到資料塊寫到dirty list,並寫髒塊,為新讀取的資料塊尋找空閒空間的過程 。
以下通過DUMP UNDO 相關 資訊來檢視。
看到index是0x09的事務槽的 state 為 10代表事務正在活動,而其他槽是 9代表事務不活動,
scn 表示務事啟動、提交、回滾的SCN,事務槽 0x09的scn是 0x0009.01e25a30,轉換之後是38686317104。
事物表中0x19槽的dba為0x0a400495即41號檔案的1173號塊塊號這與(與v$transaction檢視中一致)。
我們在看一下這個前映象到底是什麼?
轉儲資料塊
這裡scn表示 最近寫入磁碟的SCN號,此時資料塊中的scn是 0x0009.01e25beb,轉化之後是38686317547。
接著往下看,有本UNDO塊中有51條記錄:
我們找到第51行記錄的物件號是130736,這個正是我們本次事務更改的表。
這裡欄位值是 49 43 4f 4c 24,通過轉換是ICOL$,這正是update前的值。
SQL> select utl_raw.cast_to_varchar2(replace('49 43 4f 4c 24',' ')) from dual; UTL_RAW.CAST_TO_VARCHAR2(REPLACE('49434F4C24','')) ------------------------------------------------------------------------------------- ICOL$
tab 0, row 0, @0x1e87 tl: 249 fb: --H-FL-- lb: 0x0 cc: 55 col 0: [ 3] 53 59 53 col 1: [ 5] 49 43 4f 4c 24<<<<<< 轉換成字元後是'ICOL$' Block dump from disk: buffer tsn: 7 rdba: 0x039c01e3 (14/1835491) scn: 0x0009.01e25a2b seq: 0x02 flg: 0x04 tail: 0x5a2b0602 frmt: 0x02 chkval: 0xf28b type: 0x06=trans data Hex dump of block: st=0, typ_found=1
tl: 248 fb: --H-FL-- lb: 0x2 cc: 55 col 0: [ 3] 53 59 53 col 1: [ 4] 61 61 78 78<<<<<<<<< 轉換成字元後是'aaxx' Block dump from disk: buffer tsn: 7 rdba: 0x039c01e3 (14/1835491) scn: 0x0009.01e25beb seq: 0x01 flg: 0x04 tail: 0x5beb0601 frmt: 0x02 chkval: 0xad91 type: 0x06=trans data Hex dump of block: st=0, typ_found=1
REDO RECORD - Thread:1 RBA: 0x000412.00335b66.0010 LEN: 0x01a0 VLD: 0x0d SCN: 0x0009.01e25beb SUBSCN: 1 07/22/2019 17:53:43 (LWN RBA: 0x000412.00335b66.0010 LEN: 0001 NST: 0001 SCN: 0x0009.01e25beb) CHANGE #1 TYP:0 CLS:1 AFN:14 DBA:0x039c01e3 OBJ:130736 SCN:0x0009.01e25a2b SEQ:2 OP:11.5 ENC:0 RBL:0 KTB Redo op: 0x01 ver: 0x01 compat bit: 4 (post-11) padding: 1 op: F xid: 0x000b.009.0001ba87 uba: 0x0a400495.639a.51 KDO Op code: URP row dependencies Disabled xtype: XA flags: 0x00000000 bdba: 0x039c01e3 hdba: 0x039c01e2 itli: 2 ispac: 0 maxfr: 4858 tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 0 ncol: 55 nnew: 1 size: -1 col 1: [ 4] 61 61 78 78 CHANGE #2 TYP:0 CLS:37 AFN:3 DBA:0x00c00170 OBJ:4294967295 SCN:0x0009.01e25bb3 SEQ:1 OP:5.2 ENC:0 RBL:0 ktudh redo: slt: 0x0009 sqn: 0x0001ba87 flg: 0x0012 siz: 140 fbi: 0 uba: 0x0a400495.639a.51 pxid: 0x0000.000.00000000 CHANGE #3 TYP:0 CLS:38 AFN:41 DBA:0x0a400495 OBJ:4294967295 SCN:0x0009.01e25bb2 SEQ:1 OP:5.1 ENC:0 RBL:0 ktudb redo: siz: 140 spc: 646 flg: 0x0012 seq: 0x639a rec: 0x51 xid: 0x000b.009.0001ba87 ktubl redo: slt: 9 rci: 0 opc: 11.1 [objn: 130736 objd: 130736 tsn: 7] Undo type: Regular undo Begin trans Last buffer split: No Temp Object: No Tablespace Undo: No 0x00000000 prev ctl uba: 0x0a400495.639a.50 prev ctl max cmt scn: 0x0009.01e25b73 prev tx cmt scn: 0x0009.01e25b75 txn start scn: 0x0000.00000000 logon user: 0 prev brb: 171967629 prev bcl: 0 BuExt idx: 0 flg2: 0 KDO undo record: KTB Redo op: 0x03 ver: 0x01 compat bit: 4 (post-11) padding: 1 op: Z KDO Op code: URP row dependencies Disabled xtype: XA flags: 0x00000000 bdba: 0x039c01e3 hdba: 0x039c01e2 itli: 2 ispac: 0 maxfr: 4858 tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0 ncol: 55 nnew: 1 size: 1 col 1: [ 5] 49 43 4f 4c 24 《〈〈更改前映象資料
什麼時候發生normal checkpoint
下面這些操作將會觸發checkpoint事件:
· 日誌切換,通過ALTER SYSTEM SWITCH LOGFILE。
· DBA 發出checkpoint命令,通過ALTER SYSTEM checkpoint。
· 對資料檔案進行熱備時,針對該資料檔案的checkpoint也會進行,ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。
· 當執行ALTER TABLESPACE/DATAFILE READ ONLY的時候。
· SHUTDOWN 命令發出時。
因為每次完全的checkpoint都需要把buffer cache所有的髒塊都寫入到資料檔案中,這樣就是產生一個很大的IO消耗,頻繁的完全checkpoint操作很對系統的效能有很大的影響,為此Oracle引入的增量checkpoint的概念,buffer cache中的髒塊將會按照BCQ佇列的順序持續不斷的被寫入到磁碟當中,同時CKPT程式將會每3秒中檢查DBWn的寫入進度並將相應的RBA資訊記錄到控制檔案中。
有了增量checkpoint之後在進行例項恢復的時候就不需要再從崩潰前的那個完全checkpoint開始應用重做日誌了,只需要從控制檔案中記錄的RBA開始進行恢復操作,這樣能節省恢復的時間。
發生增量checkpoint的先決條件
· 恢復需求設定 (FAST_START_IO_TARGET/FAST_START_MTTR_TARGET)
· LOG_checkpoint_INTERVAL 引數值
· LOG_checkpoint_TIMEOUT 引數值
· 最小的日誌檔案大小
· buffer cache 中的髒塊的數量
啟動資料庫時,如果發現STOP SCN = NULL,表示需要進行crash recovery。
oracle 的例項恢復過程
DATABASE ENTRY *************************************************************************** 。。。。 Controlfile Creation Timestamp 08/21/2017 11:01:49 Incmplt recovery scn: 0x0000.00000000 Resetlogs scn: 0x0000.000e2006 Resetlogs Timestamp 08/21/2017 11:01:51 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/24/2013 11:37:30 Redo Version: compatible=0xb200400 #Data files = 53, #Online files = 53 Database checkpoint: Thread=1 scn: 0x0009.01e35ecd Threads: #Enabled=1, #Open=1, Head=1, Tail=1
CHECKPOINT PROGRESS RECORDS *************************************************************************** (size = 8180, compat size = 8180, section max = 11, section in-use = 0, last-recid= 0, old-recno = 0, last-recno = 0) (extent = 1, blkno = 2, numrecs = 11) THREAD #1 - status:0x2 flags:0x0 dirty:15 low cache rba:(0x413.18481.0)〉〉〉起點 on disk rba:(0x413.1849b.0)〉〉〉終點 on disk scn: 0x0009.01e374ef 07/24/2019 10:23:54 resetlogs scn: 0x0000.000e2006 08/21/2017 11:01:51 heartbeat: 996528373 mount id: 1186014334
low cache rba 以前的更新的髒塊已經寫入資料檔案,不需要重做, on disk rba以後的日誌還沒寫入到online logfile.所以不需要恢復.
DATA FILE #14: name #18: /opt/app/oracle/oradata/xxxx/xxx creation size=2097152 block size=8192 status=0xe head=18 tail=18 dup=1 tablespace 7, index=7 krfil=14 prev_file=13 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:1061 scn: 0x0009.01e35ecd 07/24/2019 07:30:51 Stop scn: 0xffff.ffffffff 09/27/2018 09:20:13 Creation Checkpointed at scn: 0x0000.000f4212 08/21/2017 12:03:57 thread:1 rba:(0x8.3f45.10)
oradebug dump file_hdrs 1 DATA FILE #14: name #18: /opt/app/oracle/oradata/xxxx/xxx creation size=2097152 block size=8192 status=0xe head=18 tail=18 dup=1 tablespace 7, index=7 krfil=14 prev_file=13 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00 Checkpoint cnt:1061 scn: 0x0009.01e35ecd 07/24/2019 07:30:51
alter database open Beginning crash recovery of 1 threads parallel recovery started with 32 processes Started redo scan Completed redo scan read 16 KB redo, 14 data blocks need recovery Started redo application at Thread 1: logseq 1043, block 185196 Recovery of Online Redo Log: Thread 1 Group 2 Seq 1043 Reading mem 0 Mem# 0: /opt/app/oracle/oradata/tlvdb/redo2.log Completed redo application of 0.01MB Completed crash recovery at Thread 1: logseq 1043, block 185228, scn 38686432573《〈〈〈〈〈〈〈〈 14 data blocks read, 14 data blocks written, 16 redo k-bytes read Wed Jul 24 23:44:50 2019 Thread 1 advanced to log sequence 1044 (thread open) Thread 1 opened at log sequence 1044 Current log# 3 seq# 1044 mem# 0: /opt/app/oracle/oradata/tlvdb/redo3.log Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Wed Jul 24 23:44:50 2019 SMON: enabling cache recovery [39962] Successfully onlined Undo Tablespace 2. Undo initialization finished serial:0 start:193329648 end:193329738 diff:90 (0 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 ZHS16GBK
SQL> ALTER SYSTEM DUMP LOGFILE '/opt/app/oracle/oradata/tlvdb/redo1.log' SCN MIN 38686383821 SCN MAX 38686389487; System altered. Opcodes *.* RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff SCNs: scn: 0x0009.01e35ecd (38686383821) thru scn: 0x0009.01e374ef (38686389487) Times: creation thru eternity FILE HEADER: 。。。。 Control Seq=459718=0x703c6, File size=4194304=0x400000 File Number=1, Blksiz=512, File Type=2 LOG descrip:"Thread 0001, Seq# 0000001042, SCN 0x000901d8f38d-0x000901e35ecd" thread: 1 nab: 0x384d91 seq: 0x00000412 hws: 0x3 eot: 0 dis: 0 resetlogs count: 0x38c7849f scn: 0x0000.000e2006 (925702) prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1) Low scn: 0x0009.01d8f38d (38685701005) 07/08/2019 09:24:12 Next scn: 0x0009.01e35ecd (38686383821) 07/24/2019 07:30:51 Enabled scn: 0x0000.000e2006 (925702) 08/21/2017 11:01:51 Thread closed scn: 0x0009.01d8f38d (38685701005) 07/08/2019 09:24:12 Disk cksum: 0x56ca Calc cksum: 0x56ca Terminal recovery stop scn: 0x0000.00000000 Terminal recovery 01/01/1988 00:00:00 Most recent redo scn: 0x0000.00000000 Largest LWN: 2395 blocks
3.資料檔案中包含已提交或未提交的資料,儘管存在未提交的資料,此時資料庫已經被開啟,允許使用者連線,此時針對
未提交的事務被進行回滾
前滾一旦完畢,SMON程式立即開啟資料庫。但是,這時的資料庫中還含有那些中間狀態的、既沒有提交又沒有回滾的髒塊,這種髒塊是不能存在於資料庫中的,因為它們並沒有被提交,必須被回滾。開啟資料庫以後,SMON程式會在後臺進行回滾,此時會從Undo空間中尋找到舊版本SCN的資料塊資訊,來進行SGA中Buffer Cache資料塊恢復。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29863023/viewspace-2652139/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle例項恢復和介質恢復Oracle
- oracle database 例項恢復和介質恢復OracleDatabase
- Oracle例項恢復Oracle
- Oracle例項恢復機制Oracle
- Oracle 例項恢復詳解Oracle
- oracle goldengate 恢復過程OracleGo
- Oracle 11g 例項恢復Oracle
- Oracle例項恢復——說說前滾和回滾Oracle
- ORACLE資料庫事務處理和故障恢復Oracle資料庫
- oracle例項恢復的學習理解Oracle
- ORACLE例項恢復過程詳細分析--使用dump、BBED等多種工具結合分析Oracle
- oracle instance recovery例項恢復小記Oracle
- MySQL恢復過程MySql
- Oracle 業務資料unload恢復過程Oracle
- 恢復被覆蓋的儲存過程 oracle儲存過程Oracle
- oracle 11C rman 恢復到單例項Oracle單例
- SCN、Checkpoint、例項恢復介質恢復理解
- 【原創】Oracle 事務探索與例項(二)Oracle
- 【原創】 Oracle 事務探索與例項(一)Oracle
- 關於oracle例項恢復的前滾和回滾的理解Oracle
- ORACLE RMAN恢復中的一些注意事項Oracle
- rac恢復到單例項單例
- 單例項恢復至RAC單例
- 資料塊恢復例項
- 一次Oracle資料庫恢復過程Oracle資料庫
- ORACLE主從中斷後,如何恢復(單例項)Oracle單例
- oracle 關於例項恢復的一個討論Oracle
- Db2恢復注意事項DB2
- Oracle 恢復一例Oracle
- RAC asm恢復到單例項ASM單例
- 例項恢復的簡要解析
- 資料庫恢復過程資料庫
- Oracle資料檔案損壞恢復例項二則Oracle
- OS 刪除oracle資料檔案恢復過程Oracle
- MySQL定時任務與儲存過程例項MySql儲存過程
- MySQL 事務提交過程MySql
- vsan儲存資料恢復過程—虛擬機器故障恢復過程資料恢復虛擬機
- 儲存過程注意事項儲存過程