Oracle 8i引入的并行执行并不是简单地把一个查询同时发给多个用户，而是通过协调进程将SQL拆分为多个可以独立运行的子任务，再由一组并行服务进程同时处理。对于全表扫描、大结果集排序、多表哈希连接以及大数据量聚合操作，这种机制能把原本由单个服务进程串行完成的I/O和CPU工作分摊到多个进程上，显著降低响应时间。并行执行在数据仓库、报表库和批量加工场景中尤其有效，但在高并发OLTP环境里反而可能带来额外的进程切换和资源争用。

理解并行执行要先分清三种主要类型：并行查询、并行DML和并行DDL。并行查询只涉及SELECT语句，Oracle会把表或索引的数据块范围划分成多个颗粒，每个并行服务进程扫描自己负责的那部分数据，协调进程最后汇总结果。并行DML则允许INSERT、UPDATE、DELETE操作使用多个并行服务进程，但默认情况下会话并不开启并行DML，需要显式执行ALTER SESSION ENABLE PARALLEL DML，否则即使SQL中带了PARALLEL提示也不会真正并行写数据。并行DDL常用于CREATE TABLE AS SELECT、CREATE INDEX和ALTER INDEX REBUILD等操作，这类语句在维护大表或重建大索引时能节省大量时间。

并行执行的应用场景和底层工作方式

并行查询适合扫描大量数据的场景，但并非所有SQL都适合走并行。Oracle 8i的并行执行机制依赖协调进程和并行服务进程。协调进程负责解析SQL、生成执行计划、分配颗粒并汇总结果。多个并行服务进程同时执行扫描、排序、哈希连接等操作。当一个并行服务进程因为I/O等待时，其他进程可以继续占用CPU，从而提高整体吞吐量。这种机制对CPU核数多、存储带宽充足的服务器效果更好，如果硬件本身只有两三个核，强行开启高并行度只会增加调度负担。

并行执行在分区表上效果更明显。8i支持范围分区和哈希分区，并行扫描可以按分区边界或数据块范围分配颗粒。对于未分区表，Oracle会把表分成若干连续数据块范围。并行度越高，颗粒划分越细，但协调进程需要合并的结果集也越大。例如一个32GB的表设置并行度为8，每个并行服务进程大约扫描4GB数据；如果并行度提升到32，每个进程只扫描1GB，但协调进程需要等待32个进程全部完成，并且需要合并更多中间结果。因此并行度不是越大越好，要根据表的实际大小和I/O能力来定。

并行DML和并行DDL有一些限制需要特别留意。并行DML不能用于索引组织表，也不能在表上有某些行级触发器或外键约束时使用。同时，同一事务中不能对并行DML修改过的表立即执行查询，必须先提交。并行DDL中CREATE TABLE AS SELECT和CREATE INDEX最常用，但要注意索引创建时生成的排序段可能占用大量临时空间。如果临时表空间不足，语句会报ORA-01652错误，所以在执行大规模并行DDL之前，应该先检查临时表空间的可用空间。

配置Oracle 8i并行执行的几种途径

初始化参数决定并行服务进程的总量。parallel_max_servers指定实例中同时运行的并行服务进程上限，如果设置为0则禁用并行执行。parallel_min_servers用于预启动一定数量的空闲并行服务进程，减少首次请求时的启动开销。parallel_automatic_tuning在8i中可以开启，让Oracle自动调整并行度以及其他相关内存参数。例如下面的语句可以查看并设置这些参数。

-- 查看并行相关参数
SHOW PARAMETER parallel;
-- 设置最大并行服务进程数
ALTER SYSTEM SET parallel_max_servers = 64 SCOPE=BOTH;
-- 设置最小并行服务进程数
ALTER SYSTEM SET parallel_min_servers = 8 SCOPE=BOTH;
-- 开启并行自动调优（8i参数）
ALTER SYSTEM SET parallel_automatic_tuning = TRUE SCOPE=BOTH;

表和索引属性中的PARALLEL子句可以固定默认并行度，用户执行查询时如果未加提示，优化器会参考表或索引的并行度。创建表时可以指定DEGREE，也可以用ALTER TABLE调整。如果不想让某个表走并行，可以设置NOPARALLEL。下面的示例展示了如何创建并修改带并行属性的表和索引。

-- 创建表时指定并行度
CREATE TABLE sales_par
PARALLEL (DEGREE 4)
AS SELECT * FROM sales;
-- 修改已有表的并行度
ALTER TABLE sales PARALLEL (DEGREE 8);
-- 创建索引时指定并行度
CREATE INDEX idx_sales_cust ON sales_par(cust_id)
PARALLEL (DEGREE 4);
-- 重建索引时指定并行度
ALTER INDEX idx_sales_cust REBUILD PARALLEL (DEGREE 8);

SQL级提示优先级最高，可以覆盖表属性。使用/*+ PARALLEL(表名或别名, DOP) */为单表指定并行度，/*+ PARALLEL_INDEX */用于索引扫描。并行DML必须同时满足两个条件：会话执行ALTER SESSION ENABLE PARALLEL DML，并且DML语句中带PARALLEL提示或表设置为并行。下面给出一个并行查询和并行插入的示例。

-- 对单表并行扫描
SELECT /*+ PARALLEL(sales, 4) */
       cust_id, SUM(amount)
FROM sales
GROUP BY cust_id;
-- 并行DML需要先开启会话级开关
ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+ PARALLEL(sales_arc, 4) */
INTO sales_arc
SELECT /*+ PARALLEL(sales, 4) */ * FROM sales;

并行执行监控与常见性能陷阱

监控并行执行需要关注V$PX_SESSION等动态性能视图。V$PX_SESSION显示所有并行服务进程的会话信息，包括协调进程SID、请求的并行度和实际获得的并行度。如果实际并行度低于请求值，说明并行服务进程不足，需要增加parallel_max_servers。还可以通过V$PX_SESSTAT查看并行会话的统计信息，通过V$SORT_SEGMENT查看临时段的分配情况。下面是一组常用的监控SQL。

-- 查看当前并行服务进程的状态
SELECT sid, serial#, qcsid, degree, req_degree
FROM V$PX_SESSION;
-- 查看并行会话的统计信息
SELECT * FROM V$PX_SESSTAT;
-- 查看已分配的临时段
SELECT tablespace_name, total_blocks, used_blocks
FROM V$SORT_SEGMENT;

并行度设置过高是常见的性能陷阱。例如表只有几百MB，却设置并行度为32，启动32个并行服务进程带来的上下文切换和通信开销可能远大于并行扫描节省的时间。并行执行还会消耗大量临时表空间，所有并行排序操作都会在临时段中写入中间结果，如果临时表空间不足，语句会报ORA-01652错误。因此，在设置并行度之前，应该先评估表的大小、SQL的复杂程度以及实例当前的并行服务进程使用情况。

另一个容易忽视的问题是并行执行与OLTP的冲突。并行查询会抢占大量CPU和I/O资源，可能导致在线交易出现明显延迟。对于OLTP系统，建议只对少数报表查询使用并行，或者通过Resource Manager限制并行度。在8i中可以通过调整parallel_max_servers和设置表级并行度来控制资源使用，而不是所有表都开放并行。实际生产环境中，通常的做法是白天关闭或限制并行，晚上批量任务期间再开启较高的并行度，这样既能利用并行优势，又不会影响在线业务的稳定性。