Oracle 架構分為實例與資料庫兩大核心層次。實例是記憶體結構與背景進程的集合；資料庫是作業系統層面的實體檔案集合。理解兩者關係與 SGA 內部元件運作，是效能調校與故障診斷的基石。
核心架構圖解
- Instance（實例） = SGA + Background Processes（DBWR, LGWR, SMON, PMON, CKPT, ARCH…）
- Database（資料庫） = Datafiles + Control Files + Redo Log Files + Parameter Files + Password File
- 一個實例同一時間只能掛載一個資料庫；RAC 環境下多實例共享同一資料庫。
系統全域區（SGA）核心元件
透過 SELECT * FROM v$sga; 可觀察 SGA 總大小與四大區塊：
- Fixed Size：內部結構指標，極小且固定。
- Variable Size：共用池、大池、Java 池、Streams 池等動態元件總和。
- Database Buffers：資料緩衝區，快取資料塊，通常佔 SGA 最大比例。
- Redo Buffers：重做日誌緩衝，順序寫入，後由 LGWR 刷入線上重做日誌檔。
共用池：效能關鍵的「心臟」
共用池包含兩大核心快取：
1. Library Cache（程式庫快取）
- 快取 SQL/PLSQL 解析樹、執行計畫、物件定義。
- 硬解析 vs 軟解析：首次執行需硬解析（語法/語意檢查、優化器生成計畫），後續命中 Library Cache 則為軟解析，跳過優化器，極大降低 CPU 與閂鎖爭用。
- 範例驗證：
ALTER SYSTEM FLUSH SHARED_POOL; 清空後首次查詢 0.08 秒，第二次 0.02 秒，第三次 0.00 秒 —— 差異即為硬解析成本。
- 關鍵指標：
V$SQLAREA.EXECUTIONS 高、PARSE_CALLS 低 = 高重用率；反之則需檢查是否使用繫結變數。
2. Data Dictionary Cache（資料字典快取）
- 快取表/索引/使用者/權限等中繼資料，供內部頻繁存取，減少對
SYSTEM 表空間的物理 I/O。
- 通常無需人工干預，但
SHARED_POOL_SIZE 過小時會被擠出，導致遞迴 SQL 暴增。
共用池調校黃金法則
- 使用繫結變數：
WHERE id = :b1 而非字面值，確保游標共用。
- 避免過大/過小：太小導致頻繁硬解析與 ORA-04031；太大浪費記憶體且增加閂鎖管理開銷。建議啟用
SGA_TARGET/MEMORY_TARGET 自動管理。
- 監控關鍵視圖：
V$SGASTAT（細項用量）、V$LIBRARYCACHE（命中率）、V$SQL_SHARED_CURSOR（不共用原因）。
- 保留區：對大型、低頻 PLSQL 物件使用
DBMS_SHARED_POOL.KEEP 或設定 SHARED_POOL_RESERVED_SIZE 防止被淘汰。
初學者實作建議
- 先掌握
V$SGA、V$SGASTAT、V$SQLAREA 三大視圖用法。
- 實驗
ALTER SYSTEM FLUSH SHARED_POOL 體驗硬/軟解析差異。
- 養成「所有 SQL 使用繫結變數」的編碼習慣，是預防共用池問題最有效的手段。
深入理解實例與資料庫的邊界、SGA 內部運作，能讓 DBA 從「調參數」進化到「調架構」，精準定位效能瓶頸，打造穩定高效的 Oracle 環境。
