| | |
| | |
执行概要
并行处理技术是数据库的一项核心技术，它使组织能够高效地管理和访问TB级的数据。如
果不能提供高效的并行处理技术，这些大型数据库（通常用于数据仓库但也越来越多地出现在
简而言之，并行处理就是利用多个CPU和I/O资源来执行单个数据库操作。尽管现在每个主
要的数据库供应商都声称可以提供并行处理能力，但每个供应商所提供的体系结构其实存在关
本白皮书讨论Oracle9 i 并行处理的体系结构，并说明于在实际应用中其相对于其它体系
结构的优越性。需要着重指出的是，Oracle9i并行处理体系结构的主要优点在于它能在任何情
况下完全利用底层硬件基础架构??每个处理器单元、每个内存字节以及所有可用的I/O带宽
。本白皮书还讲述Oracle 并行处理组件与其它关键业务组件（例如：Oracle
简介
现在的数据库，无论是用于数据仓库、操作数据存储(ODS)或OLTP 系统，都包含丰富的信
息。然而，由于其中涉及海量数据，及时查找和展示信息是一个巨大的挑战。并行处理技术能
够解决这一挑战。使用并行处理技术，数分种内（而非数小时或数天）就可以处理数TB级的数
据。并行处理技术通过利用所有可用的硬件资源取得这样的高性能：多个CPU、多个I/O通道、
多个存储阵列和磁盘驱动器，以及大量的内存。数据库软件越能有效地利用所有这些资源，处
此外，现在的数据库应用的复杂性大大都增强了，不仅需要支持大量并发用户，而且需要
管理不同类型的用户。因此，一个并行查询体系结构不仅应该确保底层硬件平台的所有资源都
得到充分利用，而且应该更进一步，将这些资源适当地分配给多个并发请求。很显然，支持
CEO的战略决策的请求比执行批处理报表更加重要，并行查询体系结构应该能够处理这些商务
要求：不仅基于请求自身，而且应该基于发出请求的人以及当前可用的系统资源的数量来做出
Oracle9i 的并行处理体系结构能够全面满足这些要求，Oracle9i的体系结构不仅提供业
Oracle9i 的并行处理体系结构充分利用每种硬件投资――SMP、群集或MPP的优势??在
任何时间保证最佳的吞吐量和连续的、优化的系统使用量。
Oracle9i 数据库根据可用资源、请求优先级和实际系统负载控制来平衡所有并行操作。
并行化设计策略??静态与动态
并行处理的思想就是将单个任务分解为多个更小的单元。不是通过一个进程完成所有工作
，而是将任务并行化而使多个进程同时在更小的单元上运行。这可以极大地提高性能和最佳地
利用系统。然而，并行处理的最关键部分是如何作出将单个任务分成更小的工作单元的正确决
典型地，有两种方法用于实现数据库系统的并行处理。主要区别在于是否需要进行物理数
据布局，将静态的数据分区作为并行处理的前提。
通过物理数据分区的静态并行??不共享
在纯不共享数据库体系结构中必须将数据库文件在多计算机系统的节点上进行分区才能进
行并行处理。每个节点拥有一个数据子集，拥有节点使用单一进程或线程，以独占方式执行对
此数据子集的所有访问。数据访问不能在分区内并行。（有时，也用术语“虚拟处理器”来代
替节点。“虚拟处理器”是在SMP计算机上模拟不共享节点的一种机制。为了简单，在讨论不
共享体系结构时，我们将统一使用“节点”作为术语）。换句话说，纯不共享系统使用分区或
受限访问方法在多个处理节点间划分工作。节点对数据所有权的改变相对少见??为了适应业
务需求的改变而进行的数据库重组、添加或删除节点以及节点故障是所有权更改的典型原因。
这种数据所有权的改变对纯不共享系统而言总是意味着要进行人工管理。
从概念上看，可以认为纯不共享系统与分布式数据库非常相似。为了在某个节点上执行要
求的读/写操作，该节点上的事务必须将消息发送给拥有需要被访问的数据的其它节点，并协
调在其它节点上完成的工作。将消息传递给其它节点，在它们拥有的数据集上请求执行特定操
作（功能）称为功能传送。另一方面，如果从远程节点请求简单数据，则必须访问完整的数据
集并将它从拥有节点返回至请求节点（数据传送）。
在不共享体系结构下的并行处理像分布式数据库一样运作。每个节点以独占方式拥有其数
据分区。没有其它任何节点可以访问此数据，而使节点成为单一的访问点和故障点
此方法具有一些基本缺点，无法解决今天高端环境对可伸缩性和高可用性要求:
(1)、首先，不共享方法在用于共享一切的SMP硬件时并不是最佳的。为了获得并行处
理的益处而要求对数据进行物理分区，在共享一切的SMP系统中很明显是一种人工的、过时的
要求。因为在SMP系统中每个处理器都可以对所有数据进行直接的、等同的访问。
(2)、其次，在不共享方法中使用严格的基于分区的并行处理策略，通常会导致不正常
的资源利用。例如以下两种情况：在没有必要访问表的所有分区时；或当单一节点所拥有的更
大的未分区表是操作的一部分时。在这些情况下，限制分区内并行处理的紧密所有权模式，无
法利用所有可用的处理能力，因而不能提供最佳的处理能力使用方案。
(3)、第三，由于具有对节点对应物理数据分区的关系，不共享系统在适应变化的业务
需求方面一点都不灵活。当业务增长时，无法方便地以增量方式扩充系统来适应增长的业务需
求。可以升级所有现有的节点，保持它们对称并避免数据重新分区。在大多数情形下，升级所
有节点费用太高；必须添加新节点并重组（进行物理重新分区）现有数据库。一个不需要进行
任何重组的方案总是比必须重组的方案要更好，即使可以利用到最复杂的重组工具。
(4)、最后，由于使用严格的受限制的访问模式，不共享系统无法完全利用群集系统为
毫无疑问，基于使用静态数据分布的不共享体系结构，大量的并行处理可以在实验室条件
下并行化和扩展。然而，在每个现实环境中，必须正确地解决上面谈到的问题才能满足今天高
执行时的动态并行??共享一切
使用Oracle 的动态并行处理框架，可以共享所有数据。并行化和将工作分成更小的单元
的决策，并不受限于数据库设置（创建）时所做的任何预先确定的静态数据分布。
由于能够为每个语句构造不受限制的、优化的数据子集，执行时动态并行可以提供与不共
享体系结构等同的或甚至更好的可伸缩性。
每个查询在访问、连接和处理数据的不同部分时都有它自己的特征。因此，每个SQL语句
在被解析时都要进行优化和并行化处理。数据更改时，如果有更加优化的并行执行计划可用，
或者系统中新添加了一个节点，那么Oracle可以自动适应新的情况。这样可为并行化任何种类
(1)、在语句执行前，对于每个查询要求，会动态地优化并行访问的物理数据子集。
(2)、对于每个查询，都会优化其并行度。与不共享环境不同，不存在必需的最小并行
度来调用所有节点访问所有数据，这是访问所有数据的基础要求。
(3)、操作可以根据当前工作负载、特征和查询的重要性，使用一个、一些或全部
只要语句得到优化和并行化，就可以知道所有后续的并行子任务。原始进程变为查询协调
器；并行处理服务器（PX 服务器）从一个或多个节点上的并行处理服务器的公用缓冲池得到
与不共享体系结构相似，共享一切体系结构中的每个并行处理服务器在其个人数据子集上
独立工作。数据或功能在并行进程之间的传送机制也与上述的不共享体系结构相似或者相同。
确定请求的并行计划之后，每个并行处理服务器都知道其数据集和任务，而进程间通信就像在
然而，与不共享体系结构不同，每个并行处理的SQL 语句不需要考虑任何物理数据库布局
限制就可以进行优化。这使得每个并行处理可以构造最佳的数据子集，从而提供与纯不共享体
系结构相比同等的，甚至在大多数情形下更好的可伸缩性和性能。只要有益，并行操作的后续
步骤就会由一个并行处理服务器进行组合和处理，从而减少数据传送或功能传送的需求。
为什么共享一切比不共享更好？
不共享体系结构可以追溯到将海量并行处理(MPP)系统看作唯一能提供可伸缩的高端并行
计算的硬件体系结构。MPP系统中的每个节点都有它自己的系统组件（CPU、内存和磁盘），
这一切都已过去。现在，大多数成功的、广泛使用的并行硬件系统都是对称多处理器系统
(SMP)， 要么是单机的，要么是作为松耦合的群集。SMP系统利用共享公用内存和磁盘资源的
多处理器，因而也被称为“共享一切”系统。
纯不共享体系结构的支持者总是声称共享一切体系结构（特别是群集环境）对于高端环境
会缺乏可伸缩性并引起显著的开销，因而这种体系结构不能用于具有高度并行和/或并发性的
高端应用。这种说法是错误的。今天的硬件和软件技术已经解决了过去所有的问题，如高速群
集互连或Oracle Real Application Clusters 的高速缓存融合体系结构。
Oracle 的动态并行处理框架建立在与不共享软件相同的并行高级计算基础设计之上，具
有所有的优点，还增强了其功能并克服了不共享方法在体系结构上的缺点。基于不共享原理的
软件可以看作是第一代、但已经过时的数据库并行处理软件。
应该注意到，基于不共享方法的并行处理软件正在试图通过采用新的共享机制来克服前面
谈到的缺点,而其所采用的技术正是Oracle独特的、且早已实现的动态并行处理的基本组件。
(1)、多个虚拟节点在单个大型SMP机器上运行，在共享一切硬件上模拟不共享的节点
(2)、分区内并行??在不共享系统内的单个节点上实现“共享一切”式的数据访问
(3)、节点故障切换机制克服可用性障碍，要求物理共享磁盘访问。除非具有空闲节点
日常生活中的并行
现在我们看一个简单的例子，说明Oracle的动态并行处理的不同与优越之处：在某些方面
，静态并行与动态并行的体系结构反映一个来自队列理论的基本问题。例如，考虑一下进入邮
局时会发生什么。邮局有多个窗口，每个窗口都有一个邮政工作人员。
一种方法是让客户在每个窗口的前面排成一条队等候直到该窗口提供服务为止。另一种方
法是让所有的窗口都排一条队，在该队列的前面的客户去第一个可用的窗口。
在许多方面，静态并行与第一种方法相似，而动态并行与第二种方法相似。因为排过队的
人都知道，只排一条队通常可以使平均等待时间最小化。类似的情况是：邮政窗口是可用的并
行处理服务器，而客户是需要完成的数据库操作的单独部分。
动态模型中，查询协调器对第一个可用的并行处理服务器分配数据库操作。在查询开始之
前，没有办法知道哪个操作将由哪个并行处理服务器来完成。在静态模型中，该工作在查询开
事实上，静态并行方法比上述排队方式更为糟糕。静态并行方法不仅要求每个窗口一个客
户队列，而且要求特定的客户仅可以在某个特定的窗口前排队（就像特定的数据集仅可以由特
定节点进行访问一样）。也就是说，邮局有一个窗口，用于姓氏为以字母A 至字母D 开头的所
有客户，而有另一个窗口，用于姓氏为以字母E 至字母H 开头的所有客户，以此类推。如果名
字为Mr. Adams 的客户站在A-D 窗口的长队中，并注意到E-H队列没有人排队，但Mr. Adams
不能换队，因为A-D 窗口是唯一允许为他提供服务的窗口。如果A-D 窗口的职员生病或需要窗
口J-L 处理一些可用的其它信息，该怎么办？如何使用静态并行方法使邮局运转来应对类似季
您希望访问哪个邮局？
ORACLE 的并行处理体系结构
“并行一切”的原理
Oracle根据共享一切的战略建立并行处理框架，Oracle 可以对数据库中的一切进行并行
处理操作。不管是将数据装入到单个分区中，建立新的索引结构，多个用户正在分析上个月的
销售数据，或者系统正在恢复被中断的事务处理，或者仅使用一个分区进行处理??所有的这
些操作都能以很高的可伸缩性并行完成，使用最佳的并行度和最佳的并行（物理的）工作单元
。Oracle9 i 及其动态的、可伸缩的并行一切功能，能够在任何情况下充分利用硬件投资、保
证最佳的吞吐量和连续的、优化的系统使用。
Oracle 如何并行化操作
Oracle 服务器由一个Oracle 数据库和一个Oracle 服务器实例组成；使用Oracle Real
Application Clusters 时，群集中的每个节点上运行一个数据库实例且访问相同的Oracle
数据库。每个实例提供一个并行处理服务器缓冲池。此缓冲池将由该实例的任何并行操作或相
同群集内的其它实例所使用。与不共享系统不同，没有任何静态数据行分配给节点。根据从任
何物理数据库创建中解除耦合的系统硬件功能，选择足够数量的执行服务器。所以，当业务量
增加时，添加附加的硬件资源（如附加的CPU）是即插即用的，且不需要任何物理重新分区。
避免数据的物理重新分发，总是比以最优的方式实现物理重新分发要好。
执行并行操作时，并行处理协调器从缓冲池中获得并行处理服务器并将它们分配至该操作
。在该语句已被完全处理之后，并行处理服务器返回到缓冲池中。用于某个操作的并行处理服
务器的数量称为并行度(DOP)，它是在查询执行时根据系统的当前工作负载和其它条件（如用
户查询的业务优先级）确定的。在本白皮书的后文中，我们将详细讨论Oracle 如何确定并行
在静态并行体系结构下，由于其体系结构上固有的限制，并行处理服务器的静态数量是在
对象创建时确定的，Oracle 没有此限制。在不共享环境中，每个数据分区至少需要一个进程
；而不经过物理数据重新分发，对象的最小DOP 无法进行更改。
关于并行一切操作的知识内置在优化器中；当确定某个语句的执行计划时，会决定关于每
个操作的DOP 和最佳并行化方法。例如，全表扫描的并行操作可能会按数据库块进行，而索引
范围扫描的并行操作可能是按分区进行。此外，每个操作的重新分发要求也会被确定。一个操
作的重新分发是指在并行处理服务器中划分或重新分发执行操作的行。Oracle 的“并行敏感
”优化使用增强的重新分发机制（如，连接优化的小行集的广播或在不同的并行处理服务器之
间的偏向性重新分发。Oracle 的共享一切方法还消除了由于数据的静态节点的亲合性所需要
的所有数据重新分发，不共享体系结构在多个或甚至全部节点上冗余地复制相同的数据时，经
在执行计划中确定了每个操作的重新分发要求之后，该优化器就会确定执行操作必须使用
的顺序。使用这一信息，优化器就可以确定最终的并行计划和语句的并行操作之间的数据流。
图2 对连接employees 和department 表的查询的数据流进行了图解：
SELECT department_name,
MAX(sal), AVG(sal)
FROM emp e, dept d
WHERE e.deptno = d.deptno
GROUP BY department_name;
要求其它操作的输出的操作称为父操作。在图2 中，SORT GROUP BY 操作是HASH JOIN 操
只要子操作已产生行结果，父操作就可以开始消耗行。在前一个例子中，并行处理服务器
在FULL SCAN dept 操作中生成行，而另一组并行处理服务器可以开始执行HASH JOIN 操作以
使用行。注意这第二组并行处理服务器将HASH JOIN 操作与emp 表的并行FULL SCAN 组合起来
，从而最小化SQL 语句的数据重新分发与通信。
同时执行的这两个操作中都被赋予它自己的并行处理服务器集。因此，查询操作和数据流
树本身都使用并行。单独操作的并行称为操作内并行，而在数据流树中的操作之间的并行称为
操作间并行。
图2：并行数据流的例子
图3 显示上面讨论的并行操作的执行计划。执行计划给了我们关于并行查询处理的更多信
息，即，数据分发是否已经发生及如何在并行处理服务器集之间分发数据（列“PQ 数据分发
”）。并行处理服务器组的标识符在列“PX 集”中显示。我们现在更仔细地观察一下这个示
例执行计划，以突出显示Oracle 的一些并行处理内部优化。
图3：并行处理计划的例子
只要有可能，后续操作会组合由相同的并行处理服务器集进行处理；这可以减少数据分发
和SQL语句的通信。在我们的示例查询中，操作ID 4、3 和2 是由相同的并行处理服务器集
(PX SET 1) 进行处理的。没有必要进行数据分发；这些操作步骤是组合的并行操作。
另外，会看到由操作ID 5 (FULL SCAN dept) 导出的行集被传播至后续的操作ID 3
(HASH JOIN)，从而优化这些操作之间的数据重新分发。
图4：使用“工作单元动态确定”优化的并行数据流
该查询表还显示在图1 中看不到的一个附加的操作步骤。在并行HASH JOIN 操作ID 3 后
面将数据重新分发之前，每个并行处理服务器将预排序和预集合其个人数据集（SORT GROUP
BY，操作ID 2），并在之后将它发送到后续的（最后的）排序和集合操作（操作ID 1）中。在
这些操作之间的数据重新分发是一个散列分发，确保对于在操作ID 1 上工作的所有并行处理
服务器都有一个同等均衡的工作负载。在最后操作之后，只要所有并行处理服务器都已完成其
工作（在查询中没有指定任何排序顺序），就会按随机顺序将结果集从所有并行处理服务器返
回到用户进程（操作ID 0）中。图4 显示使用上面讨论的并行处理优化的并行数据流。
动态确定工作单元
与不共享体系结构中的并行操作不同，Oracle 的并行处理基于用户请求、DOP 和实际的
系统负载，确定要访问的物理数据的最佳子集。Oracle 不依赖于任何跨节点的物理数据分发
在Oracle 中，使用并行的基本工作单元称为区组(granule)。Oracle 将正在进行并行化
的操作（如，表扫描、表更新或索引创建）划分为区组。
并行处理服务器一次执行一个区组操作。区组的数量及其大小与DOP 和对象大小相关。因
为Oracle 从内部作此决定，所以没有办法强制特定的区组策略。
依靠并行操作，Oracle 选择基于块范围的区组，或者选择完整的分区作为最佳区组策略
。看一下先前讨论的示例，Oracle 为全表扫描操作选择块范围分组,以优化和平衡所有受影
响的PX 服务器的工作分发。另一方面，类似并行智能化分区连接的操作使用分区分组来最小
化PX 服务器之间的数据重新分发。本白皮书的后文会更详细地讨论智能化分区连接的优化。
图5：并行全表扫描不共享与共享一切
提供选择分组特定操作的灵活性使得Oracle 能够优化并行处理，远远超过了不共享体系
图5 对如何在不共享环境中使用Oracle 的方法并行化emp 的FULL SCAN 进行了图解。假
定相同的并行度、相同数量的数据及具有相似的硬件功能，则对于这两种体系结构，执行时间
会近似相同。注意，对于不共享体系结构，并行度是静态的。
使用静态的、预定义的并行意味着什么？
图6 显示了，当数据的数量加倍且没有采取任何手工管理操作以物理重新分发任何数据时
，如何并行化相同的全表扫描。与不共享体系结构（其并行度是静态的）不同，Oracle 可以
自动选择一个更高的并行度（在我们的示例中DOP 也加倍）以适应更改后的环境。操作的执行
时间（而非并行度）保持稳定且可预测。
图6：并行全表扫描使数据容量加倍
并行处理服务器缓冲池
可用的并行处理(PX) 服务器总数可由数据库系统进行动态和自动调整。如果由某个实例
同时处理的并行操作的数量发生显著更改，Oracle 就会自动更改缓冲池中并行处理服务器的
“并行自动调整”根据可用的系统资源，为已优化的并行处理管理所有相关的数据库参数
如果并行操作的数量增加，Oracle 会创建额外的PX 服务器来处理进入的请求。然而，
它永远不会超出PX 服务器的上限，根据系统的硬件特征，该上限可以由数据库管理员手动定
义，或由数据库自动确定。这样可以防止系统因使用太多并发并行进程而过载；没有任何硬件
如果并行操作减少，Oracle 就会终止那些空闲时间超过某个阈值的任何并行处理服务器
启用了并行自动调整后，Oracle 就可以管理与并行处理相关的所有数据库设置。在大多
数情形下，Oracle 的自动化设置至少与手动导出的参数一样有效，并避免了由于错误的用户
负载或系统资源计算或假定而引起的手动调整错误。
然而，您可以改写数据库所做的任何缺省的设置，从而具有最大的灵活度并适应应用程序
控制并行度
特定SQL 语句的并行度(DOP) 是由三个影响因素驱动的：
1. 可用的硬件资源，确定系统的并行能力：根据可用的硬件资源，仅特定的最大并行进
程应该同时在系统上运行，从而使系统不至于过载。注意，这是一个硬件限制而非数据库限制
2. 开始执行该语句时系统上的当前工作负载：在确定可以分配用于执行并行操作的DOP
的过程中，系统上的当前工作负载是一个很重要的因素。
3. 基于对象属性启用的并行：
所有表和索引都有一个已定义的并行属性。应该将此属性设置为NOPARALLEL 或PARALLEL
DEFAULT。通常，后者为特定对象启用并行处理。或者，如果您希望显式控制并行处理，则可
以通过将对象的并行属性设置为一个具体的值（如PARALLEL 32）而为它请求特定的DOP。
4． 请求的业务优先级：
每个用户都属于所谓的资源消费者组。使用Database Resource Manager，您可以限制资
源消费者组（代表一个业务功能）可以允许的资源消耗；例如，最大并行度就表示这样的一个
除非有不同的指定，否则“并行自动调整”会通过考虑所有上面谈到的因素，确定特定语
句的并行度(DOP)。在Real Application Clusters 环境中，可以在所有、一些或仅一个群集
节点上启动PX 服务器。这是由数据库根据并行处理计划和当前系统与节点工作负载动态确定
的。它总是会在任一时刻保证最佳的系统吞吐量。
Oracle 自动的、可适应的并行度为获取最佳的系统吞吐量平衡所有并行操作。
Oracle 的自动和自适应多用户功能，基于系统的用户负载主动地调整所有操作的DOP。
可适应的多用户算法首先考虑由Database Resource Manager 计算分配的线程数。该算法接着
考虑实例并行的缺省设置，以及参与对象和任何SQL 提示的并行属性。
如果系统过载且输入DOP 大于缺省的DOP，该算法会使用缺省的并行度作为输入。系统接
着会计算应用到输入DOP 的减少因子。例如，使用16-CPU 系统时，如果第一个用户进入系统
时系统空闲，就会赋予该用户32 个DOP。下一个用户将被赋予8 个DOP，再下一个用户为4 个
DOP，以此类推。如果系统停留在八个用户发出查询的的稳定状态，则会最终赋予所有用户4
个DOP，从而在所有并行用户中间平均划分系统。这确保了系统在任一点都具有适时的最佳吞
考虑当前的工作负载并且在某个操作开始前减少DOP，与盲目地使用预置的并行度启动一
切相比，是一种更好的替代方法；后者是由不共享系统（它们无法更改DOP）使用的，不共享
系统为了避免耗尽系统资源，不得不在执行后期终止某些数据库活动。必须开发能够使用超出
尽管这样始终可以保证数据库系统的最佳吞吐量，但这可能并非您所希望的应用程序的运
行方式。因此，为了执行操作，您可以为您的应用指定必须可用的并行处理服务器数量的最小
百分比。此策略确保您的SQL 语句在定义明确的界限内按预测方式执行。如果请求的并行处理
服务器的最小百分比不可用，则SQL 语句不会执行并返回错误。
并行类型
所有业务关键操作都可以进行并行化。下列部分将讨论在大规模环境中各种类型的并行操
并行查询
大规模环境中最常见的并行操作是查询。由于Oracle 不需要申请读锁，在大规模系统中
，同时存在数百种不同类型的即席查询的高并发应用是很常见的事情。特别是，这些环境会受
您可以并行化SELECT 语句中的查询和子查询。对于大多数查询，Oracle 选择块区组，
保证了在所有参与PX 服务器上大致平均的工作负载分布。只有一个例外是涉及一个或多个已
分区表的并行HASH JOIN，此时优化器决定使用分区的区组。并行执行具有分区智能的对等连
接与任意并行连接相比，效率和性能都要高得多。后面我们会更加详细地讨论并行分区智能的
并行DDL
数据仓库环境通常面临创建大对象的任务??重建索引、创建中间阶段临时表或发出移动
数据的分区维护操作。可以为已分区和未分区的对象并行化所有这些类型的操作。
并行DML
并行DML（PARALLEL INSERT、UPDATE 和DELETE）依据大型数据库表和索引，使用并行处
并行DML 操作主要用于加快针对大型数据库对象的大型DML操作。并行DML 补充并行查询
，从而为您提供对大型数据库的查询和更新能力。尽管Oracle 提供一种有效的、可伸缩的并
行DML 框架，经验表明使用CREATE TABLE AS SELECT 命令创建的中间对象在大规模数据仓库
其它
除了并行SQL 执行之外，Oracle 还可以为每个重要的数据库操作使用并
行。本白皮书不会详细讨论这些功能。这些功能包括
(1)并行恢复
(2)并行传播（复制）
(3)并行读取外部表
(4)并行装载（SQL*Loader 实用程序）
并行处理与分区
为了确保每个并行操作都有大致平均且平衡的工作负载，所有参与进程的工作单元应该是
大致相同的。对于不共享环境而言，预先确定物理数据分区是实现并行处理的关键技术。所有
数据分区（用于为不共享系统确定工作单元的唯一基础）必须是同等大小的。这就是为什么不
共享系统的基础分区策略必须基于“散列”分区的唯一原因。基于散列值分布数据保证了等同
大小的数据分区，但记录的位置变得完全与记录的业务内容不相关；散列分布是纯物理分布。
与不共享系统不同，Oracle 不论是在SMP、Cluster或MPP的体系结构下，都不依赖于
Oracle 分区技术来实现并行处理。可以根据系统的业务要求选择分区策略，该策略是第一手
的，完全与任何并行操作都不相关。任何操作，无论是访问表的一个、一些或全部分区，仅根
据您的特定环境和业务要求（如硬件资源、数据容量或可用的时间窗口）就可以使用任何未加
此外，结合并行处理技术，Oracle 分区可以显著地提高大规模环境中的性能。
它讨论一些特定的领域：分区启用增强的并行操作，或分区与并行处理的组合显示与仅并
分区忽略
分区忽略是大规模环境中的一种重要的高性能特性。在分区忽略中，基于成本的优化器会
分析SQL 语句中的FROM 和WHERE 子句以在构建分区访问列表时消除不需要的分区。这使得
Oracle 能够仅需要在与SQL 语句相关的那些分区上执行操作。分区忽略显著地减少了需要从
磁盘检索的数据的数量，并缩短了处理时间，提高了查询性能和资源利用。
由于Oracle 最常使用的分区方法是逻辑的而不是纯物理（散列）的分区策略，大多数情
况下，许多查询很可能从分区忽略中受益。例如，假设某个应用程序包含一个存储订单历史记
录的“订单”表，并且此表已被按周分区。请求本周的最近订单的所有查询仅会访问“订单”
表的一个单一的分区。如果“订单”表包含2年的历史数据，则此查询会访问一个分区，而不
是去访问104 个分区。仅因使用分区忽略，此查询的执行就可以加快100 倍。
不共享系统由于需要依赖于跨节点散列分区实现并行处理，因此不能提供相同级别的复杂
操作。然而，我们姑且假设此时不共享系统会使用上面谈到的“订单”表的逻辑分区策略。我
们还假设系统会提供与Oracle 相同的分区忽略能力，如果只需要访问一个分区就可以满足业
务查询的需求，这对于并行操作来说意味着什么？仅访问“一个”分区会意味着仅“一个”节
点可以用于处理请求。不共享系统并行的基础会被破坏，而导致系统性能低下、被扭曲。
使用Oracle，分区忽略不会影响或干扰并行处理。与不共享环境不同，访问一个、一些或
全部分区的一个查询总是可以使用任何DOP 进行并行化；在群集的一个、一些或全部节点上被
智能分区连接
当要连接的表在连接键上被等值分区时，或并行处理操作且其中一个表在连接键上进行分
区时，会发生智能分区连接。智能分区连接通过最小化在连接并行处理时并行处理服务器之间
交换的数据的数量来降低查询响应时间。这样可以显著地减少响应时间并更加有效地使用CPU
在Oracle Real Application Clusters 环境中，智能分区连接还可以避免或至少限制节
点之间的数据通信量，这有助于为大量连接操作获得良好的可伸缩性。这使用与不共享体系结
构完全相同的机制，从而最小化它们的节点间通信。
图7：并行完全智能分区连接的例子
智能分区连接可以是完全的或部分的。在完全智能分区连接操作中，这两个表在连接键上
被等值分区。与完全智能分区连接不同，部分智能分区连接在连接键上仅有一个分区的表，而
不是全部两个表。已分区的表被作为参考表。部分智能分区连接比完全智能分区连接更为常见
。为了执行部分智能分区连接，Oracle 通常基于更大的、已分区参考表的分区键动态地重新
分发更小的、可能未分区的表。一旦这个表被动态重新分区，执行就与完全智能分区相似。
部分智能分区连接在未分区表中的连接上的性能优势是参考表在连接操作过程中不会被移
支持不共享并行方法的供应商主要依赖于智能分区连接以获取良好的查询性能。这是预先
确定数据与节点之间的亲合性和远程访问数据遗漏的可能性的实际结果。为了在这样的环境中
提高查询性能，这两个匹配分区应该对同一节点具有亲合性。必须将分区分布到所有节点上以
避免瓶颈和使用系统上所有可用的CPU 资源。尽管对于一个查询类，这可能为您带来性能上的
益处，但是它限制了您可以选择的数据模型且不允许更改查询的业务要求和类型。例如，如果
为了最有效地分析客户相关类型查询而优化“订单”表，则会在客户和订单表的连接键
customer_id. 上对它们进行分区。这样可启用这两个表的智能化分区连接并保证必须被连接
的分区的节点亲合性。然而，任何与产品相关的业务查询都不会被优化并会涉及跨节点数据重
新分布，从而使查询处理达不到最佳。业务要求的变化会引起极大的附加管理成本和停机时间
，这限制了实际应用能力，尽管这对于保持系统高性能很有必要：
(1)频繁的数据重新分区：在实际生活中，数据访问要求会随时间变化发生更改，这时
必须对数据进行重新分区以获得可接受的性能级别。另外，下列情形也要求进行重新分区：
(2)数据容量的显著增长
(3)处理节点的增加
(4)导致了不正常分区的数据分发模式中的转移
Oracle 在各种硬件平台上的并行体系结构
Oracle 的并行处理框架被内置在Oracle9 i 数据库中，且为群集环境和非群集环境进行
了优化。因此，它透明地为任何应用程序提供相同的功能，不管是在大型SMP 计算机上使用
Oracle，还是在MPP 计算机或松散耦后的群集上使用Oracle Real Application Clusters。
单节点SMP 环境中的并行处理
在单节点SMP 系统上运行Oracle 数据库使您能够完全利用所讨论的并行处理能力。该硬
件为并行处理提供资源（CPU 处理能力和I/O 带宽）。Oracle 管理剩余的一切。与需要在单
个计算机上运行多个人工“虚拟”不共享节点（实例）的不共享系统不同，您只需启动并运行
一个Oracle 实例。数据库上执行的每个语句可以不进行任何特殊的并行敏感设置或不使用任
何数据布局而执行，提供系统可支持的最大并行度。并行处理服务器之间的通信是在相同的实
例之内，并通过快速内存操作来完成。单一计算机是这样使用的，运行单个数据库实例并利用
低于限制的所有可用系统资源。不共享系统在单个计算机上需要运行多个实例以模拟不共享环
境。每个实例都有它自己的进程和内存分配集，与在群集环境中的行为方式相同。由于增加了
运行多个实例的开销，并强制它们像在不共享硬件体系结构中那样通信。所以，不共享系统在
Real Application Clusters 环境中的并行处理
Oracle 的第一个并行数据库Oracle Parallel Server 是在VMS 操作系统上随Oracle
V6 一起引入的。Oracle9 i 的Real Application Clusters (RAC) 是Oracle 的第四代并行数
据库体系结构，它为高容量关键任务应用程序提供线性的可伸缩性和可用性，从而为系统提供
线性的可伸缩性的获得在于可以充分挖掘任何种类的群集计算机系统的处理能力和冗余。
Oracle Real Application Clusters 使用现代群集互连设备以减少磁盘I/O，并能利用正在
形成的高带宽、低滞后时间的互连方式来提供线性的可伸缩性。它完全利用群集系统的扩展
CPU、内存和磁盘资源来推动更多的事务处理。
Oracle 的并行处理框架被内置到Oracle9 i 数据库中，且为群集环境和非群集环境进行
了优化。结果，它透明地为任何应用程序提供相同的功能，而不管是在大型SMP 计算机上使用
Oracle，还是在MPP 计算机或松散耦后的群集上使用Oracle Real Application Clusters。
为任意群集类型选择最好的方法
例如，因为并行处理在多个实例上分发大型SQL 语句的各个部分，所以并行处理在Real
Application Clusters 中执行得非常有效。因为事务在多个CPU 上执行，所以它完成得更快
在Real Application Clusters 中，Oracle在运行时确定它是应该在仅一个实例上运行并
行处理服务器进程，还是在多个实例上运行进程。通常，在有足够的资源可用时，Oracle 尝
试仅使用一个实例。这样可减少跨实例间的消息通信和同步。也会考虑群集环境的潜在特性细
节。例如，如果不共享硬件系统很流行，则强大的数据位置能力会更加重要。然而，几乎所有
当前群集系统都使用一个共享的磁盘体系结构，对所有节点的所有可用磁盘启用相同的I/O 访
在松散耦合系统中，Oracle 的并行处理技术使用一种功能传送策略以在可能时执行远程
节点上的工作。这样可提供有效的并行处理并消除互连之上不需要的节点间数据转移。
在不共享(MPP) 系统中，每个节点都与磁盘设备的一个子集有直接的硬件连接。在这些系
统上，从拥有节点访问本地设备会更加有效。Real Application Clusters 利用这种设备对节
点的亲合性并使用多计算机配置和共享磁盘体系结构来提供优于不共享系统的性能。
与Cache Fusion（高速缓存融合）的其它因素相同，Oracle 的策略透明地工作，而不需
要进行数据分区。Oracle 动态地检测目标数据所在的磁盘并以下列两种方式实现智能化使用
(1)Oracle 在要处理的数据所在的节点上衍生并行处理服务器进程
(2)Oracle 将本地数据分区分配到每个子进程，以消除或最小化节点间数据移动
动态群集和并行敏感查询优化
Oracle 的基于成本优化器考虑在确定最佳执行计划时使用并行处理。不同的访问路径（
如，表扫描与索引访问）成本的估计会考虑对操作可用的并行度。这会导致Oracle 选择为并
中等规模群集系统平均有四个节点，每个群集节点有四个CPU，这并不罕见。Oracle 在这
样一个系统上的设置将会是在每个节点上有一个Oracle实例，所有节点都访问相同的数据库。
设置每个节点上并行处理服务器的数量以反映每个节点并行处理的能力；例如，每个节点上有
16 个PX 服务器，总共有64 个PX 服务器。在此硬件上不共享系统的等同设置将会是每个群集
节点有16 个虚拟节点和数据分区，总共有64 个分区。在不共享环境中，如果希望并行访问
每个对象，则必须对其进行分区。而且，接着所有这些对象必须始终使用64 的并行度进行访
问，涉及所有群集节点。
图8：节点间并行
另一方面，Oracle 在Real Application Clusters 环境中关于节点内和节点间并行进行
智能化决策。在节点内并行中，例如，如果某个SQL 语句要求并行度为6，则负载会在所有节
点上进行平衡，且在本地节点（用户连接到的节点）上有6 个并行处理服务器空闲，SQL 语句
使用本地资源进行处理（图8）。这样消除了跨多节点的查询协调开销。不共享系统必须使用
64 个并行进程执行所有语句以便能够访问所有数据，涉及所有节点，并在所有节点之间进行
继续这个例子：如果在本地节点上仅存在两个并行处理服务器空闲，那么这两个并行处理
服务器和其它节点上的四个并行处理服务器会用于完成SQL 语句；Oracle 使用节点间并行（
图9）。不共享系统仍必须在所有节点上使用全部64 个进程。
图9：节点内并行和节点间并行
Oracle 的并行处理技术能够动态地检测空闲CPU 并从具有较重工作负载的CPU 的执行队
列将工作分配给那些空闲的CPU。这样，Oracle 可以有效地跨系统中所有CPU 重新分发查询工
作负载。Real Application Clusters 通过跨群集的所有节点重新分发工作扩展了对群集的有
多个并发并行操作的群集负载平衡
负载平衡分发并行处理服务器进程以在节点间平均分布CPU 和内存使用。它还最小化通信
和远程I/O。Oracle 通过将服务器分配到运行进程数量最少的节点上来达到此目标。负载平衡
算法保持跨所有节点一个平均的负载。例如，如果在每个节点有一个CPU 的八节点系统上请求
8 个DOP，且此操作必须使用两个从集，则会在每个节点上分配两个PX 服务器。如果整个并
行处理服务器组适合于一个节点，则负载平衡算法会将所有进程置于一个单节点上以避免通信
开销。因此，如果在每个节点有16 个CPU 的双节点群集上发布上面讨论的相同语句，则该算
法会将全部16 个并行处理服务器进程都分配到仅一个节点上。
图10：群集环境中的智能负载平衡
不共享系统声称通过为对象使用智能散列分区策略而具有内建的负载平衡。只要仅处理正
在跨所有节点进行分区的对象，则这可能会实现。然而，对于仅跨一些节点的未分区或已分区
对象，这就不可能实现。对节点的数据亲合性静态地确定数据必须进行处理的位置。
结论
不管您是选择使用SMP、MPP 或是群集系统：Oracle 的可伸缩并行处理框架始终能为您
提供硬件体系结构的最佳吞吐量性能。并行处理的能力仅受到系统（而非数据库）能力的限制
Oracle 的并行处理框架被内建在Oracle9 i 数据库中，且对群集环境和非群集环境进行
了优化。结果，它透明地为任何应用程序提供相同的功能，而不管是在大型SMP 计算机上使用
Oracle，还是在MPP 计算机或松散耦后的群集上使用Oracle Real Application Clusters。
建立在与旧的不共享实现相同的并行高级计算的基础之上，Oracle 远远超出其原先的能
力，提供了市场上最具伸缩性、最灵活和最完整的并行处理体系结构。
| |
|
|
| |
| |
|
