這篇文章主要介紹“ORACLE事務和實例的恢復過程講解”，在日常操作中，相信很多人在ORACLE事務和實例的恢復過程講解問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”O(jiān)RACLE事務和實例的恢復過程講解”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：空間域名、網頁空間、營銷軟件、網站建設、順平網站維護、網站推廣。

從oracle 的一個事務說起：

例如當我們發(fā)起一個update 語句更改某一行數據，例如更改zabbix.cwdtest 的 table_name='ICOL$' 為'aaxx'。該行記錄在14號文件，1835491塊

1.首先會經過在share pool中的sql語句的解析過程，這一過程只要是針對sql語法，執(zhí)行計劃這些進行處理，這一部分不細講。

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

3.同時會分配回滾段并在undo段再保留一份修改前的數據塊映像。

以下通過DUMP UNDO 相關 信息來查看。

看到index是0x09的事務槽的state 為10代表事務正在活動，而其他槽是9代表事務不活動，

scn   表示務事啟動、提交、回滾的SCN，事務槽0x09的scn是 0x0009.01e25a30,轉換之后是38686317104。

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

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

我們在看一下這個前鏡像到底是什么？

轉儲數據塊

這里scn表示 最近寫入磁盤的SCN號，此時數據塊中的scn是0x0009.01e25beb，轉化之后是38686317547。

對于DBWR，每次刷新臟塊后，會去維護這個block的SCN號，代表這個block的數據版本。

接著往下看，有本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$

而bdba: 0x039c01e3 是該記錄對應的數據塊地址，該行記錄正是在14號文件，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

整個與UNDO相關的有幾個SCN，我們重新整理下：

undo header 中的SCN: 表示務事啟動、提交、回滾的SCN，事務槽0x09的scn是 0x0009.01e25a30,轉換之后是38686317104。

undo block中scn:表示 最近寫入磁盤的SCN號，此時數據塊中的scn是0x0009.01e25beb，轉化之后是38686317547

undo block修改記錄行的SCN:

ctl max scn: 0x0009.01e25b73 轉化之后是38686317427

prv tx scn: 0x0009.01e25b75 ，轉化之后是38686317429

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

而此時redo記錄的信息如下：

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

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

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

執(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<<<<<< 轉換成字符后是'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 轉換之后是38686317099

執(zhí)行UPDATE 之后：

tl: 248 fb: --H-FL-- lb: 0x2 cc: 55col 0: [ 3] 53 59 53col 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: 0x5beb0601frmt: 0x02 chkval: 0xad91 type: 0x06=trans dataHex dump of block: st=0, typ_found=1

這里scn: 0x0009.01e25beb 轉換之后是38686317547

這里說明，當事務中修改了數據塊，不管事務有無提交，數據臟塊會隨著 dbw進程的機制寫入數據文件中。 

而在 REDO日志中會記錄操作的記錄，并記錄本次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 《〈〈更改前鏡像數據

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

在事務的過程中涉及到三個進程，CKPT,DBWn,LGWR進程 ：

CKPT：檢查點進程（Checkpoint Process）只是更新數據文件的文件首部，以輔助建立檢查點的進程

ckpt 觸發(fā)條件：

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

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

·         日志切換，通過ALTER SYSTEM SWITCH LOGFILE。

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

·         對數據文件進行熱備時，針對該數據文件的checkpoint也會進行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。

·         當運行ALTER TABLESPACE/DATAFILE READ ONLY的時候。

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

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

有了增量checkpoint之后在進行實例恢復的時候就不需要再從崩潰前的那個完全checkpoint開始應用重做日志了，只需要從控制文件中記錄的RBA開始進行恢復操作，這樣能節(jié)省恢復的時間。

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

·         恢復需求設定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）

·         LOG_checkpoint_INTERVAL參數值

·         LOG_checkpoint_TIMEOUT參數值

·         最小的日志文件大小

·         buffer cache中的臟塊的數量

DBWn：數據庫塊寫入器（Database Block Writer）負責將臟塊寫入磁盤的后臺進程。 

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

1.DBWR超時，大約3秒 

2.系統(tǒng)中沒有多余的空緩沖區(qū)來存放數據 

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

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

5.關機會觸發(fā)dbwr寫

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

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

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

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

           觸發(fā)LGWn工作的時點有幾個：

  1. 用戶提交 ，用戶提交時必須寫LOGFILE.

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

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

  4. 3秒超時 

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

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

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

其次，在日志文件上，可以有三個類型的事務事件。

1、事務結束，已經被commit，之后打過checkpoint檢查點。

2、事務結束，已經被commit，之后沒有打入checkpint檢查點。

3、事務未結束，沒有commit。

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

啟動數據庫時，如果發(fā)現有datafile header的START SCN 不等于儲存于CONTROLFILE的DATAFILE SCN，表示需要進行介質恢復。

啟動數據庫時，如果發(fā)現STOP SCN = NULL，表示需要進行crash recovery。

oracle 的實例恢復過程

實例恢復主要經歷三個階段： cache recovery、open database、transaction recovery

1.首先oracle對比控制文件中檢查點scn與數據文件頭部scn，發(fā)現不一致

但我開啟一個事務，并不作提交時，首先來看控制文件中記錄的 SCN情況：

最近一次完全檢查點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，轉換之后是38686383821。

而增量檢查點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)〉〉〉起點  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:51heartbeat: 996528373 mount id: 1186014334

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

而此時有15個臟塊。 

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

這里的增量檢查點SCN是38686389487，這個scn會比全量檢查點后的SCN大。

控制文件中記錄的數據文件 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)

這里記錄的數據文件的scn 也同樣是 38686383821，而Stop scn是無窮大，表示當前數據庫是正常打開狀態(tài)，或者異常關閉狀態(tài)。

再看數據文件頭中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

這里記錄的數據文件頭SCN 與控制文件中記錄的一致。 

以上這種情況當發(fā)現控制文件中數據文件的SCN與數據文件頭中記錄 的SCN一致，即不會發(fā)生介質恢復。

當啟動時發(fā)現Stop scn是無窮大,則表示數據庫是異常關閉了，需要進行crash recovery，即回滾。而其中增量檢查點的作用就是記錄了該從哪個地方回滾到那個地方。

此時，我們 模式 數據庫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.從最后檢查點之后到日志文件尾部將被重新應用到數據文件，同時產生undo信息(回滾)，此階段也稱為cache recovery

當數據庫中有已經COMMIT但沒有寫入磁盤的數據塊，當數據庫CRASH后重啟，會從控制文件中最近一次完全檢查點位置到最后一次增量檢查點位置，例如上面從38686383821到38686389487。

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

buffer cache里既有崩潰時已經提交還沒有寫入數據文件的臟數據塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄臟的數據塊。

可以把這個過程的redo給dump出來： 

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進程立即打開數據庫。但是，這時的數據庫中還含有那些中間狀態(tài)的、既沒有提交又沒有回滾的臟塊，這種臟塊是不能存在于數據庫中的，因為它們并沒有被提交，必須被回滾。打開數據庫以后，SMON進程會在后臺進行回滾，此時會從Undo空間中尋找到舊版本SCN的數據塊信息，來進行SGA中Buffer Cache數據塊恢復。

幾個疑問：

一，當log buffer 中的數據還沒來得及寫入redo file,此時數據庫crash掉，那這部分丟失redo怎么辦？

Oracle 采取在事務提交的時候將和這個事務相關的REDO LOG 數據，包括COMMIT 記錄，都必須從LOG BUFFER 中寫入REDO LOG 文件，此時事務提交成功的信號才能發(fā)送給用戶進程。這樣便可以確保當已經提交的事務中的部分BUFFER CACHE 還沒有被寫入數據文件時發(fā)生了實例故障，在重啟后做實例恢復的時候，也可以通過REDO LOG 的信息，將不一致的數據前滾。

如果某事務未提交，此時產生的REDO仍在LOG  BUFFER中，當數據庫突然CRASH,log buffer數據也丟失了，我們可以確認這部分數據是沒有提交的，將會被回滾，但是，redo信息沒有寫入磁盤，不存在了。也沒辦法通過redo 構造數據塊，怎么辦？

其實這里是理解錯了，未寫入redo_file,也未寫入db_file,那么發(fā)生數據庫失敗恢復時,數據庫將直接丟棄該DML操作,反正該操作尚未commit,丟掉了也沒關系，并且因為未寫入數據文件，沒必要進行構造UNDO回滾。 

二、UNDO有沒有寫緩存情況，如果有UNDO丟失怎么辦？

undo 有undo buffer ,從以上可以看出，redo 日志會記錄了事務的 redo 和undo信息。所以不用擔心

三、實例恢復過程主要使用的四個SCN：

Control file三個地方為：

1、System checkpoint SCN

select checkpoint_change# from v$database;

這里應該有完整檢查點的SCN，完整檢查點的SCN會更新數據文件及數據文件頭的SCN， 增量檢查點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運作下，last_change#一定是null

還有一個SCN在datafile header內

4、 Start SCN

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

到此，關于“ORACLE事務和實例的恢復過程講解”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
網站題目：ORACLE事務和實例的恢復過程講解
本文URL：http://weahome.cn/article/ipcidc.html