香蕉皮

<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 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‧