ORACLE事務(wù)和實(shí)例的恢復(fù)過(guò)程講解

156次閱讀

共計(jì) 13193 個(gè)字符，預(yù)計(jì)需要花費(fèi) 33 分鐘才能閱讀完成。

這篇文章主要介紹“ORACLE 事務(wù)和實(shí)例的恢復(fù)過(guò)程講解”，在日常操作中，相信很多人在 ORACLE 事務(wù)和實(shí)例的恢復(fù)過(guò)程講解問(wèn)題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”O(jiān)RACLE 事務(wù)和實(shí)例的恢復(fù)過(guò)程講解”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著丸趣 TV 小編一起來(lái)學(xué)習(xí)吧！

從 oracle 的一個(gè)事務(wù)說(shuō)起：

例如當(dāng)我們發(fā)起一個(gè) update 語(yǔ)句更改某一行數(shù)據(jù)，例如更改 zabbix.cwdtest 的 table_name= ICOL$ 為 aaxx。該行記錄在 14 號(hào)文件，1835491 塊

1. 首先會(huì)經(jīng)過(guò)在 share pool 中的 sql 語(yǔ)句的解析過(guò)程，這一過(guò)程只要是針對(duì) sql 語(yǔ)法，執(zhí)行計(jì)劃這些進(jìn)行處理，這一部分不細(xì)講。

2. 接著，到了 sql 執(zhí)行后，數(shù)據(jù)庫(kù)從物理文件讀出數(shù)據(jù)行相應(yīng)的數(shù)據(jù)庫(kù)到 buffer cache 中（假設(shè)此時(shí)內(nèi)存不存在相應(yīng)的數(shù)據(jù)塊同時(shí)不討論鎖的過(guò)程），這一過(guò)程也涉及到數(shù)據(jù)塊寫到 dirty list, 并寫臟塊，為新讀取的數(shù)據(jù)塊尋找空閑空間的過(guò)程。

3. 同時(shí)會(huì)分配回滾段并在 undo 段再保留一份修改前的數(shù)據(jù)塊映像。

以下通過(guò) DUMP UNDO 相關(guān) 信息來(lái)查看。

看到 index 是 0x09 的事務(wù)槽的 state 為 10 代表事務(wù)正在活動(dòng)，而其他槽是 9 代表事務(wù)不活動(dòng)，

scn 表示務(wù)事啟動(dòng)、提交、回滾的 SCN，事務(wù)槽 0x09 的 scn 是 0x0009.01e25a30, 轉(zhuǎn)換之后是 38686317104。

dba 表示 uba: 第一部分的 undo 塊地址，這個(gè) DBA 是 (rollback) 回滾的起始點(diǎn)，也就是說(shuō)是記錄事務(wù)修改的最后一條記錄所在 UNDO 塊的地址。

事物表中 0x19 槽的 dba 為 0x0a400495 即 41 號(hào)文件的 1173 號(hào)塊塊號(hào)這與（與 v$transaction 視圖中一致）。

我們?cè)诳匆幌逻@個(gè)前鏡像到底是什么？

轉(zhuǎn)儲(chǔ)數(shù)據(jù)塊

這里 scn 表示最近寫入磁盤的 SCN 號(hào)，此時(shí)數(shù)據(jù)塊中的 scn 是 0x0009.01e25beb，轉(zhuǎn)化之后是 38686317547。

對(duì)于 DBWR，每次刷新臟塊后，會(huì)去維護(hù)這個(gè) block 的 SCN 號(hào)，代表這個(gè) block 的數(shù)據(jù)版本。

接著往下看，有本 UNDO 塊中有 51 條記錄：

我們找到第 51 行記錄的對(duì)象號(hào)是 130736，這個(gè)正是我們本次事務(wù)更改的表。

這里字段值是 49 43 4f 4c 24，通過(guò)轉(zhuǎn)換是 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$

而 bdba: 0x039c01e3 是該記錄對(duì)應(yīng)的數(shù)據(jù)塊地址，該行記錄正是在 14 號(hào)文件，1835491 塊

SQL select to_number(039c01e3 , xxxxxxxxxxx)from dual;TO_NUMBER(039C01E3 , XXXXXXXXXXX)———————————– 60555747SQL select dbms_utility.data_block_address_file(60555747)file#, dbms_utility.data_block_address_block(60555747) block from dual; FILE# BLOCK————- ————- 14 1835491

整個(gè)與 UNDO 相關(guān)的有幾個(gè) SCN，我們重新整理下：

undo header 中的 SCN: 表示務(wù)事啟動(dòng)、提交、回滾的 SCN，事務(wù)槽 0x09 的 scn 是 0x0009.01e25a30, 轉(zhuǎn)換之后是 38686317104。

undo block 中 scn: 表示最近寫入磁盤的 SCN 號(hào)，此時(shí)數(shù)據(jù)塊中的 scn 是 0x0009.01e25beb，轉(zhuǎn)化之后是 38686317547

undo block 修改記錄行的 SCN:

ctl max scn: 0x0009.01e25b73 轉(zhuǎn)化之后是 38686317427

prv tx scn: 0x0009.01e25b75，轉(zhuǎn)化之后是 38686317429

txn start scn: scn: 0x0000.00000000，這里是 0。

而此時(shí) redo 記錄的信息如下：

alter system dump logfile /opt/app/oracle/oradata/tlvdb/redo1.log

4.. 為事務(wù)修改數(shù)據(jù)塊，并在執(zhí)行更改完成后，針對(duì)此數(shù)據(jù)塊的修改也生成 redo 信息。這里是將該語(yǔ)句所影響的并被讀入 db buffer 中的這些行數(shù)據(jù)的 rowid 及要更新的原值和新值及 scn 等信息從 PGA 逐條的寫入 redo log buffer 中，

以下分別 UPDATE 前后執(zhí)行 alter system dump datafile 14 block 1835491; 來(lái) dump 出數(shù)據(jù)塊。

執(zhí)行 UPDATE 之前：

tab 0, row 0, @0x1e87tl: 249 fb: –H-FL– lb: 0x0 cc: 55col 0: [ 3] 53 59 53col 1: [ 5] 49 43 4f 4c 24 轉(zhuǎn)換成字符后是 ICOL$ Block dump from disk:buffer tsn: 7 rdba: 0x039c01e3 (14/1835491)scn: 0x0009.01e25a2b seq: 0x02 flg: 0x04 tail: 0x5a2b0602frmt: 0x02 chkval: 0xf28b type: 0x06=trans dataHex dump of block: st=0, typ_found=1

這里 scn: 0x0009.01e25a2b 轉(zhuǎn)換之后是 38686317099

執(zhí)行 UPDATE 之后：

tl: 248 fb: –H-FL– lb: 0x2 cc: 55col 0: [ 3] 53 59 53col 1: [ 4] 61 61 78 78 轉(zhuǎn)換成字符后是 aaxx Block dump from disk:buffer tsn: 7 rdba: 0x039c01e3 (14/1835491)scn: 0x0009.01e25beb seq: 0x01 flg: 0x04 tail: 0x5beb0601frmt: 0x02 chkval: 0xad91 type: 0x06=trans dataHex dump of block: st=0, typ_found=1

這里 scn: 0x0009.01e25beb 轉(zhuǎn)換之后是 38686317547

這里說(shuō)明，當(dāng)事務(wù)中修改了數(shù)據(jù)塊，不管事務(wù)有無(wú)提交，數(shù)據(jù)臟塊會(huì)隨著 dbw 進(jìn)程的機(jī)制寫入數(shù)據(jù)文件中。

而在 REDO 日志中會(huì)記錄操作的記錄，并記錄本次 undo 操作的信息，即修改前的信息：

REDO RECORD – Thread:1 RBA: 0x000412.00335b66.0010 LEN: 0x01a0 VLD: 0x0dSCN: 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:0KTB Redo op: 0x01 ver: 0x01 compat bit: 4 (post-11) padding: 1op: F xid: 0x000b.009.0001ba87 uba: 0x0a400495.639a.51KDO Op code: URP row dependencies Disabled xtype: XA flags: 0x00000000 bdba: 0x039c01e3 hdba: 0x039c01e2itli: 2 ispac: 0 maxfr: 4858tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 0ncol: 55 nnew: 1 size: -1col 1: [ 4] 61 61 78 78CHANGE #2 TYP:0 CLS:37 AFN:3 DBA:0x00c00170 OBJ:4294967295 SCN:0x0009.01e25bb3 SEQ:1 OP:5.2 ENC:0 RBL:0ktudh redo: slt: 0x0009 sqn: 0x0001ba87 flg: 0x0012 siz: 140 fbi: 0 uba: 0x0a400495.639a.51 pxid: 0x0000.000.00000000CHANGE #3 TYP:0 CLS:38 AFN:41 DBA:0x0a400495 OBJ:4294967295 SCN:0x0009.01e25bb2 SEQ:1 OP:5.1 ENC:0 RBL:0ktudb 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: 0KDO undo record:KTB Redo op: 0x03 ver: 0x01 compat bit: 4 (post-11) padding: 1op: ZKDO Op code: URP row dependencies Disabled xtype: XA flags: 0x00000000 bdba: 0x039c01e3 hdba: 0x039c01e2itli: 2 ispac: 0 maxfr: 4858tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 0ncol: 55 nnew: 1 size: 1col 1: [ 5] 49 43 4f 4c 24 《〈〈更改前鏡像數(shù)據(jù)

5. 執(zhí)行 commit 命令，聲明 redo log buffer 中的 redo 處于 commit 狀態(tài)，然后修改事務(wù)表相應(yīng) slot，聲明事務(wù)已提交，最后通知 lgwr 進(jìn)程將 redo log buffer 中的數(shù)據(jù)寫入 redo log file。待 lgwr 進(jìn)程通知已經(jīng)寫入完成后，向用戶發(fā)出 commit 完成的信息。

在事務(wù)的過(guò)程中涉及到三個(gè)進(jìn)程，CKPT,DBWn,LGWR 進(jìn)程：

CKPT：檢查點(diǎn)進(jìn)程（Checkpoint Process）只是更新數(shù)據(jù)文件的文件首部，以輔助建立檢查點(diǎn)的進(jìn)程

ckpt 觸發(fā)條件：

什么時(shí)候發(fā)生 normal checkpoint

下面這些操作將會(huì)觸發(fā) checkpoint 事件：

· 日志切換，通過(guò) ALTER SYSTEM SWITCH LOGFILE。

· DBA 發(fā)出 checkpoint 命令，通過(guò) ALTER SYSTEM checkpoint。

· 對(duì)數(shù)據(jù)文件進(jìn)行熱備時(shí)，針對(duì)該數(shù)據(jù)文件的 checkpoint 也會(huì)進(jìn)行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。

· 當(dāng)運(yùn)行 ALTER TABLESPACE/DATAFILE READ ONLY 的時(shí)候。

· SHUTDOWN 命令發(fā)出時(shí)。

因?yàn)槊看瓮耆?checkpoint 都需要把 buffer cache 所有的臟塊都寫入到數(shù)據(jù)文件中，這樣就是產(chǎn)生一個(gè)很大的 IO 消耗，頻繁的完全 checkpoint 操作很對(duì)系統(tǒng)的性能有很大的影響，為此 Oracle 引入的增量 checkpoint 的概念，buffer cache 中的臟塊將會(huì)按照 BCQ 隊(duì)列的順序持續(xù)不斷的被寫入到磁盤當(dāng)中，同時(shí) CKPT 進(jìn)程將會(huì)每 3 秒中檢查 DBWn 的寫入進(jìn)度并將相應(yīng)的 RBA 信息記錄到控制文件中。

有了增量 checkpoint 之后在進(jìn)行實(shí)例恢復(fù)的時(shí)候就不需要再?gòu)谋罎⑶暗哪莻€(gè)完全 checkpoint 開始應(yīng)用重做日志了，只需要從控制文件中記錄的 RBA 開始進(jìn)行恢復(fù)操作，這樣能節(jié)省恢復(fù)的時(shí)間。

發(fā)生增量 checkpoint 的先決條件

· 恢復(fù)需求設(shè)定（FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）

· LOG_checkpoint_INTERVAL 參數(shù)值

· LOG_checkpoint_TIMEOUT 參數(shù)值

· 最小的日志文件大小

· buffer cache 中的臟塊的數(shù)量

DBWn：數(shù)據(jù)庫(kù)塊寫入器（Database Block Writer）負(fù)責(zé)將臟塊寫入磁盤的后臺(tái)進(jìn)程。

觸發(fā) DBWR 進(jìn)程的條件有：

1.DBWR 超時(shí)，大約 3 秒

2. 系統(tǒng)中沒(méi)有多余的空緩沖區(qū)來(lái)存放數(shù)據(jù)

3.CKPT 進(jìn)程觸發(fā) DBWR

4.free buffer waits 40% 觸發(fā) dbwr 吧 lruw 臟塊寫入磁盤

5. 關(guān)機(jī)會(huì)觸發(fā) dbwr 寫

6.alter system checkpoint 觸發(fā) dbwr 寫

7.redo 日志切換觸發(fā) dbwr 寫

8. 表空間 offline /online 觸發(fā) dbwr 寫

LGWR：日志寫入器（Log Writer）負(fù)責(zé)將 SGA 中重做日志緩沖區(qū)的內(nèi)容刷新輸出到磁盤。

觸發(fā) LGWn 工作的時(shí)點(diǎn)有幾個(gè)：

1. 用戶提交，用戶提交時(shí)必須寫 LOGFILE.

2. 有 1 / 3 重做日志緩沖區(qū)未被寫入磁盤

3. 有大于 1M 的重做日志緩沖區(qū)未被寫入磁盤

4. 3 秒超時(shí)

5. DBWR 需要寫入的數(shù)據(jù)的 SCN 大于 LGWR 記錄的 SCN，DBWR 觸發(fā) LGWR 寫入。

這三個(gè)進(jìn)程都是為了更好地完成一件事：安全高效地實(shí)現(xiàn)內(nèi)存數(shù)據(jù)塊寫入數(shù)據(jù)文件，就是將內(nèi)存中修改的數(shù)據(jù)反映到硬盤的數(shù)據(jù)文件上。我在事務(wù)未提交時(shí)做一個(gè)刷新 buffer cache, 此時(shí)發(fā)現(xiàn)數(shù)據(jù)塊已經(jīng)被刷新到磁盤文件中，通過(guò)以上三個(gè)進(jìn)程的觸發(fā)條件也可以看出刷新數(shù)據(jù)塊與事務(wù)是否提交關(guān)系不大。

首先，日志文件的寫入是很頻繁的。LGWn 會(huì)不斷將日志信息從 Log Buffer 中寫入 Online Redo Log；

其次，在日志文件上，可以有三個(gè)類型的事務(wù)事件。

1、事務(wù)結(jié)束，已經(jīng)被 commit，之后打過(guò) checkpoint 檢查點(diǎn)。

2、事務(wù)結(jié)束，已經(jīng)被 commit，之后沒(méi)有打入 checkpint 檢查點(diǎn)。

3、事務(wù)未結(jié)束，沒(méi)有 commit。

那么當(dāng)我有一個(gè)事務(wù)一直未提交，此時(shí)發(fā)生斷電，數(shù)據(jù)庫(kù)直接 crash，在重啟后 ORACLE 是如何保證數(shù)據(jù)一致性呢？

啟動(dòng)數(shù)據(jù)庫(kù)時(shí)，如果發(fā)現(xiàn)有 datafile header 的 START SCN 不等于儲(chǔ)存于 CONTROLFILE 的 DATAFILE SCN，表示需要進(jìn)行介質(zhì)恢復(fù)。

啟動(dòng)數(shù)據(jù)庫(kù)時(shí)，如果發(fā)現(xiàn) STOP SCN = NULL，表示需要進(jìn)行 crash recovery。

oracle 的實(shí)例恢復(fù)過(guò)程

實(shí)例恢復(fù)主要經(jīng)歷三個(gè)階段：cache recovery、open database、transaction recovery

1. 首先 oracle 對(duì)比控制文件中檢查點(diǎn) scn 與數(shù)據(jù)文件頭部 scn，發(fā)現(xiàn)不一致

但我開啟一個(gè)事務(wù)，并不作提交時(shí)，首先來(lái)看控制文件中記錄的 SCN 情況：

最近一次完全檢查點(diǎn) checkpoint change scn:

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

這里是 Database checkpoint: Thread=1 scn: 0x0009.01e35ecd，轉(zhuǎn)換之后是 38686383821。

而增量檢查點(diǎn) SCN

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:15low cache rba:(0x413.18481.0)〉〉〉起點(diǎn) on disk rba:(0x413.1849b.0)〉〉〉終點(diǎn) on disk scn: 0x0009.01e374ef 07/24/2019 10:23:54 resetlogs scn: 0x0000.000e2006 08/21/2017 11:01:51heartbeat: 996528373 mount id: 1186014334

low cache rba 就是 CKPT 記錄的 DBWR 寫臟塊的進(jìn)度是最近一次完全 checkpoint scn 的位置, on disk rba 就是 LGWR 的寫進(jìn)度，是 lgwr 寫日志文件的最末位置的地址 low cache rba 以前的更新的臟塊已經(jīng)寫入數(shù)據(jù)文件，不需要重做, on disk rba 以后的日志還沒(méi)寫入到 online logfile. 所以不需要恢復(fù).

而此時(shí)有 15 個(gè)臟塊。

on disk scn 表示當(dāng)前系統(tǒng)最新的 rba 對(duì)應(yīng)的 scn, 由 CKPT 進(jìn)程每 3 秒跟新一次。如果數(shù)據(jù)庫(kù)異常宕機(jī)，那么 CRASH RECOVER 時(shí)服務(wù)器至少要應(yīng)用到該 SCN 為止。

這里的增量檢查點(diǎn) SCN 是 38686389487，這個(gè) scn 會(huì)比全量檢查點(diǎn)后的 SCN 大。

控制文件中記錄的數(shù)據(jù)文件 SCN：

DATA FILE #14: name #18: /opt/app/oracle/oradata/xxxx/xxxcreation 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)

這里記錄的數(shù)據(jù)文件的 scn
也同樣是 38686383821，而 Stop scn 是無(wú)窮大，表示當(dāng)前數(shù)據(jù)庫(kù)是正常打開狀態(tài)，或者異常關(guān)閉狀態(tài)。

再看數(shù)據(jù)文件頭中 SCN：

oradebug dump file_hdrs 1DATA FILE #14: name #18: /opt/app/oracle/oradata/xxxx/xxxcreation 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

這里記錄的數(shù)據(jù)文件頭 SCN
與控制文件中記錄的一致。

以上這種情況當(dāng)發(fā)現(xiàn)控制文件中數(shù)據(jù)文件的 SCN 與數(shù)據(jù)文件頭中記錄的 SCN 一致，即不會(huì)發(fā)生介質(zhì)恢復(fù)。

當(dāng)啟動(dòng)時(shí)發(fā)現(xiàn) Stop scn 是無(wú)窮大, 則表示數(shù)據(jù)庫(kù)是異常關(guān)閉了，需要進(jìn)行 crash recovery，即回滾。而其中增量檢查點(diǎn)的作用就是記錄了該從哪個(gè)地方回滾到那個(gè)地方。

此時(shí)，我們模式數(shù)據(jù)庫(kù) crash，然后重啟：

alter database openBeginning crash recovery of 1 threads parallel recovery started with 32 processesStarted redo scanCompleted redo scan read 16 KB redo, 14 data blocks need recoveryStarted redo application at Thread 1: logseq 1043, block 185196Recovery of Online Redo Log: Thread 1 Group 2 Seq 1043 Reading mem 0 Mem# 0: /opt/app/oracle/oradata/tlvdb/redo2.logCompleted redo application of 0.01MBCompleted crash recovery at Thread 1: logseq 1043, block 185228, scn 38686432573《〈〈〈〈〈〈〈〈 14 data blocks read, 14 data blocks written, 16 redo k-bytes readWed Jul 24 23:44:50 2019Thread 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.logSuccessful open of redo thread 1MTTR advisory is disabled because FAST_START_MTTR_TARGET is not setWed Jul 24 23:44:50 2019SMON: 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 completedSMON: enabling tx recoveryDatabase Characterset is ZHS16GBK

2. 從最后檢查點(diǎn)之后到日志文件尾部將被重新應(yīng)用到數(shù)據(jù)文件，同時(shí)產(chǎn)生 undo 信息(回滾)，此階段也稱為 cache recovery

當(dāng)數(shù)據(jù)庫(kù)中有已經(jīng) COMMIT 但沒(méi)有寫入磁盤的數(shù)據(jù)塊，當(dāng)數(shù)據(jù)庫(kù) CRASH 后重啟，會(huì)從控制文件中最近一次完全檢查點(diǎn)位置到最后一次增量檢查點(diǎn)位置，例如上面從 38686383821 到 38686389487。

然后到 redo 日志文件中找到該檢查點(diǎn)位置，然后從該檢查點(diǎn)位置開始往下到增量檢查點(diǎn)位置，應(yīng)用所有的 redo，而其尋找 redo 條目是從 low cache rba 到 on disk rba，從而在 buffer cache 里又恢復(fù)了實(shí)例崩潰那個(gè)時(shí)間點(diǎn)的狀態(tài)。這個(gè)過(guò)程叫做前滾，前滾完畢以后，

buffer cache 里既有崩潰時(shí)已經(jīng)提交還沒(méi)有寫入數(shù)據(jù)文件的臟數(shù)據(jù)塊，也還有事務(wù)被突然終止，而導(dǎo)致的既沒(méi)有提交又沒(méi)有回滾的事務(wù)所弄臟的數(shù)據(jù)塊。

可以把這個(gè)過(guò)程的 redo 給 dump 出來(lái)：

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. 數(shù)據(jù)文件中包含已提交或未提交的數(shù)據(jù)，盡管存在未提交的數(shù)據(jù)，此時(shí)數(shù)據(jù)庫(kù)已經(jīng)被打開，允許用戶連接, 此時(shí)針對(duì)未提交的事務(wù)被進(jìn)行回滾

前滾一旦完畢，SMON 進(jìn)程立即打開數(shù)據(jù)庫(kù)。但是，這時(shí)的數(shù)據(jù)庫(kù)中還含有那些中間狀態(tài)的、既沒(méi)有提交又沒(méi)有回滾的臟塊，這種臟塊是不能存在于數(shù)據(jù)庫(kù)中的，因?yàn)樗鼈儾](méi)有被提交，必須被回滾。打開數(shù)據(jù)庫(kù)以后，SMON 進(jìn)程會(huì)在后臺(tái)進(jìn)行回滾，此時(shí)會(huì)從 Undo 空間中尋找到舊版本 SCN 的數(shù)據(jù)塊信息，來(lái)進(jìn)行 SGA 中 Buffer Cache 數(shù)據(jù)塊恢復(fù)。

幾個(gè)疑問(wèn)：

一，當(dāng) log buffer 中的數(shù)據(jù)還沒(méi)來(lái)得及寫入 redo file, 此時(shí)數(shù)據(jù)庫(kù) crash 掉，那這部分丟失 redo 怎么辦？

Oracle 采取在事務(wù)提交的時(shí)候?qū)⒑瓦@個(gè)事務(wù)相關(guān)的 REDO LOG 數(shù)據(jù)，包括 COMMIT 記錄，都必須從 LOG BUFFER 中寫入 REDO LOG 文件，此時(shí)事務(wù)提交成功的信號(hào)才能發(fā)送給用戶進(jìn)程。這樣便可以確保當(dāng)已經(jīng)提交的事務(wù)中的部分 BUFFER CACHE 還沒(méi)有被寫入數(shù)據(jù)文件時(shí)發(fā)生了實(shí)例故障，在重啟后做實(shí)例恢復(fù)的時(shí)候，也可以通過(guò) REDO LOG 的信息，將不一致的數(shù)據(jù)前滾。

如果某事務(wù)未提交，此時(shí)產(chǎn)生的 REDO 仍在 LOG BUFFER 中，當(dāng)數(shù)據(jù)庫(kù)突然 CRASH,log buffer 數(shù)據(jù)也丟失了，我們可以確認(rèn)這部分?jǐn)?shù)據(jù)是沒(méi)有提交的，將會(huì)被回滾，但是，redo 信息沒(méi)有寫入磁盤，不存在了。也沒(méi)辦法通過(guò) redo 構(gòu)造數(shù)據(jù)塊，怎么辦？

其實(shí)這里是理解錯(cuò)了，未寫入 redo_file, 也未寫入 db_file, 那么發(fā)生數(shù)據(jù)庫(kù)失敗恢復(fù)時(shí), 數(shù)據(jù)庫(kù)將直接丟棄該 DML 操作, 反正該操作尚未 commit, 丟掉了也沒(méi)關(guān)系，并且因?yàn)槲磳懭霐?shù)據(jù)文件，沒(méi)必要進(jìn)行構(gòu)造 UNDO 回滾。

二、UNDO 有沒(méi)有寫緩存情況，如果有 UNDO 丟失怎么辦？

undo 有 undo buffer , 從以上可以看出，redo 日志會(huì)記錄了事務(wù)的 redo 和 undo 信息。所以不用擔(dān)心

三、實(shí)例恢復(fù)過(guò)程主要使用的四個(gè) SCN：

Control file 三個(gè)地方為：

1、System checkpoint SCN

select checkpoint_change# from v$database;

這里應(yīng)該有完整檢查點(diǎn)的 SCN，完整檢查點(diǎn)的 SCN 會(huì)更新數(shù)據(jù)文件及數(shù)據(jù)文件頭的 SCN，增量檢查點(diǎn) SCN 只在控制文件中更新。

2、Datafile checkpoint SCN

set linesize 400

col name for a50

select name, checkpoint_change# from v$datafile where file#=14;

3、Stop SCN

select name,last_change# from v$datafile where file#=14;

正常 datafile 在 read-write mode 運(yùn)作下，last_change# 一定是 null

還有一個(gè) SCN 在 datafile header 內(nèi)

4、Start SCN

select name,checkpoint_change# from v$datafile_header where file#=14;

到此，關(guān)于“ORACLE 事務(wù)和實(shí)例的恢復(fù)過(guò)程講解”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

正文完