承接上篇，本文具體列舉 Shared-Nothing (不共享) 架構四大根本缺點，並詳細闡述 Oracle Shared-Everything (共享一切) 動態並行如何在**執行時**構造最優資料子集、彈性並行度、跨節點負載均衡，實現超越靜態分區的擴展性與可用性。
Shared-Nothing 四大根本缺點
- 不適配 SMP 硬體：SMP 所有 CPU 等價存取所有記憶體，強行物理分區屬人為限制，浪費硬體能力。
- 資源利用率異常：
- 查詢僅需部分分區 → 其他節點閒置無法協助。
- 大表未分區 → 無法並行，退化為單節點串行。
- 業務適應性僵化：
- 擴容需重新分區 (Re-partition) → 停機、資料搬移、風險高。
- 升級所有節點成本極高；新增節點必須重組。
- 容錯能力受限：節點 = 單一存取點 = 單一故障點。叢集提供的冗余 (多路徑、多網卡) 無法被充分利用，因資料擁有權固定綁定節點。
Oracle Shared-Everything 動態並行核心機制
1. 執行時動態構造最優資料子集
- 每個 SQL 解析時，優化器依**當前統計資訊、查詢條件、可用資源**決定：
- 並行度 (DOP)、資料分佈方法 (Hash/Range/Random)、PX Server 分配節點。
- **不受建表時的物理分區限制**，每條查詢擁有專屬的最優並行計畫。
2. 彈性並行度與節點參與
- 無「最小並行度」強制喚醒所有節點。
- 依**工作負載、查詢重要性、資源管理器計畫**動態決定：1 個、部分、或所有 RAC 節點參與。
- 重要查詢 (CEO 報表) 可獲更多 PX Servers；批次報表自動降級。
3. PX Server 池化與工作分配
- 實例啟動建立 **Parallel Execution Server Pool** (參數
PARALLEL_MIN_SERVERS / MAX_SERVERS)。
- QC 向池請求 PX Servers，用完歸還，**跨查詢複用進程**，避免頻繁建立/銷毀開銷。
- 每個 PX Server 獨立處理 **Granule (區塊範圍/分區)**，僅在資料重分佈時透過 **PX SEND/RECEIVE** 交換資料。
4. 超越 Shared-Nothing 的擴展性
- 共享一切架構下，**每個查詢可構造最優資料子集**，而非被迫遵循固定物理分區。
- 大多數情況下擴展性 **等同或優於** 純不共享架構。
- 後續步驟可在單一 PX Server 內合併處理，**減少資料/功能傳送**，進一步降低開銷。
關鍵參數速查
| 參數 | 用途 | 建議 |
|---|
| PARALLEL_MAX_SERVERS | 全實例最大 PX Server 數 | CPU 核心數 x 2 ~ 4 |
| PARALLEL_MIN_SERVERS | 池中預熱最小數 | 0 或少量，避免佔用記憶體 |
| PARALLEL_DEGREE_POLICY | AUTO / MANUAL / LIMITED | AUTO (11g+) 自動決定 DOP |
| PARALLEL_MIN_TIME_THRESHOLD | 自動並行門檻 (秒) | 10~30，避免小查詢並行開銷 |
| RESOURCE_MANAGER_PLAN | 資源管理器計畫 | 配合並行語句優先級控制 |
總結：為何 Oracle 選擇動態並行
**靜態分區將「資料佈局」綁定「硬體拓撲」，犧牲彈性換取簡單。**
**動態並行將「並行決策」延遲到「執行時」，保留最大彈性，適應多變負載與硬體演進。**
這是 Oracle 從 9i 確立至今的架構智慧，也是現代雲原生資料庫 (如 Autonomous DB、Snowflake、BigQuery) 繼承的核心設計哲學。
