还是继上次说说并行parallel，首先并行原理是：oracle创建一个进程用于协调并行服务进程之间的信息和任务分配，把一个任务分割成很多小任务分配给并行服务进程，并行进程同时处理各自分配任务，直到任务全部结束，最后协调进程负责将各进程任务合并为最终执行结果返回给用户。

并行在OLAP用的比较多，OLAP系统表一般为大表，OLTP上的表很多都以索引访问为主，不过一切都要看实际业务情况，一般如果有多cpu，操作的对象很大开启并行是可以明显提高效率的。

一个查询的parallel

Alter table tt01 parallel 2;

SQL> select count(*) from tt01 order by object_id;

COUNT(*)

----------

48545

执行计划

----------------------------------------------------------

Plan hash value: 1845497878

--------------------------------------------------------------------------------

--------------------------------

| Id | Operation Cost (%CPU) Bytes

SELECT STATEMENT, GOAL = ALL_ROWS 90 48545 4514685

PX COORDINATOR

PX SEND QC (ORDER) SYS :TQ10001 90 48545 4514685

SORT ORDER BY 90 48545 4514685

PX RECEIVE 86 48545 4514685

PX SEND RANGE SYS :TQ10000 86 48545 4514685

PX BLOCK ITERATOR 86 48545 4514685

TABLE ACCESS FULL ASHUANG TT01 86 48545 4514685

下面的执行计划摘自一位网友的blog（哎，英文不好）

（1）并行服务进程对tt01表进行全表扫描。

（2）并行服务进程以ITERATOR（迭代）方式访问数据块，也就是并行协调进程分给每个并行服务进程一个数据片，在这个数据片上，并行服务进程顺序地访问每个数据块（Iterator），所有的并行服务进程将扫描的数据块传给另一组并行服务进程（父进程）用于做Hash Group操作。

（3）并行服务父进程对子进程传递过来的数据做Hash Group操作。

（4）并行服务进程（子进程）将处理完的数据发送出去。

（5）并行服务进程（父进程）接收到处理过的数据。

（6）合并处理过的数据，按照随即的顺序发给并行协调进程（QC：Query Conordinator）。

（7）并行协调进程将处理结果发给用户。

Alter table tt01 parallel 2开启了两个并行度

select count(*) from tt01 order by object_id;

此时在执行并行查询前在v$session视图中可以比较一下

select * from v$session where username=’ASHUANG’ and status=’ACTIVE’发现执行后多了两个session 不过某种情况可能出现4个并行进程，查看资料发现存在父进程和子进程概念，有时候需要对sql进行额外的处理比如排序等，并行协调进程又会调用n个并行服务进程（父进程）用于处理刚开始分配n的进程处理（子进程）的数据，而并行服务进程之间数据交流叫做交互操作，单个并行服务之间叫做并行的内部操作。所以有时候并行服务进程是并行度的两倍。

并行执行等待事件：

在做并行执行时也会遇到所谓的等待事件：PX Deq Credit：send blkd,查看v$session_wait等视图或者statspack awr报表可以看到。

PX Deq Credit：send blkd等待事件缘由：

当并行服务进程向并行协调进程QC（也可能是上一层的并行服务进程）发送消息时，同一时间只有一个并行服务进程可以向上层进程发送消息，这时候如果有其他的并行服务进程也要发送消息，就只能等待了。 知道获得一个发送消息的信用信息（Credit），这时候会触发这个等待事件，这个等待事件的超时时间为2秒钟。而对于事件的处理就是适当降低并行度！

上面展示了一个并行查询（不过不能使用于dblink），同样并行dml和并行ddl都是可以的。

并行ddl

Create table tt parallel 2 as select * from dba_objects

Alter table tt parallel 2

Create index index_tt on tt(object_id) parallel 2

….

如果想查看具体的并行执行时可以去查看udump下的trace文件，而使用tkprof工具则可以很清楚的查看这个过程

Alter session set events ‘10046 trace name context forever,level 12’;

Create table tt parallel 2 as select * from dba_objects

Alter session set events ‘10046 trace name context off’;

设置10046跟踪sql然后tkprof查看trace

索引 表的并行等都是并行协调进程创建并行进程让其任务分配给各进程然后集合处理汇总。

并行dml

需要在使用并行的session级别设置一下alter session enable parallel dml

SQL> insert /*+parallel(tt02 2)*/ into tt02 select * from v$sysstat;

已创建347行。

执行计划

----------------------------------------------------------

ERROR:

ORA-12838: 无法在并行模式下修改之后读/修改对象

SP2-0612: 生成 AUTOTRACE EXPLAIN 报告时出错

貌似出现了一个错误，把所有的session都提交了，暂时还没理清为什么！

并行执行的几个参数：

parallel_min_servers：数据库启动时预先分配的并行进程数

parallel_max_servers: 数据库的最大分配的并行进程数

parallel_adaptive_multi_user=true|false: 10G R2默认是true 能根据sql执行时系统的负载情况动态调整sql并行度。

Parallel_min_percent：申请并行服务进程的百分比，例如我们申请一个20的进程，而系统此时进程无法满足，会按照这个参数20*parallel_min_percent个并行进程，如果还是无法满足则报错ora-12827

默认的并行度的计算跟cpu个数，rac实例和parallel_threads_per_cpu有关，而对于分区表一般采用分区数的并发进程处理，但是也并不是任何情况都并行，一般在服务进程资料充足

，硬件和实际业务情况同时考虑下采取并行，不然可能会适得其反，比如单cpu。

[@more@]