簡而言之，並行處理就是利用多個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計算機上模擬不共享節點的一種機制。為了簡單，在討論不共享體系結構時，我們將統一使用“節點”作為術語)。換句話說，純不共享系統使用分區或受限訪問方法在多個處理節點間劃分工作。節點對數據所有權的改變相對少見——為了適應業務需求的改變而進行的數據庫重組、添加或刪除節點以及節點故障是所有權更改的典型原因。這種數據所有權的改變對純不共享系統而言總是意味著要進行人工管理。
從概念上看，可以認為純不共享系統與分布式數據庫非常相似。為了在某個節點上執行要求的讀/寫操作，該節點上的事務必須將消息發送給擁有需要被訪問的數據的其它節點，並協調在其它節點上完成的工作。將消息傳遞給其它節點，在它們擁有的數據集上請求執行特定操作(功能)稱為功能傳送。另一方面，如果從遠程節點請求簡單數據，則必須訪問完整的數據集並將它從擁有節點返回至請求節點(數據傳送)。 在不共享體系結構下的並行處理像分布式數據庫一樣運作。每個節點以獨占方式擁有其數據分區。沒有其它任何節點可以訪問此數據，而使節點成為單一的訪問點和故障點
此方法具有一些基本缺點，無法解決今天高端環境對可伸縮性和高可用性要求:
(1)、首先，不共享方法在用於共享一切的SMP硬件時並不是最佳的。為了獲得並行處理的益處而要求對數據進行物理分區，在共享一切的SMP系統中很明顯是一種人工的、過時的要求。因為在SMP系統中每個處理器都可以對所有數據進行直接的、等同的訪問。
(2)、其次，在不共享方法中使用嚴格的基於分區的並行處理策略，通常會導致不正常的資源利用。例如以下兩種情況：在沒有必要訪問表的所有分區時;或當單一節點所擁有的更大的未分區表是操作的一部分時。在這些情況下，限制分區內並行處理的緊密所有權模式，無法利用所有可用的處理能力，因而不能提供最佳的處理能力使用方案。
(3)、第三，由於具有對節點對應物理數據分區的關系，不共享系統在適應變化的業務需求方面一點都不靈活。當業務增長時，無法方便地以增量方式擴充系統來適應增長的業務需求。可以升級所有現有的節點，保持它們對稱並避免數據重新分區。在大多數情形下，升級所有節點費用太高;必須添加新節點並重組(進行物理重新分區)現有數據庫。一個不需要進行任何重組的方案總是比必須重組的方案要更好，即使可以利用到最復雜的重組工具。
(4)、最後，由於使用嚴格的受限制的訪問模式，不共享系統無法完全利用群集系統為保證系統高可靠性所提供的潛在的容錯能力。
毫無疑問，基於使用靜態數據分布的不共享體系結構，大量的並行處理可以在實驗室條件下並行化和擴展。然而，在每個現實環境中，必須正確地解決上面談到的問題才能滿足今天高端關鍵任務要求。
Oracle數據庫並行處理技術之執行時的動態並行——共享一切
使用Oracle 的動態並行處理框架，可以共享所有數據。並行化和將工作分成更小的單元的決策，並不受限於數據庫設置(創建)時所做的任何預先確定的靜態數據分布。
由於能夠為每個語句構造不受限制的、優化的數據子集，執行時動態並行可以提供與不共享體系結構等同的或甚至更好的可伸縮性。
每個查詢在訪問、連接和處理數據的不同部分時都有它自己的特征。因此，每個SQL語句在被解析時都要進行優化和並行化處理。數據更改時，如果有更加優化的並行執行計劃可用，或者系統中新添加了一個節點，那麼Oracle可以自動適應新的情況。這樣可為並行化任何種類的操作提供最高程度的靈活性：
(1)、在語句執行前，對於每個查詢要求，會動態地優化並行訪問的物理數據子集。
(2)、對於每個查詢，都會優化其並行度。與不共享環境不同，不存在必需的最小並行度來調用所有節點訪問所有數據，這是訪問所有數據的基礎要求。
(3)、操作可以根據當前工作負載、特征和查詢的重要性，使用一個、一些或全部Real Application Cluster 節點並行運行。
只要語句得到優化和並行化，就可以知道所有後續的並行子任務。原始進程變為查詢協調器;並行處理服務器(PX 服務器)從一個或多個節點上的並行處理服務器的公用緩沖池得到分配，並開始並行執行該操作。
與不共享體系結構相似，共享一切體系結構中的每個並行處理服務器在其個人數據子集上獨立工作。數據或功能在並行進程之間的傳送機制也與上述的不共享體系結構相似或者相同。確定請求的並行計劃之後，每個並行處理服務器都知道其數據集和任務，而進程間通信就像在不共享環境中一樣很少。
然而，與不共享體系結構不同，每個並行處理的SQL 語句不需要考慮任何物理數據庫布局限制就可以進行優化。這使得每個並行處理可以構造最佳的數據子集，從而提供與純不共享體系結構相比同等的，甚至在大多數情形下更好的可伸縮性和性能。只要有益，並行操作的後續步驟就會由一個並行處理服務器進行組合和處理，從而減少數據傳送或功能傳送的需求。
Oracle數據庫並行處理技術之為什麼共享一切比不共享更好?
不共享體系結構可以追溯到將海量並行處理(MPP)系統看作唯一能提供可伸縮的高端並行計算的硬件體系結構。MPP系統中的每個節點都有它自己的系統組件(CPU、內存和磁盤)，在不同的子任務上工作，並且不能共享其任何資源。
這一切都已過去。現在，大多數成功的、廣泛使用的並行硬件系統都是對稱多處理器系統(SMP)， 要麼是單機的，要麼是作為松耦合的群集。SMP系統利用共享公用內存和磁盤資源的多處理器，因而也被稱為“共享一切”系統。
純不共享體系結構的支持者總是聲稱共享一切體系結構(特別是群集環境)對於高端環境會缺乏可伸縮性並引起顯著的開銷，因而這種體系結構不能用於具有高度並行和/或並發性的高端應用。這種說法是錯誤的。今天的硬件和軟件技術已經解決了過去所有的問題，如高速群集互連或Oracle Real Application Clusters 的高速緩存融合體系結構。
Oracle 的動態並行處理框架建立在與不共享軟件相同的並行高級計算基礎設計之上，具有所有的優點，還增強了其功能並克服了不共享方法在體系結構上的缺點。基於不共享原理的軟件可以看作是第一代、但已經過時的數據庫並行處理軟件。
Oracle數據庫並行處理技術的相關內容就向你介紹到這裡，希望對你了解和學習Oracle數據庫並行處理技術有所幫助。
