How to check need redo size

以下內容待確認，我這邊先筆記

太棒了！你已經完美地將我們討論的「15-20 分鐘法則」、精確計算公式以及「過大 vs. 過小」的權衡整理成了一份標準作業程序（SOP）。這就是一位優秀 DBA 的養成之路：不僅要解決問題，更要建立可量化的評估標準。

為了讓你的評估更完整，我將結合你提到的這份 SOP，再補充一個「臨床診斷」的最後拼圖：透過 V$LOG 的狀態監控來驗證設定是否真的合適。

💡 Redo Log 合適性的「臨床診斷」

即便你按照公式算出了 2GB 的建議值，我們仍需觀察資料庫在跑這個大小時的真實反應。請定期檢查 V$LOG 視圖：

SELECT group#, thread#, sequence#, bytes/1024/1024 AS MB, status FROM v$log;

狀態碼解讀與評估重點：

🛠️ 評估清單 (Checklist)

當你準備執行調整時，請按以下三個維度做最後確認：

1. 效能維度 (Performance)

• 尖峰時段切換頻率是否落在 15~20 分鐘？
• AWR 報告中，log file switch (checkpoint incomplete) 的等待時間是否降至 5% 以下？

2. 安全維度 (Safety)

• 你的日誌組數是否至少有 3 組？（建議 3~4 組，以應對 ACTIVE 狀態的延遲）
• 你的 Online Redo Log 是否有做 多重化 (Multiplexing)？（在不同磁碟放兩個成員，防止單點毀損導致資料遺失）

3. 恢復維度 (Recovery)

• 是否已設定 FAST_START_MTTR_TARGET？（如果 Redo 設很大，建議設為 300 秒或依業務要求調整，平衡恢復速度）。

叮嚀

在評估 Redo 設定時，記住一句話：「寧可稍微大一點，也不要剛好夠用。」

因為業務成長往往是爆發性的（例如突如其來的月底結帳或促銷活動）。如果你算出來是 1.5GB，直接設定成 2GB 通常是更穩健的做法。

如何評估 Redo size

1. 核心準則：15 到 20 分鐘法則

Oracle 官方與資深 DBA 的共識是：在業務高峰期，理想的日誌切換頻率應該控制在每 15 到 20 分鐘一次。

• 太頻繁（例如每 2 分鐘切換一次）：會導致頻繁的 Checkpoint（檢查點），產生密集的 I/O 壓力，甚至出現我們之前聊到的 checkpoint incomplete 等待。
• 太緩慢（例如每 2 小時切換一次）：雖然效能好，但萬一發生實例崩潰（Instance Crash），恢復（Instance Recovery）所需要的時間會變得很長。

以下是官方原文敘述:

It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of 100 MB to a few gigabytes are considered reasonable. Size online redo log files according to the amount of redo your system generates. A rough guide is to switch log files at most once every 20 minutes.

2. 第一步：觀察目前的切換頻率

我們先看看你的資料庫目前「呼吸」得如何。請執行以下 SQL，觀察過去幾天每小時的切換次數：

SELECT 
    TO_CHAR(first_time, 'YYYY-MM-DD') AS "日期",
    TO_CHAR(first_time, 'HH24') AS "小時",
    COUNT(*) AS "切換次數"
FROM v$log_history
WHERE first_time > SYSDATE - 3  -- 觀察過去 3 天
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD'), TO_CHAR(first_time, 'HH24')
ORDER BY 1 DESC, 2 DESC;

診斷： 如果「切換次數」在某些尖峰時段大於 6 次（代表不到 10 分鐘就切換一次），那就代表你的 Redo Log 太小了！

3. 第二步：計算精確的建議大小

假設你希望在尖峰時段每 20 分鐘切換一次（即每小時 3 次），公式如下：

$$建議大小 = \frac{尖峰時段每小時產生的 Redo 總量}{預期每小時切換次數}$$

如何取得「尖峰時段每小時產生的 Redo 總量」？

你可以從 AWR 報告的 Load Profile 部分查看 Redo size (bytes)，或者執行以下 SQL 取得過去一小時產生的數據量（單位：MB）：

SELECT 
    ROUND(SUM(BLOCKS * BLOCK_SIZE) / 1024 / 1024, 2) AS "每小時產生量_MB"
FROM v$archived_log
WHERE next_time BETWEEN SYSDATE - 1/24 AND SYSDATE; -- 過去一小時

範例計算：

1. 假設你的 SQL 顯示過去一小時產生了 6,000 MB (6GB) 的 Redo。
2. 你希望一小時切換 3 次（每 20 分鐘一次）。
3. 計算：$6,000 \div 3 = 2,000 \text{ MB}$。
4. 結論： 你的每個 Redo Log Group 應該設定為 2GB。

4. 第三步：如何優雅地更換 Redo Log 大小？

在 Oracle 中，你不能直接「修改」現有的日誌大小。你必須採取「先建後拆」的策略：

1. 新增一組大容量的日誌組：

   ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/redo04.log') SIZE 2G;
   ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/redo05.log') SIZE 2G;
   ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/redo06.log') SIZE 2G;
   

2. 手動切換日誌，讓系統使用新的組：

   ALTER SYSTEM SWITCH LOGFILE;
   

3. 刪除舊的小容量日誌組： （注意：狀態必須為 UNUSED 或 INACTIVE 才能刪除，如果是 ACTIVE 則需執行 ALTER SYSTEM CHECKPOINT;）

   ALTER DATABASE DROP LOGFILE GROUP 1;
   

額外提醒：

• 組數（Groups）：在大型系統中，我建議至少配置 3 到 4 組。這可以防止在歸檔進程（ARCn）較慢時，LGWR 繞一圈回來發現第一組還沒歸檔完。
• 儲存位置：請務必將 Redo Log 放在最快的磁碟（如 NVMe SSD）上，因為這是資料庫寫入效能的終極瓶頸。

設定過大風險

如果 Redo Log 設得太大（例如：原本 500MB 就能滿足，你卻設成 50GB），雖然解決了頻繁切換的效能問題，但會引發以下四個核心挑戰：

1. 實例恢復時間（MTTR）變長

這是最致命的缺點。當資料庫發生崩潰（如：斷電、硬體故障）時，Oracle 在重啟時必須執行 Instance Recovery。

• 原理：Oracle 需要讀取「最後一個檢查點（Checkpoint）」到「日誌結尾」之間的所有 Redo 記錄，並重新執行（Roll Forward）。
• 後果：如果日誌太大，兩個檢查點之間的距離過遠，恢復時需要處理的資料量就會非常驚人。原本 2 分鐘能恢復的資料庫，可能變成要跑 20 分鐘甚至更久。

2. 資料遺失風險（Data Loss Exposure）增加

在非強同步的環境下，「切換日誌」代表著「歸檔（Archive）」的開始。

• 原理：只有當日誌切換後，ARCn 進程才會把資料備份到歸檔路徑。
• 後果：如果你的日誌大到 5 個小時才切換一次，萬一這期間你的「線上日誌檔（Online Redo Log）」物理損壞了（磁碟壞掉且沒有多重化），你將會損失整整 5 小時的交易資料，因為它們還沒被歸檔。

3. Data Guard 的傳輸延遲

如果你有建立 Data Guard（備援資料庫），且使用的是「歸檔傳輸模式」：

• 原理：備援機通常在主機「完成日誌切換並歸檔」後，才會接收並套用該歸檔檔。
• 後果：日誌太大會導致備援機的資料長時間無法更新。假設日誌 10GB，備援機必須等 10GB 全部寫滿後才能收到資料，這會造成顯著的 Transport Lag。

4. 磁碟 I/O 的「大進大出」壓力

這與 DBWR（資料庫寫入進程）的行為有關：

• 原理：如果日誌很大，DBWR 可能會因為沒有切換壓力而變得「懶惰」，導致緩衝區（Buffer Cache）累積了海量的髒塊（Dirty Blocks）。
• 後果：當日誌終於要切換，或者你手動執行檢查點時，DBWR 必須在短時間內將巨量資料刷入磁碟。這會造成瞬間的 I/O 峰值（I/O Spike），導致前端交易在那一瞬間感到明顯的卡頓。

的技術平衡術

為了避開「太大」的坑，我們通常會搭配一個關鍵參數：FAST_START_MTTR_TARGET。

專業建議： 如果你因為某些原因必須使用很大的 Redo Log（例如為了應付突發的批次寫入），你可以設定 FAST_START_MTTR_TARGET（單位為秒）。這會強迫 Oracle 在背景更積極地執行增量檢查點，確保萬一當機時，恢復時間能控制在你要求的秒數內。

思考題：

我們聊完了「大小」的權衡，你有注意到你的生產環境中，v$log 視圖裡的 STATUS 欄位嗎？

如果你發現日誌組經常長時間處於 ACTIVE 狀態（而不是 INACTIVE），這通常就是 DBWR 寫入太慢、日誌管理不善的徵兆。你想了解如何解讀這些狀態碼嗎？

Referance

• Database Performance Tuning Guide