當我們優化
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 entries
where retries.name='redo buffer allocation retries'
and entries.name = 'redo entries' 2.
改進redo log buffer效能
(1)增大引數
log_buffer
(2)
減少重做生成
unrecoverable
關鍵字
nologging
關鍵字
例如：
create table col_cust as
select * from collect_cust
unrecoverable; 3.
調整檢查點
(1)
檢查點過多也會引起不必要的
i/o操作
select name,value from v$sysstat where name like '%background checkpoint%'
結果如下：
background checkpoints started 40
background checkpoints completed 40
當啟動點的數目和完成點的數目不一致
(不包括目前正在執行的那個哦
),就需要考慮調整一下
(2)
調整引數
fast_start_mttr_target --
檢查點頻率
預設是:0 4.
調整聯機重做日誌檔案
注意兩點，
(1)把重做日誌檔案和資料庫檔案分開
(2)重做日誌放在快速裝置上，不要放在
raid卷上
5.調整存檔操作 略
...(
本人還不大清楚怎樣操作)
Oracle效能優化調整 調整緩衝區快取記憶體
一 我們可以通過配置 shared pool 保證使用者在記憶體中查詢到已經快取的語句 改進效能 還有乙個重要的方法就是 使使用者可以在記憶體找到他們所請求的資料 這就需要通過 database buffer cache 資料庫緩衝區的快取記憶體區 來實現。buffer cache 是sga 的乙個...
JBOSS AS 效能調整優化
1 減少日誌的輸出量 jboss 4.2.3.ga server default conf jboss log4j.xml 根據不同的日誌級別 一共有5個等級，越往下輸出的東西越詳細。一般沒什麼特殊情況，調整為warn或者info即可 fatal 0 error 3 warn 4 info 6 de...
Tomcat效能調整優化
一 引言 效能測試與分析是軟體開發過程中介於架構和調整的乙個廣泛並比較不容易理解的領域，更是一項較為複雜的活動。就像下棋遊戲一樣，有效的效能測試和分析只能在乙個良好的計畫策略和具備了對不可預料事件的處理能力的條件下順利地完成。乙個下棋高手贏得比賽靠的不僅僅是對遊戲規則的認識，更是靠他的自己的能力和不...