實戰案例：cursor: pin S 等待事件導致 DG 備機效能暴跌

實戰案例：cursor: pin S 等待事件導致 DG 備機效能暴跌

場景背景

• 主庫：RAC 兩節點，各 8 vCPU / 16 GB 記憶體。
• DG 備機：單節點，8 vCPU / 16 GB 記憶體（僅相當於主庫單節點規格）。
• 觸發事件：主庫存儲微碼升級，執行 SWITCHOVER 切換至 DG 備機承擔業務一天。

故障現象

備機運行期間，v$session 大量出現 cursor: pin S 等待事件，前端業務回應極慢。此等待通常因軟解析過度、共享池競爭或熱門 SQL 並發執行引起。

根因分析

1. 硬體資源不對等：備機規格僅為主庫單節點，無法承接雙節點合併負載。
2. 並發壓力暴增：業務流量全湧入單節點，Cursor 競爭劇烈。
3. 軟解析風暴：大量相似 SQL 缺乏綁定變數，導致 Library Cache 鎖競爭。

解決與教訓

SWITCHOVER 切回 RAC 後，效能即時恢復。核心建議：容災端規格必須 ≥ 主庫所有節點規格之和，否則切換即是災難。同時優化 SQL 使用綁定變數、調整共享池大小、啟用 Cursor Sharing 可緩解類似問題。