[Oracle]效能最佳化調整(三)–調整重做機制

 

      當我們最佳化ORACLE效能,檢查了Shared Pool和Buffer Cache命中率之後,意識到需要使這些結構的變得更大才能改進它們，但伺服器中沒有足夠的記憶體來支援這一改進。同時又發現Redo Log Buffer的Retry Ratio又很低，表明Redo Log Buffer可能被設定得太大，在我們沒有購買記憶體的情況下，調小Redo Log Buffer可能會是不錯的選擇哦! 不過調整之前一定要謹慎,需要經過效能和安全性之間的反覆權衡!    重做機制的原理大致是這樣的,User Server Process --> 設立資料庫檢查點(Database Checkpoint) --> 將使用者事務中所需要的資訊(使用DML/DDL語句)記錄下來 --> 複製到Redo Log Buffer中 --> 日誌寫入程式(LGWR)把Redo Log Buffer資訊寫到Online Redo Log上 --> 如果當前的Online Redo Log被全部寫完了，該Redo Log就變成offline狀態,切換另外一個Redo Log,並使其狀態online(所以我們可以知道每個資料庫必須至少有2個Redo Log檔案，注意Redo Log是物理檔案) --> Offline Redo Log的檔案通過Archive (ARCO)後台進程機制,把該日誌的內容複寫到存檔的重做日誌!    如果發現系統的瓶頸是在重做日誌機制的效能上面，我們就需要改進它的效能。1.測量Redo Log Buffer效能Redo Log Buffer Retry Ratio(重試率) 使用者Server Process因為訪問Redo Log Buffer而等候的機率，一般我們希望<1%select retries.VALUE / entries.VALUE "Redo Log Buffer Retry Ratio"from v$sysstat retries,v$sysstat entrieswhere retries.NAME='redo buffer allocation retries'and entries.NAME = 'redo entries'2.改進Redo Log Buffer效能(1)增大參數Log_Buffer(2)減少重做產生UNRECOVERABLE關鍵字NOLOGGING關鍵字例如：create table col_custasselect * from collect_custunrecoverable;3.調整檢查點(1)檢查點過多也會引起不必要的I/O操作select name,value from v$sysstat where name like '%background checkpoint%'結果如下：background checkpoints started                40background checkpoints completed         40當啟動點的數目和完成點的數目不一致(不包括目前正在執行的那個哦),就需要考慮調整一下(2)調整參數FAST_START_MTTR_TARGET --檢查點頻率預設是:04.調整聯機重做記錄檔注意兩點，(1)把重做記錄檔和資料庫檔案分開 (2)重做日誌放在快速裝置上，不要放在RAID卷上5.調整存檔操作略...(本人還不大清楚怎樣操作)