《重做日志：分析日志容量及切換頻率》要點(diǎn)：
本文介紹了重做日志：分析日志容量及切換頻率，希望對您有用。如果有疑問，可以聯(lián)系我們。

在Oracle數(shù)據(jù)庫的世界里,Redo Log是一個(gè)非常核心的存在,通過Redo日志,Oracle實(shí)現(xiàn)了數(shù)據(jù)變更的延遲寫出,通過日志的順序?qū)懲蒲恿藬?shù)據(jù)塊離散寫的性能影響,從而實(shí)現(xiàn)了高效率運(yùn)作.

Redo Log首先在Buffer中生成,然后寫出到磁盤上的Redo Log File – 重做日志文件,那么如何配置日志文件就成為數(shù)據(jù)庫優(yōu)化和健康巡檢的重要內(nèi)容之一.如果日志文件過小,就會出現(xiàn)重做日志頻繁切換,檢查點(diǎn)不能及時(shí)完成等問題,影響到數(shù)據(jù)庫的正常運(yùn)行.

最常見的,如果在告警日志中看到?Checkpoint not complete 的提示,就意味著存在日志切換重用時(shí)的阻塞.如果頻繁出現(xiàn),那么就必須采取主動(dòng)的優(yōu)化措施,如加大日志文件大小、增加日志組等.

在?白求恩 – Bethune 智能巡檢平臺 上,我們專門設(shè)定了于此有關(guān)的檢查分析項(xiàng)目,幫助用戶及時(shí)簡單的剖析在日志設(shè)置上可能存在的問題.

在【數(shù)據(jù)庫空間資源 – 重做日志】分析項(xiàng),可以找到和Redo相關(guān)的分析項(xiàng)：

如果在日志設(shè)置上存在問題,Bethune會給出分析提示,如以下數(shù)據(jù)庫的日志組大小不一致,三組日志大小是50M,另外兩組日志大小是100M,這是不規(guī)范的配置,可能來自于某次臨時(shí)的日志組增加,事實(shí)上需要DBA進(jìn)行審視和整改：

對于日志切換頻率,Bethune 給出了詳細(xì)的趨勢分析,多日數(shù)據(jù)的趨勢作為對比展現(xiàn),可以清晰的幫助我們看到系統(tǒng)的日志變化和波動(dòng)點(diǎn)：

將鼠標(biāo)移動(dòng)到峰值處,我們可以看到在每日的21：00,是數(shù)據(jù)庫幾種的日志產(chǎn)生高峰,在該時(shí)段可能存在批處理作業(yè)：

通過點(diǎn)選具體的日期,我們可以在趨勢圖保留兩個(gè)日期,分析其業(yè)務(wù)變化在日志生成上的改變,如圖的兩個(gè)日期,日志切換的波動(dòng)非常吻合,這說明這個(gè)業(yè)務(wù)系統(tǒng)的運(yùn)行是非常規(guī)律的：

當(dāng)然,如果伴隨著日志切換,數(shù)據(jù)庫告警日志中出現(xiàn)了『檢查點(diǎn)未完成』等待,在分析提示中會以性能標(biāo)簽提示出來,在這種情況下,我們通常需要進(jìn)行日志配置的調(diào)整以消除這類問題：

以上這段提示給出了非常具體的建議：

在當(dāng)前實(shí)例告警日志中發(fā)現(xiàn)了 46 次檢查點(diǎn)未完成的提示(檢查點(diǎn)未完成導(dǎo)致聯(lián)機(jī)日志無法切換,會引起數(shù)據(jù)庫上一切活動(dòng)會話的等待,造成業(yè)務(wù)中斷).其中在 15 點(diǎn)檢查點(diǎn)未完成次數(shù)最多,共發(fā)現(xiàn)了 46 次檢查點(diǎn)未完成.檢查點(diǎn)未完成時(shí)段內(nèi),一小時(shí)日志切換次數(shù)峰值為 50 次,平均每隔 1.2 分鐘切換一次.為了避免日志無法切換導(dǎo)致業(yè)務(wù)中斷,建議再添加 2 組聯(lián)機(jī)日志.

Bethune 的日志分析,一個(gè)頁面幫你了解日志組的配置和切換頻度,以及數(shù)據(jù)庫的相應(yīng)性能表征,Oracle數(shù)據(jù)庫無微不至的智能診斷,從白求恩開始!

Bethune官網(wǎng)：bethune.enmotech.com

文章來自微信公眾號：數(shù)據(jù)和云

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4087.html