从概念上看，可以认为纯不共享系统与分布式数据库非常相似。为了在某个节点上执行要求的读/写操作，该节点上的事务必须将消息发送给拥有需要被访问的数据的其它节点，并协调在其它节点上完成的工作。将消息传递给其它节点，在它们拥有的数据集上请求执行特定操作(功能)称为功能传送。另一方面，如果从远程节点请求简单数据，则必须访问完整的数据集并将它从拥有节点返回至请求节点(数据传送)。

在不共享体系结构下的并行处理像分布式数据库一样运作。每个节点以独占方式拥有其数据分区。没有其它任何节点可以访问此数据，而使节点成为单一的访问点和故障点

此方法具有一些基本缺点，无法解决今天高端环境对可伸缩性和高可用性要求:

(1)、首先，不共享方法在用于共享一切的SMP硬件时并不是最佳的。为了获得并行处理的益处而要求对数据进行物理分区，在共享一切的SMP系统中很明显是一种人工的、过时的要求。因为在SMP系统中每个处理器都可以对所有数据进行直接的、等同的访问。

(2)、其次，在不共享方法中使用严格的基于分区的并行处理策略，通常会导致不正常的资源利用。例如以下两种情况：在没有必要访问表的所有分区时;或当单一节点所拥有的更大的未分区表是操作的一部分时。在这些情况下，限制分区内并行处理的紧密所有权模式，无法利用所有可用的处理能力，因而不能提供最佳的处理能力使用方案。

(3)、第三，由于具有对节点对应物理数据分区的关系，不共享系统在适应变化的业务需求方面一点都不灵活。当业务增长时，无法方便地以增量方式扩充系统来适应增长的业务需求。可以升级所有现有的节点，保持它们对称并避免数据重新分区。在大多数情形下，升级所有节点费用太高;必须添加新节点并重组(进行物理重新分区)现有数据库。一个不需要进行任何重组的方案总是比必须重组的方案要更好，即使可以利用到最复杂的重组工具。

(4)、最后，由于使用严格的受限制的访问模式，不共享系统无法完全利用群集系统为保证系统高可靠性所提供的潜在的容错能力。

毫无疑问，基于使用静态数据分布的不共享体系结构，大量的并行处理可以在实验室条件下并行化和扩展。然而，在每个现实环境中，必须正确地解决上面谈到的问题才能满足今天高端关键任务要求。

Oracle数据库并行处理技术之执行时的动态并行——共享一切

使用Oracle 的动态并行处理框架，可以共享所有数据。并行化和将工作分成更小的单元的决策，并不受限于数据库设置(创建)时所做的任何预先确定的静态数据分布。

由于能够为每个语句构造不受限制的、优化的数据子集，执行时动态并行可以提供与不共享体系结构等同的或甚至更好的可伸缩性。

每个查询在访问、连接和处理数据的不同部分时都有它自己的特征。因此，每个SQL语句在被解析时都要进行优化和并行化处理。数据更改时，如果有更加优化的并行执行计划可用，或者系统中新添加了一个节点，那么Oracle可以自动适应新的情况。这样可为并行化任何种类的操作提供最高程度的灵活性：

(1)、在语句执行前，对于每个查询要求，会动态地优化并行访问的物理数据子集。

(2)、对于每个查询，都会优化其并行度。与不共享环境不同，不存在必需的最小并行度来调用所有节点访问所有数据，这是访问所有数据的基础要求。

(3)、操作可以根据当前工作负载、特征和查询的重要性，使用一个、一些或全部Real Application Cluster 节点并行运行。

只要语句得到优化和并行化，就可以知道所有后续的并行子任务。原始进程变为查询协调器;并行处理服务器(PX 服务器)从一个或多个节点上的并行处理服务器的公用缓冲池得到分配，并开始并行执行该操作。

与不共享体系结构相似，共享一切体系结构中的每个并行处理服务器在其个人数据子集上独立工作。数据或功能在并行进程之间的传送机制也与上述的不共享体系结构相似或者相同。确定请求的并行计划之后，每个并行处理服务器都知道其数据集和任务，而进程间通信就像在不共享环境中一样很少。