重作日誌中如何分析日誌容量及切換頻率？

導讀	在Oracle數據庫的世界裏，Redo Log是一個很是核心的存在，經過Redo日誌，Oracle實現了數據變動的延遲寫出，經過日誌的順序寫推延了數據塊離散寫的性能影響，從而實現了高效率運做。

Redo Log首先在Buffer中生成，而後寫出到磁盤上的Redo Log File – 重作日誌文件，那麼如何配置日誌文件就成爲數據庫優化和健康巡檢的重要內容之一。若是日誌文件太小，就會出現重作日誌頻繁切換，檢查點不能及時完成等問題，影響到數據庫的正常運行。

最多見的，若是在告警日誌中看到 Checkpoint not complete 的提示，就意味着存在日誌切換重用時的阻塞。若是頻繁出現，那麼就必須採起主動的優化措施，如加大日誌文件大小、增長日誌組等。

在白求恩 – Bethune 智能巡檢平臺上，咱們專門設定了於此有關的檢查分析項目，幫助用戶及時簡單的剖析在日誌設置上可能存在的問題。

在【數據庫空間資源 – 重作日誌】分析項，能夠找到和Redo相關的分析項：

若是在日誌設置上存在問題，Bethune會給出分析提示，如如下數據庫的日誌組大小不一致，三組日誌大小是50M，另外兩組日誌大小是100M，這是不規範的配置，可能來自於某次臨時的日誌組增長，事實上須要DBA進行審視和整改：

對於日誌切換頻率，Bethune 給出了詳細的趨勢分析，多日數據的趨勢做爲對比展示，能夠清晰的幫助咱們看到系統的日誌變化和波動點：

將鼠標移動到峯值處，咱們能夠看到在每日的21：00，是數據庫幾種的日誌產生高峯，在該時段可能存在批處理做業：

經過點選具體的日期，咱們能夠在趨勢圖保留兩個日期，分析其業務變化在日誌生成上的改變，如圖的兩個日期，日誌切換的波動很是吻合，這說明這個業務系統的運行是很是規律的：

固然，若是伴隨着日誌切換，數據庫告警日誌中出現了『檢查點未完成』等待，在分析提示中會以性能標籤提示出來，在這種狀況下，咱們一般須要進行日誌配置的調整以消除這類問題：

以上這段提示給出了很是具體的建議：
在當前實例告警日誌中發現了 46 次檢查點未完成的提示（檢查點未完成致使聯機日誌沒法切換，會引發數據庫上一切活動會話的等待，形成業務中斷）。其中在 15 點檢查點未完成次數最多，共發現了 46 次檢查點未完成。檢查點未完成時段內，一小時日誌切換次數峯值爲 50 次，平均每隔 1.2 分鐘切換一次。爲了不日誌沒法切換致使業務中斷，建議再添加 2 組聯機日誌。
Bethune 的日誌分析，一個頁面幫你瞭解日誌組的配置和切換頻度，以及數據庫的相應性能表徵，Oracle數據庫無微不至的智能診斷，從白求恩開始！

原文來自：https://www.linuxprobe.com/redo-log.html