<Instance Failure>
instance失敗就是非正常地關閉instance,通常就是指當機‧這可能是由停電、突然關掉等等原因所造成‧instance失敗的影響,
在功能上,與提出SHUTDOWN ABORT命令一樣‧你或許聽過有人說「把資料庫當掉」,其實他們是指SHUTDOWN ABORT命令‧       
                                                                                                                 
在instance失敗後,資料庫或許遺失了已提交(committed)的交易儲存至磁碟,但卻將未提交(uncommitted)的交易儲存至磁碟‧這
是已毀損之資料庫的定義‧ 此狀況是因為Oracle更新的是資料庫緩衝快取(database buffer cache)中的資料區塊(Data Block)和
復舊區段(Undo Segment)的資料區塊(Data Block),並不是磁碟上的Data Block,請記住‧                                 
                                                                                                                 
DBWn 會把被改變區塊(被稱為Dirty Block)寫到資料檔(Data File)‧DBWn會以效能為導向的演算法,去選擇將被改變區塊(被稱為
Dirty Block)寫入至磁碟‧所以會造成最少在作用中的區塊(Data Block)會先被寫入,畢竟,要寫入每秒都在持有改變的區塊,意
義比較不大‧但這意謂著,有可能已提交(committed)的交易可能還沒有寫入資料檔(Data File),而未被提交(uncommitted) 的交
易已被寫入‧                                                                                                     
 
<Instance Recovery>
如果資料庫發生Instance Failue造成資料毀壞,重新啟動Oracle後,Oracle會偵測到此事實,並自動強制執行Instance Recovery
‧Oracle會從Online Redo Log File內找出最近的Checkpoint點,逐一開始進行Rolling Forward(Redo),此時Redo Record內都會
記錄修改後的值和修改前的復舊值(Undo Data),要記住Redo Log內的新值和復舊值(Undo Data)記錄的單位都是Block‧        
                                                                                                                 
另外Redo Record也會記錄Transactions Data,所以當 Oracle做完Rolling Forward時,此時Undo Segment會有當機前完整的交易
情況,Oracle可以明確得知那些Transactions是committed和uncommitted‧                                               
範例: //Creates a 5.2 change to update transaction table in undo segment header                                  
         (1)CHANGE #1 TYP:0 CLS:25 AFN:3 DBA:0x00c0012e SCN:0x0000.0ac86eb8 SEQ:1 OP:5.2 ktudh redo: slt: 0x0010    
              sqn: 0x0000475a flg: 0x0012 siz: 96 fbi: 0 uba: 0x00c04d20.234b.0e pxid: 0x0000.000.00000000             
                                                                                                                  
         //A 5.4 change is created for a commit                                                                     
         (2)CHANGE #1 TYP:0 CLS:25 AFN:3 DBA:0x00c0012e SCN:0x0000.0ac86ebf SEQ:1 OP:5.4 ktucm redo: slt: 0x0010    
              sqn: 0x0000475a srt: 0 sta: 9 flg: 0x0                                                                  
                                                                                                                 
當Oracle做完Rolling Forward時,現行的Database Buffer Cache已回復成當機前的狀態‧Oracle將會立即開放給使用者登入‧但
是此時會有二種情況需要特別注意:                                                                                  
(1)上次當機前,已COMMIT但資料(新值和復舊值Undo Data)尚未寫入至 Data File,此情況Oracle會以相關機制和演算法,DBWn將
   選適當時間寫入至Disk中的Data File‧                                                                           
(2)上次當機前,未COMMIT的交易,但已經寫入Data File,由於Oracle之前已經先做Rolling Forward(Redo),相關 Undo Segment
   將有當機前完整的Transaction Data、Undo Data,開始針對那些未COMMIT的交易做Rolling Backup(Undo)‧由於Oracle在做完
   Rolling Forward就會立即開放資料庫讓使用者登入使用,此時如果有使用者查詢的資料剛好是當機前未COMMIT的交易,Oracle
   會將查詢導至Undo Segment‧                                                                                    
創作者介紹

香蕉皮

香 香蕉皮 發表在 痞客邦 PIXNET 留言(0) 人氣()