• “DBA+社群”香港联合发起人；

• 网名@IvanYao，Oracle OCM，RedHat RHCE；

• 十年以上Oracle、Unix/Linux 运维开发经验；

• 拥有包括银行、证券、电信、媒体及政府等行业IT经验；

• 目前供职香港某电信及系统集成商，高级DBA。

这次带来的分享主题是《Oracle Parallel相关参数设置不当引起的系统故障》，是生产环境中遇到的一个真实的案例。

大家都知道在ORACLE OLAP类的系统中，因为涉及到大量的数据操作，让ORACLE提供的Parallel特性成为提高数据处理效率的不二选择。这些特性确实大大地提高了DBA的工作效率，同时也降低了系统运维的难度。只不过在实际环境中往往因为这些参数设置反而给系统运行带来一些问题。

我本次分享的主题包括以下几个部分：

• 系统描述

• 故障表现

• 故障解决

• 故障分析

• 总结

这个是我们维护的一套算是比较老的系统：

操作系统AIX 5.3，Oracle database是10.2.0.3单实例，应用是Oracle Portal。

以下摘抄了一段网络上对Portal的描述：

Oracle Portal是一个建立企业信息门户的集成环境。通过Oracle Portal，企业员工可以很方便地将自己所需要的，来源于各种渠道的信息集成在一个统一的视图之内。例如，在传统企业信息系统环境下，一个财务部门可能要接触这样一些信息源：企业财务软件，企业内部网站的政策、新闻、公告，各种图表、报表，互联网上的财经新闻，股票行情等等；通过Oracle Portal提供的“自助式”的服务，财务部门可以为自己部门量身定制一套财务人员的信息门户，将上述信息有效地组织在Web应用程序之中，并根据不同级别人员的职能设定相应的访问权限。在以前，这可能需要向IT部门提交详细的需求分析，并等待好几个月才能投入使用；通过Oracle Portal提供的快速、易用的开发工具和内建功能模块，非IT人员也可以根据自己的实际业务需求，创建这样的集成化Web应用了。

具体针对我们的系统DBA运维的database来说，这个应用主要功能是出报表，也是我们运维的内容。

午饭的时间，监控部门（SMC Service Management Center）监控工具报警，数据库连接有问题，存在不能应用不能接入的情况，但是业务部门并没有反应。一般来说，如果是业务受到影响，基本上是业务部门第一个发现问题的，而监控工具的探测有一定的时间间隔。当时也没细想，马上进行健康检查。

发现主机上的数据库实例都在还在，被反应有问题的实例也在，instance没有crash。如图所示，是单机多实例（database) 的系统。

尝试登入数据库，多次尝试发现，表现形式如图片显示。比较怪异，时而ora-01012 not logged on，时而显示connected to a idle isntance。

多次尝试，发现居然可以login进入。马上对初始化参数进行检查，生成一个pfile 备查。如图所示，process基本上已经满了。前面的症状和猜想的一样，是process爆了，但是why？新增应用了？原有业务增加了？App team对connect pool进行调整了？

根据alert事发前后的alert日志，发现没有特别的error，仅仅发现m000 creation failed。

tail -f发现redo log file还是可以正常的切换，也就是说至少部分业务还是可以工作的。

电话知会业务部门，业务老大回复，目前正在出表报，不能kill进程更不能重启DB，切记！

这个时候心稍宽，业务老大发话了，说明关键业务还在跑，没受到影响。

我们也不能傻等着，利用这个可以连入的process，继续做一些health check的工作。

database规模大约14T

SGA 80G

…

赶紧做一个AWR report，发现一点异样，“wait for a undo record”，和undo相关的。

检查OS层面的oracle相关的进程，发现ora_pxx的进程非常多。统计了一下，居然260多个，感觉有点异常。如果instance processes上限是800，parallel进程在分出去260，留给普通的user processes就不多了。

感觉怪怪滴。

值得怀疑的问题，跟着检查parallel相关的初始化参数，发现parallel_max_servers居然高达685。也就是说目前的parallel process 26x还是没有吃饱，如果有资源还能再分配给它。

查看相关的parallel的view v$px_process，发现大量ora_pxxx相关的进程的status是available的，从database症状的表现上时 很多parallel相关的processes可能是被用过了，但是目前看，仅仅是占用了process这个进程，但是目前并没有parallel的进程或者说是并行SQL在跑。

等了几分钟再次尝试，发现依然是这个表现。第一反应是，可能之前业务部门跑了个大SQL还是并行的，这样相关的并行资源被占用了。但是，跑完了，这些资源并没有被释放。

参数parallel_max_servers的设定和processes的设定，感觉有点怪异，生产环境跑了n多年了。

我们知道oracle database的process是静态参数，要重启instance。发现这个parallel_max_servers的参数不是静态参数，尝试将它降一些？根据等待的2xx个并行slave进程数，腰斩一下先？

耐心地等了一下，几分钟之后继续检查，发现v$px_process这个view中的并发进程数下来了。从OS层面看，也是类似的结果ora_p开头的进程也降下来了。这个时候检查database process从800降到600多，tail -f alert.log反应instance没有异常，监控部分反应数据库无警告出来。这个参数生效了。

还记得之前之前快速生成的AWR report吗？

到这里只能说是问题得到缓解。

根据问题出现时候的AWR report，为什么产生了大量的Wait for a Undo record？借助MOS和Google找来了一些解释：

In parallel transaction recovery this wait-event is used in a number of places while waiting for some work.

In fast-start parallel rollback, the background process SMON acts as a coordinator and rolls back a set of transactions in parallel using multiple server processes.

Fast start parallel rollback is mainly useful when a system has transactions that run a long time before a commit, especially parallel Inserts, Updates, Deletes operations. When SMON discovers that the amount of recovery work is above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes.

There are cases where parallel transaction recovery is not as fast as serial transaction recovery because the PQ slaves may interfere with each others work by contending for the same resource. With such a transaction rollback performance may be worse in parallel when compared to a serial rollback.

Becasue of this contention and the perceived slowness and 'hang' like symptoms (the database may seem to hang, SMON and parallel query slaves may be seen to take all the available CPU), DBA intervention may be taken. If a large transaction is terminated, the the cleanup may also take time.

我对这段的理解是：很多地方都用到了parallel traction recovery这个wait-event。在fast-start parallel rollback这个动作的时候，background进程SMON充当协调者，并且使用多个服务器进程(multiple server process)并行回滚事务。

fast-start并行回滚主要的运行场景时，当一个系统具有运行很长一段时间之前提交，特别是并行Inserts,Updates, Deletes操作。当SMON发现大量的恢复工作的量高于特定阈值时，它自动由在几个并行进程分散工作开始并行回滚。

有些情况下并行事务恢复速度比不上串行事务恢复，因为PQ slave进程可能会因为争用相同的资源而彼此互相影响。这样的话并行回滚的性能反而会越来越恶化。

从症状看，类似hang,（数据库可能看起来挂起，SMON和PQ slaves 使用了所有可用的CPU资源），这个时候DBA可以干预。但是如果一个大的交易被终止，清理也可能需要一段时间。

有点match。

根据MOS Docs对比，该database的初始化参数fast_start_parallel_rollback确实类似 文中描述 。

上图是官方文档的描述。

看样子，之前是为了加快回滚改动过这个参数。咱也别太激进了，将FAST_START_PARALLEL_ROLLBACK设定为Low。

回头再次检查alert日志，发现在故障出现前有一个session被kill了。

到目前为止，故障出现大体清楚了，业务部门发现一个长时间运行的SQL运行异常, 就kill了， 从而触发了并行rollback的动作，导致很多资源被占用掉了，从而引起监控的报警，但是在跑的业务并没有收到影响。

可为什么这个parallel的参数设置这么大呢？

前面提到了，PARALLEL_MAX_SERVERS设置为685，而在事发的时候，create pfile from spfile中没有关于这个参数的显式的设定，那就是说这个参数是使用的default值，或者说是oracle自己根据软硬件条件自己设定的。

根据oracle 10gr2官方文档描述：

ARALLEL_MAX_SEVERS参数设置并行执行可用的最大进程数量，该参数的缺省值如下得出：

1、当PGA_AGGREGATE_TARGET >0时

PARALLEL_MAX_SERVERS= (CPU_COUNT x PARALLEL_THREADS_PER_CPU x 2 x 5)

2、当PARALLEL_MAX_SERVERS未设置

PARALLEL_MAX_SERVERS=(CPU_COUNT x PARALLEL_THREADS_PER_CPU x 5)

根据oracle给出的公式：

PARALLEL_MAX_SERVERS= (CPU_COUNT x PARALLEL_THREADS_PER_CPU x 2 x 5)

PARALLEL_MAX_SERVERS= (50 x 2 x 2 x 5)＝1000

而实际的这个参数值时685，这个没有细研究，可能这个default的设定还受到其他参数的影响。这个问题先放下慢慢琢磨。

这个问题是9月下旬发生的，经过差不多一个多月的运行，DB运行正常，再无类似的问题出现。

对于使用到PARALLEL相关参数的系统，系统自动计算的参数未必是满足企业特定业务的要求。如果对业务有充分的了解，可以先行下手，主动对相关参数进行调优，根据业务应用场景再做进一步的调整。

扫码关注

DBAplus社群

来自各领域的牛逼DBA正在向我们汇聚