并行处理技术是数据库的一项核心技术，它使组织能够高效地治理和访问TB级的数据。假如不能提供高效的并行处理技术，这些大型数据库（通常用于数据仓库但也越来越多地出现在业务系统中）将不会存在。
简而言之，并行处理就是利用多个CPU和I/O资源来执行单个数据库操作。尽管现在每个主要的数据库供给商都声称可以提供并行处理能力，但每个供给商所提供的体系结构其实存在要害的差异。
本文讨论Oracle 9i并行处理的体系结构，并说明了在实际应用中其相对于其它体系结构的优越性。需要着重指出的是，Oracle9i并行处理体系结构的主要优点在于它能在任何情况下完全利用底层硬件基础架构——每个处理器单元、每个内存字节以及所有可用的I/O带宽。本白皮书还讲述Oracle 并行处理组件与其它要害业务组件（例如：Oracle RealApplication Cluster）的无缝集成。
简介
现在的数据库，无论是用于数据仓库、操作数据存储(ODS)或OLTP 系统，都包含丰富的信息。然而，由于其中涉及海量数据，及时查找和展示信息是一个巨大的挑战。并行处理技术能够解决这一挑战。使用并行处理技术，数分种内（而非数小时或数天）就可以处理数TB级的数据。并行处理技术通过利用所有可用的硬件资源取得这样的高性能：多个CPU、多个I/O通道、多个存储阵列和磁盘驱动器，以及大量的内存。数据库软件越能有效地利用所有这些资源，处理查询和其它数据库操作就越有效。
此外，现在的数据库应用的复杂性大大都增强了，不仅需要支持大量并发用户，而且需要治理不同类型的用户。因此，一个并行查询体系结构不仅应该确保底层硬件平台的所有资源都得到充分利用，而且应该更进一步，将这些资源适当地分配给多个并发请求。很显然，支持CEO的战略决策的请求比执行批处理报表更加重要，并行查询体系结构应该能够处理这些商务要求：不仅基于请求自身，而且应该基于发出请求的人以及当前可用的系统资源的数量来做出动态的分配。
Oracle9i 的并行处理体系结构能够全面满足这些要求，Oracle9i的体系结构不仅提供业界领先的高性能，而且是唯一可以自适应和动态调整的。
Oracle9i 的并行处理体系结构充分利用每种硬件投资――SMP、群集或MPP的优势——在任何时间保证最佳的吞吐量和连续的、优化的系统使用量。
Oracle9i 数据库根据可用资源、请求优先级和实际系统负载控制来平衡所有并行操作。
并行化设计策略——静态与动态
并行处理的思想就是将单个任务分解为多个更小的单元。不是通过一个进程完成所有工作，而是将任务并行化而使多个进程同时在更小的单元上运行。这可以极大地提高性能和最佳地利用系统。然而，并行处理的最要害部分是如何作出将单个任务分成更小的工作单元的正确决策。
典型地，有两种方法用于实现数据库系统的并行处理。主要区别在于是否需要进行物理数据布局，将静态的数据分区作为并行处理的前提。
通过物理数据分区的静态并行——不共享
在纯不共享数据库体系结构中必须将数据库文件在多计算机系统的节点上进行分区才能进行并行处理。每个节点拥有一个数据子集，拥有节点使用单一进程或线程，以独占方式执行对此数据子集的所有访问。数据访问不能在分区内并行。（有时，也用术语“虚拟处理器”来代替节点。“虚拟处理器”是在SMP计算机上模拟不共享节点的一种机制。为了简单，在讨论不共享体系结构时，我们将统一使用“节点”作为术语）。换句话说，纯不共享系统使用分区或受限访问方法在多个处理节点间划分工作。节点对数据所有权的改变相对少见——为了适应业务需求的改变而进行的数据库重组、添加或删除节点以及节点故障是所有权更改的典型原因。这种数据所有权的改变对纯不共享系统而言总是意味着要进行人工治理。
从概念上看，可以认为纯不共享系统与分布式数据库非常相似。为了在某个节点上执行要求的读/写操作，该节点上的事务必须将消息发送给拥有需要被访问的数据的其它节点，并协调在其它节点上完成的工作。将消息传递给其它节点，在它们拥有的数据集上请求执行特定操作（功能）称为功能传送。另一方面，假如从远程节点请求简单数据，则必须访问完整的数据集并将它从拥有节点返回至请求节点（数据传送）。
在不共享体系结构下的并行处理像分布式数据库一样运作。每个节点以独占方式拥有其数据分区。没有其它任何节点可以访问此数据，而使节点成为单一的访问点和故障点。
此方法具有一些基本缺点，无法解决今天高端环境对可伸缩性和高可用性要求：
首先，不共享方法在用于共享一切的SMP硬件时并不是最佳的。为了获得并行处理的益处而要求对数据进行物理分区，在共享一切的SMP系统中很明显是一种人工的、过时的要求。因为在SMP系统中每个处理器都可以对所有数据进行直接的、等同的访问。
其次，在不共享方法中使用严格的基于分区的并行处理策略，通常会导致不正常的资源利用。例如以下两种情况：在没有必要访问表的所有分区时；或当单一节点所拥有的更大的未分区表是操作的一部分时。在这些情况下，限制分区内并行处理的紧密所有权模式，无法利用所有可用的处理能力，因而不能提供最佳的处理能力使用方案。
第三，由于具有对节点对应物理数据分区的关系，不共享系统在适应变化的业务需求方面一点都不灵活。当业务增长时，无法方便地以增量方式扩充系统来适应增长的业务需求。可以升级所有现有的节点，保持它们对称并避免数据重新分区。在大多数情形下，升级所有节点费用太高；必须添加新节点并重组（进行物理重新分区）现有数据库。一个不需要进行任何重组的方案总是比必须重组的方案要更好，即使可以利用到最复杂的重组工具。
最后，由于使用严格的受限制的访问模式，不共享系统无法完全利用群集系统为保证系统高可靠性所提供的潜在的容错能力。
毫无疑问，基于使用静态数据分布的不共享体系结构，大量的并行处理可以在实验室条件下并行化和扩展。然而，在每个现实环境中，必须正确地解决上面谈到的问题才能满足今天高端要害任务要求。
执行时的动态并行——共享一切
使用Oracle 的动态并行处理框架，可以共享所有数据。并行化和将工作分成更小的单元的决策，并不受限于数据库设置（创建）时所做的任何预先确定的静态数据分布。
由于能够为每个语句构造不受限制的、优化的数据子集，执行时动态并行可以提供与不共享体系结构等同的或甚至更好的可伸缩性。
每个查询在访问、连接和处理数据的不同部分时都有它自己的特征。因此，每个SQL语句在被解析时都要进行优化和并行化处理。数据更改时，假如有更加优化的并行执行计划可用，或者系统中新添加了一个节点，那么Oracle可以自动适应新的情况。这样可为并行化任何种类的操作提供最高程度的灵活性：
(1)在语句执行前，对于每个查询要求，会动态地优化并行访问的物理数据子集。
(2)对于每个查询，都会优化其并行度。与不共享环境不同，不存在必需的最小并行度来调用所有节点访问所有数据，这是访问所有数据的基础要求。
(3)操作可以根据当前工作负载、特征和查询的重要性，使用一个、一些或全部Real Application Cluster 节点并行运行。
只要语句得到优化和并行化，就可以知道所有后续的并行子任务。原始进程变为查询协调器；并行处理服务器（PX 服务器）从一个或多个节点上的并行处理服务器的公用缓冲池得到分配，并开始并行执行该操作。
与不共享体系结构相似，共享一切体系结构中的每个并行处理服务器在其个人数据子集上独立工作。数据或功能在并行进程之间的传送机制也与上述的不共享体系结构相似或者相同。确定请求的并行计划之后，每个并行处理服务器都知道其数据集和任务，而进程间通信就像在不共享环境中一样很少。
然而，与不共享体系结构不同，每个并行处理的SQL 语句不需要考虑任何物理数据库布局限制就可以进行优化。这使得每个并行处理可以构造最佳的数据子集，从而提供与纯不共享体系结构相比同等的，甚至在大多数情形下更好的可伸缩性和性能。只要有益，并行操作的后续步骤就会由一个并行处理服务器进行组合和处理，从而减少数据传送或功能传送的需求。
为什么共享一切比不共享更好？
不共享体系结构可以追溯到将海量并行处理(MPP)系统看作唯一能提供可伸缩的高端并行计算的硬件体系结构。MPP系统中的每个节点都有它自己的系统组件（CPU、内存和磁盘），在不同的子任务上工作，并且不能共享其任何资源。
这一切都已过去。现在，大多数成功的、广泛使用的并行硬件系统都是对称多处理器系统(SMP)， 要么是单机的，要么是作为松耦合的群集。SMP系统利用共享公用内存和磁盘资源的多处理器，因而也被称为“共享一切”系统。
纯不共享体系结构的支持者总是声称共享一切体系结构（非凡是群集环境）对于高端环境会缺乏可伸缩性并引起显著的开销，因而这种体系结构不能用于具有高度并行和/或并发性的高端应用。这种说法是错误的。今天的硬件和软件技术已经解决了过去所有的问题，如高速群集互连或Oracle Real Application Clusters 的高速缓存融合体系结构。
Oracle 的动态并行处理框架建立在与不共享软件相同的并行高级计算基础设计之上，具有所有的优点，还增强了其功能并克服了不共享方法在体系结构上的缺点。基于不共享原理的软件可以看作是第一代、但已经过时的数据库并行处理软件。
