经过第一篇文章《Oracle 中的并行系列（一）》的介绍，我们对Oracle中的并行有了大致的了解。但是实际使用并行的过程中我们可能会遇到很多问题，比如可能还会遇到数据倾斜 、并行降级、并行失效、分发方式不合理、BUFFER SORT、HASH JOIN BUFFERED阻塞等情况。今天我们介绍其中一个大家很关心的问题：你设置的并行真的生效了吗？
要测试判断并行是否存在问题，我们一般会使用如下排查思路流程：
-
操作系统硬件资源使用情况。
-
数据库负载信息：活动会话，并行参数设置限制等
-
跟踪监控并行SQL。
-
尝试解决方案再次执行查看并行服务进程使用情况。
模拟问题：数据库中执行简单8个并行查询语句，观察并行是否存在问题。sql_text: select /*+ parallel(8)*/count(*) from test;
1.操作系统硬件资源
执行并行查询语句的时候，关注系统硬件资源的使用情况。如下示例图可知该测试环境有72颗逻辑cpu，并且开启并行查询后cpu使用率在1-2%之间，磁盘的读吞吐大概为3G左右。简单判断系统硬件资源不存在瓶颈，根据经验初步判断并行应该是生效了，因为磁盘吞吐较高，未开并行一般吞吐在几十兆到1G不等（具体视sql语句复杂度和存储类型）。
2.数据库并行参数配置
在初步确认系统硬件资源充足的情况下，确认数据库并行参数是否做过修改存在限制。
-
cpu_count为72，默认情况下等于操作系统cpu数量。
-
parallel_max_servers为1970，一个实例分配并行执行进程和并行恢复进程的最大数量。受参数（CPU_COUNT, PARALLEL_THREADS_PER_CPU, PGA_AGGREGATE_TARGET）影响，具体可以参数文章(Doc ID 1968840.1)。
-
parallel_min_percent默认为0，并行执行需要并行执行进程数的最小百分比。
-
parallel_min_servers默认为0，实例启动时oracle 常见的初始并行进程数量。
-
parallel_servers_targets为1152，一旦系统上活的并行服务器进程数等于PARALLEL_SERVERS_TARGETS，并行语句将开始排队。
-
parallel_threads_per_cpu默认为2，参数描述并行执行期间每个CPU能处理的并行执行进程或线程数。
3.跟踪监控SQL执行
跟踪SQL执行计划，如示例图3.1展示结果：Note Degree of Parallelism is 8 because of hint。执行计划显示该测试语句因为使用了hint，语句执行并行度为8。需要注意的是虽然这里显示了并行度为8，但是真正使用多少并行需要使用其他手段监控，一般我们会使用sql monitor来确定。如示例图3.2和图3.3展示结果：Parallel Execution Details（DOP=4，Servers Requested=8，Servers Allocated=4）。测试语句希望请求8个并行进程但是实际上只申请到了4个并行进程。我们通过查询视图v$px_process_sysstat和v$pq_sysstat也同样可以发现只申请了4个并行进程。
Tip：对于生产环境，一些DML语句我们不能随意执行语句进行测试。这个时候可以根据sql_id使用v$sql或者dba_hist_sqlstat视图进行并行进程使用情况的查看。
4.定位问题原因
根据前面的查询步骤我们已经发现了问题：sql的并行出现了降级（8>4）。这时我们需要更细粒度的日志监控判断问题原因，sql monitor可能也无法帮助我们定位问题根源。Oracle从9i之后提供了非常强大的跟踪工具，我们可以通过会话中设置“_px_trace”参数完成对并行语句的更细粒度的跟踪。由于本环境为测试环境并且压力负载较小所以使用"_px_trace"=high,all高粒度trace日志打印。根据示例图4.1可以非常清晰的看到以下流程：kxfrcomputerThread request 8 threads>kxfrADjustDOP no,threads 8>kxfrAllocSlaves request 8 threads>kxfpgsg call 8>kxfpiinfo mxslv:1970,inst target:1152(资源充足)>KxFpAdaptDOP Resource Manager reduced num server to maxdop=4。问题非常明显数据库使用Resource Manager导致并行出现了降级。
Tip：并行trace使用参考详细可以参考文章(Doc ID 444164.1)：
alter session set "_px_trace"=[[Verbosity,]area],[[Verbosity,]area],..,[time];
alter session set "_px_trace"=high/medium/low,scheduling/granule/messaging/buffer/compilation/all/none,time;
-
scheduling - ( equivalent to some of event 10384 and some of 10390)
-
execution - (equivalent to some of event 10390)
-
granule - (equivalent to some of event 10390 and some of 10391)
-
messaging - (equivalent to event 10392 and event 10393)
-
buffer - (equivalent to event 10399)
-
compilation - ( no equivalent event)
-
all - all of the above
-
none - none of the above.
5.验证解决并行降级问题
根据第四部分的trace信息可以定位为Resource Manager引起了并行降级问题。查询当前会话确实有名为CITY_GROUP的资源限制存在，根据示例图5.2显示列PARALLEL_DEGREE_LIMIT_P1并行为4。Resource Manager并行度进行了限制统一为4。解决Resource Manager的问题后再次进行测试。使用sql monitor判断如示例图5.3展示结果：Parallel Execution Details（DOP=8，Servers Allocated=8），并行恢复正常。
一般情况下我们可以通过上述分析流程判断我们的并行是否真的生效或者降级的问题。sql monitor工具和v$px_process_sysstat等视图可以给我们展示语句真正使用的并行度。但是当我们发现并行存在问题的时候，我们可能需要更细粒度的_px_trace工具产生trace日志进行跟踪分析。
| 作者简介
刘金龙·沃趣科技高级数据库技术专家
精通Oracle内部体系结构原理，擅长Oracle数据库性能调优、故障分析、定位以及解决，是国内最先接触并成功搭建测试12c R2 sharding 的DBA之一。