在各種事件後的平均復原時間(Mean-Time-To-Recover:MTTR),Instance Recovery 復原會保證資料庫無毀損,但在資料庫能開啟
之前所必需作的Rolling Backup(Redo),可能會花可觀的時間‧這個時間取決於二個因素:有多少Redo已被讀取,以及在應用Redo
時,Data File上會需要多少讀/寫動作‧這二個因素都可以由Checkpoint空制‧                                           
                                                                                                                 
Checkpoint會保證在特定時點,所有接近特定SCN的資料改變,都會由DBWn寫到Data File‧在instance當機的事件中,只有SMON必
須重作(Rolling Forward)從上一個儲存點位置產生的Redo Data‧ 無論是否有COMMIT,所有在那個位置之前作的改變都已在Data
File中,所以明顯地,沒有必要使用Redo Data來重新建構在那Checkpoint之前已COMMIT或未COMMIT的交易‧ 對於未COMMIT的交易
必需Rolling Backup的Undo Data,Undo Segment可以得到(最近一次Checkpoint後所有uncommitted的都將自Rolling Forward)‧
                                                                                                                 
Checkpoint位置所包含的資料愈新,Instance Recovery就愈快‧ 如果Checkpoint位置包含完整的最近資料,Oracle就不再需要去
做Rolling Forward,而instance可以立即開啟供使用者使用,而且並行做 Rolling Backup(Undo)‧但這要付出極大的代價‧如果
要提前Checkpoint位置,DBWn必須要把更動過的Data Block(又稱Dirty Block)寫入磁碟‧過量的磁碟I/O會嚴重削弱效能‧但另一
方面,如果你讓 DBWn落後太遠,會使得SMON在當機後,必須處理數百MB的Redo Data,並在Data File上進行數百萬次的讀/寫操作
,在Instance Failure後的MTTR會延長為數個小時‧                                                                   
                                                                                                                 
MTTR常會被建立在服務層級的協議中‧它可以由instance參數「fast_start_mttr_target」控制,設定的單位是秒‧通常,這個參
數設定的時間越短,在當機後要開啟資料庫就愈快,但線上效能會比較差‧                                               
範例: ALTER SYSTEM SET fast_start_mttr_target=60;                                                                
arrow
arrow
    全站熱搜

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