我們都知道Oracle數據庫的處理作為數據庫中相對比較核心的技術，它會使組織以高效的管理，訪問TB級的相關比較實用的數據。如果你不能提供比較高效的Oracle數據庫並行處理技術，這些大型數據庫(通常用於數據倉庫但也越來越多地出現在業務系統中)將不會存在。
簡而言之，並行處理就是利用多個CPU和I/O資源來執行單個數據庫操作。盡管現在每個主要的數據庫供應商都聲稱可以提供並行處理能力，但每個供應商所提供的體系結構其實存在關鍵的差異。
本文討論Oracle 9i並行處理的體系結構，並說明於在實際應用中其相對於其它體系結構的優越性。需要著重指出的是，Oracle9i並行處理體系結構的主要優點在於它能在任何情況下完全利用底層硬件基礎架構——每個處理器單元、每個內存字節以及所有可用的I/O帶寬。本白皮書還講述Oracle 並行處理組件與其它關鍵業務組件(例如：Oracle RealApplication Cluster)的無縫集成。
Oracle數據庫並行處理技術簡介
現在的數據庫，無論是用於數據倉庫、操作數據存儲(ODS)或OLTP 系統，都包含豐富的信息。然而，由於其中涉及海量數據，及時查找和展示信息是一個巨大的挑戰。Oracle數據庫並行處理技術能夠解決這一挑戰。使用Oracle數據庫並行處理技術，數分種內(而非數小時或數天)就可以處理數TB級的數據。
Oracle數據庫並行處理技術通過利用所有可用的硬件資源取得這樣的高性能：多個CPU、多個I/O通道、多個存儲陣列和磁盤驅動器，以及大量的內存。數據庫軟件越能有效地利用所有這些資源，處理查詢和其它數據庫操作就越有效。
此外，現在的數據庫應用的復雜性大大都增強了，不僅需要支持大量並發用戶，而且需要管理不同類型的用戶。因此，一個並行查詢體系結構不僅應該確保底層硬件平台的所有資源都得到充分利用，而且應該更進一步，將這些資源適當地分配給多個並發請求。
很顯然，支持CEO的戰略決策的請求比執行批處理報表更加重要，並行查詢體系結構應該能夠處理這些商務要求：不僅基於請求自身，而且應該基於發出請求的人以及當前可用的系統資源的數量來做出動態的分配。
Oracle9i 的並行處理體系結構能夠全面滿足這些要求，Oracle9i的體系結構不僅提供業界領先的高性能，而且是唯一可以自適應和動態調整的。
Oracle9i 的並行處理體系結構充分利用每種硬件投資――SMP、群集或MPP的優勢——在任何時間保證最佳的吞吐量和連續的、優化的系統使用量。
Oracle9i 數據庫根據可用資源、請求優先級和實際系統負載控制來平衡所有並行操作。
Oracle數據庫並行處理技術並行化設計策略——靜態與動態
並行處理的思想就是將單個任務分解為多個更小的單元。不是通過一個進程完成所有工作，而是將任務並行化而使多個進程同時在更小的單元上運行。這可以極大地提高性能和最佳地利用系統。然而，並行處理的最關鍵部分是如何作出將單個任務分成更小的工作單元的正確決策。
典型地，有兩種方法用於實現數據庫系統的並行處理。主要區別在於是否需要進行物理數據布局，將靜態的數據分區作為並行處理的前提。
Oracle數據庫並行處理技術之通過物理數據分區的靜態並行——不共享
在純不共享數據庫體系結構中必須將數據庫文件在多計算機系統的節點上進行分區才能進行並行處理。每個節點擁有一個數據子集，擁有節點使用單一進程或線程，以獨占方式執行對此數據子集的所有訪問。數據訪問不能在分區內並行。(有時，也用術語“虛擬處理器”來代替節點。“虛擬處理器”是在SMP計算機上模擬不共享節點的一種機制。
為了簡單，在討論不共享體系結構時，我們將統一使用“節點”作為術語)。換句話說，純不共享系統使用分區或受限訪問方法在多個處理節點間劃分工作。節點對數據所有權的改變相對少見——為了適應業務需求的改變而進行的數據庫重組、添加或刪除節點以及節點故障是所有權更改的典型原因。這種數據所有權的改變對純不共享系統而言總是意味著要進行人工管理。
從概念上看，可以認為純不共享系統與分布式數據庫非常相似。為了在某個節點上執行要求的讀/寫操作，該節點上的事務必須將消息發送給擁有需要被訪問的數據的其它節點，並協調在其它節點上完成的工作。將消息傳遞給其它節點，在它們擁有的數據集上請求執行特定操作(功能)稱為功能傳送。
另一方面，如果從遠程節點請求簡單數據，則必須訪問完整的數據集並將它從擁有節點返回至請求節點(數據傳送)。
