簡而言之，并行處理就是利用多個CPU和I/O資源來執(zhí)行單個數(shù)據(jù)庫操作。盡管現(xiàn)在每個主要的數(shù)據(jù)庫供應商都聲稱可以提供并行處理能力，但每個供應商所提供的體系結構其實存在關鍵的差異。

本文討論 9i并行處理的體系結構，并說明了在實際應用中其相對于其它體系結構的優(yōu)越性。需要著重指出的是，9i并行處理體系結構的主要優(yōu)點在于它能在任何情況下完全利用底層硬件基礎架構——每個處理器單元、每個內存字節(jié)以及所有可用的I/O帶寬。本白皮書還講述 并行處理組件與其它關鍵業(yè)務組件(例如：Oracle Application Cluster)的無縫集成。

簡介

現(xiàn)在的數(shù)據(jù)庫，無論是用于數(shù)據(jù)倉庫、操作數(shù)據(jù)存儲(ODS)或 系統(tǒng)，都包含豐富的信息。然而，由于其中涉及海量數(shù)據(jù)，及時查找和展示信息是一個巨大的挑戰(zhàn)。并行處理技術能夠解決這一挑戰(zhàn)。使用并行處理技術，數(shù)分種內(而非數(shù)小時或數(shù)天)就可以處理數(shù)TB級的數(shù)據(jù)。并行處理技術通過利用所有可用的硬件資源取得這樣的高性能：多個CPU、多個I/O通道、多個存儲陣列和磁盤驅動器，以及大量的內存。數(shù)據(jù)庫軟件越能有效地利用所有這些資源，處理查詢和其它數(shù)據(jù)庫操作就越有效。

此外，現(xiàn)在的數(shù)據(jù)庫應用的復雜性大大都增強了，不僅需要支持大量并發(fā)用戶，而且需要管理不同類型的用戶。因此，一個并行查詢體系結構不僅應該確保底層硬件平臺的所有資源都得到充分利用，而且應該更進一步，將這些資源適當?shù)胤峙浣o多個并發(fā)請求。很顯然，支持CEO的戰(zhàn)略決策的請求比執(zhí)行批處理報表更加重要，并行查詢體系結構應該能夠處理這些商務要求：不僅基于請求自身，而且應該基于發(fā)出請求的人以及當前可用的系統(tǒng)資源的數(shù)量來做出動態(tài)的分配。

Oracle9i 的并行處理體系結構能夠全面滿足這些要求，Oracle9i的體系結構不僅提供業(yè)界領先的高性能，而且是唯一可以自適應和動態(tài)調整的。

Oracle9i 的并行處理體系結構充分利用每種硬件投資――SMP、群集或MPP的優(yōu)勢——在任何時間保證最佳的吞吐量和連續(xù)的、優(yōu)化的系統(tǒng)使用量。

Oracle9i 數(shù)據(jù)庫根據(jù)可用資源、請求優(yōu)先級和實際系統(tǒng)負載控制來平衡所有并行操作。

并行化設計策略——靜態(tài)與動態(tài)

并行處理的思想就是將單個任務分解為多個更小的單元。不是通過一個進程完成所有工作，而是將任務并行化而使多個進程同時在更小的單元上運行。這可以極大地提高性能和最佳地利用系統(tǒng)。然而，并行處理的最關鍵部分是如何作出將單個任務分成更小的工作單元的正確決策。

典型地，有兩種方法用于實現(xiàn)數(shù)據(jù)庫系統(tǒng)的并行處理。主要區(qū)別在于是否需要進行物理數(shù)據(jù)布局，將靜態(tài)的數(shù)據(jù)分區(qū)作為并行處理的前提。

通過物理數(shù)據(jù)分區(qū)的靜態(tài)并行——不共享

在純不共享數(shù)據(jù)庫體系結構中必須將數(shù)據(jù)庫文件在多計算機系統(tǒng)的節(jié)點上進行分區(qū)才能進行并行處理。每個節(jié)點擁有一個數(shù)據(jù)子集，擁有節(jié)點使用單一進程或線程，以獨占方式執(zhí)行對此數(shù)據(jù)子集的所有訪問。數(shù)據(jù)訪問不能在分區(qū)內并行。(有時，也用術語“虛擬處理器”來代替節(jié)點?！疤摂M處理器”是在SMP計算機上模擬不共享節(jié)點的一種機制。為了簡單，在討論不共享體系結構時，我們將統(tǒng)一使用“節(jié)點”作為術語)。換句話說，純不共享系統(tǒng)使用分區(qū)或受限訪問方法在多個處理節(jié)點間劃分工作。節(jié)點對數(shù)據(jù)所有權的改變相對少見——為了適應業(yè)務需求的改變而進行的數(shù)據(jù)庫重組、添加或刪除節(jié)點以及節(jié)點故障是所有權更改的典型原因。這種數(shù)據(jù)所有權的改變對純不共享系統(tǒng)而言總是意味著要進行人工管理。

從概念上看，可以認為純不共享系統(tǒng)與分布式數(shù)據(jù)庫非常相似。為了在某個節(jié)點上執(zhí)行要求的讀/寫操作，該節(jié)點上的事務必須將消息發(fā)送給擁有需要被訪問的數(shù)據(jù)的其它節(jié)點，并協(xié)調在其它節(jié)點上完成的工作。將消息傳遞給其它節(jié)點，在它們擁有的數(shù)據(jù)集上請求執(zhí)行特定操作(功能)稱為功能傳送。另一方面，如果從遠程節(jié)點請求簡單數(shù)據(jù)，則必須訪問完整的數(shù)據(jù)集并將它從擁有節(jié)點返回至請求節(jié)點(數(shù)據(jù)傳送)。

在不共享體系結構下的并行處理像分布式數(shù)據(jù)庫一樣運作。每個節(jié)點以獨占方式擁有其數(shù)據(jù)分區(qū)。沒有其它任何節(jié)點可以訪問此數(shù)據(jù)，而使節(jié)點成為單一的訪問點和故障點。

此方法具有一些基本缺點，無法解決今天高端環(huán)境對可伸縮性和高可用性要求：

首先，不共享方法在用于共享一切的SMP硬件時并不是最佳的。為了獲得并行處理的益處而要求對數(shù)據(jù)進行物理分區(qū)，在共享一切的SMP系統(tǒng)中很明顯是一種人工的、過時的要求。因為在SMP系統(tǒng)中每個處理器都可以對所有數(shù)據(jù)進行直接的、等同的訪問。

其次，在不共享方法中使用嚴格的基于分區(qū)的并行處理策略，通常會導致不正常的資源利用。例如以下兩種情況：在沒有必要訪問表的所有分區(qū)時;或當單一節(jié)點所擁有的更大的未分區(qū)表是操作的一部分時。在這些情況下，限制分區(qū)內并行處理的緊密所有權模式，無法利用所有可用的處理能力，因而不能提供最佳的處理能力使用方案。

第三，由于具有對節(jié)點對應物理數(shù)據(jù)分區(qū)的關系，不共享系統(tǒng)在適應變化的業(yè)務需求方面一點都不靈活。當業(yè)務增長時，無法方便地以增量方式擴充系統(tǒng)來適應增長的業(yè)務需求?？梢陨壦鞋F(xiàn)有的節(jié)點，保持它們對稱并避免數(shù)據(jù)重新分區(qū)。在大多數(shù)情形下，升級所有節(jié)點費用太高;必須添加新節(jié)點并重組(進行物理重新分區(qū))現(xiàn)有數(shù)據(jù)庫。一個不需要進行任何重組的方案總是比必須重組的方案要更好，即使可以利用到最復雜的重組工具。

最后，由于使用嚴格的受限制的訪問模式，不共享系統(tǒng)無法完全利用群集系統(tǒng)為保證系統(tǒng)高可靠性所提供的潛在的容錯能力。

毫無疑問，基于使用靜態(tài)數(shù)據(jù)分布的不共享體系結構，大量的并行處理可以在實驗室條件下并行化和擴展。然而，在每個現(xiàn)實環(huán)境中，必須正確地解決上面談到的問題才能滿足今天高端關鍵任務要求。

執(zhí)行時的動態(tài)并行——共享一切

使用Oracle 的動態(tài)并行處理框架，可以共享所有數(shù)據(jù)。并行化和將工作分成更小的單元的決策，并不受限于數(shù)據(jù)庫設置(創(chuàng)建)時所做的任何預先確定的靜態(tài)數(shù)據(jù)分布。

由于能夠為每個語句構造不受限制的、優(yōu)化的數(shù)據(jù)子集，執(zhí)行時動態(tài)并行可以提供與不共享體系結構等同的或甚至更好的可伸縮性。

每個查詢在訪問、連接和處理數(shù)據(jù)的不同部分時都有它自己的特征。因此，每個SQL語句在被解析時都要進行優(yōu)化和并行化處理。數(shù)據(jù)更改時，如果有更加優(yōu)化的并行執(zhí)行計劃可用，或者系統(tǒng)中新添加了一個節(jié)點，那么Oracle可以自動適應新的情況。這樣可為并行化任何種類的操作提供最高程度的靈活性：

(1)在語句執(zhí)行前，對于每個查詢要求，會動態(tài)地優(yōu)化并行訪問的物理數(shù)據(jù)子集。

(2)對于每個查詢，都會優(yōu)化其并行度。與不共享環(huán)境不同，不存在必需的最小并行度來調用所有節(jié)點訪問所有數(shù)據(jù)，這是訪問所有數(shù)據(jù)的基礎要求。

(3)操作可以根據(jù)當前工作負載、特征和查詢的重要性，使用一個、一些或全部 Application Cluster 節(jié)點并行運行。

只要語句得到優(yōu)化和并行化，就可以知道所有后續(xù)的并行子任務。原始進程變?yōu)椴樵儏f(xié)調器;并行處理服務器(PX 服務器)從一個或多個節(jié)點上的并行處理服務器的公用緩沖池得到分配，并開始并行執(zhí)行該操作。

與不共享體系結構相似，共享一切體系結構中的每個并行處理服務器在其個人數(shù)據(jù)子集上獨立工作。數(shù)據(jù)或功能在并行進程之間的傳送機制也與上述的不共享體系結構相似或者相同。確定請求的并行計劃之后，每個并行處理服務器都知道其數(shù)據(jù)集和任務，而進程間通信就像在不共享環(huán)境中一樣很少。

然而，與不共享體系結構不同，每個并行處理的SQL 語句不需要考慮任何物理數(shù)據(jù)庫布局限制就可以進行優(yōu)化。這使得每個并行處理可以構造最佳的數(shù)據(jù)子集，從而提供與純不共享體系結構相比同等的，甚至在大多數(shù)情形下更好的可伸縮性和性能。只要有益，并行操作的后續(xù)步驟就會由一個并行處理服務器進行組合和處理，從而減少數(shù)據(jù)傳送或功能傳送的需求。

為什么共享一切比不共享更好?

不共享體系結構可以追溯到將海量并行處理(MPP)系統(tǒng)看作唯一能提供可伸縮的高端并行計算的硬件體系結構。MPP系統(tǒng)中的每個節(jié)點都有它自己的系統(tǒng)組件(CPU、內存和磁盤)，在不同的子任務上工作，并且不能共享其任何資源。

這一切都已過去?，F(xiàn)在，大多數(shù)成功的、廣泛使用的并行硬件系統(tǒng)都是對稱多處理器系統(tǒng)(SMP)， 要么是單機的，要么是作為松耦合的群集。SMP系統(tǒng)利用共享公用內存和磁盤資源的多處理器，因而也被稱為“共享一切”系統(tǒng)。

純不共享體系結構的支持者總是聲稱共享一切體系結構(特別是群集環(huán)境)對于高端環(huán)境會缺乏可伸縮性并引起顯著的開銷，因而這種體系結構不能用于具有高度并行和/或并發(fā)性的高端應用。這種說法是錯誤的。今天的硬件和軟件技術已經(jīng)解決了過去所有的問題，如高速群集互連或Oracle Application Clusters 的高速緩存融合體系結構。

Oracle 的動態(tài)并行處理框架建立在與不共享軟件相同的并行高級計算基礎設計之上，具有所有的優(yōu)點，還增強了其功能并克服了不共享方法在體系結構上的缺點?；诓还蚕碓淼能浖梢钥醋魇堑谝淮?、但已經(jīng)過時的數(shù)據(jù)庫并行處理軟件。