动态增加CPU带来的数据库重启风险--技术人生系列第四十六期-我和数据中心的故事

周六，正是某个客户的投产日，投产时间为晚间19:30开始，持续到翌日早上九点，老K负责现场支持任务。

投产系统多，七点半刚过，各种咨询接踵而至，老K正忙的不亦乐乎，电话过来了：“老K，快来这边帮帮忙看下，应用维护团队说投产动作比较慢，看看有没有什么办法加快下速度？”类似的电话接了不少，问题总要一个一个处理，但是刚刚电话涉及的系统还是比较重要的系统，投产窗口有限，肯定是需要更重视一些，于是答应处理完手边的这个问题紧接着下一个去看看这个系统；

但是，几分钟后电话再次响起：“老K，不好了，这个系统数据库重启了！快来看看吧！”


这就尴尬了，难道是因为我没有及时响应他们的问题，系统就撑不住重启了？如果真是这样，那这罪过可就大了！赶紧去到事故现场来处理这个问题。

问题现场，各路同事都在讨论着这事。


这个


系统是一套两节点的


RAC


数据库，数据库版本为


11g


，这次重启实际上是数据库两个节点的实例都发生了重启；

首先看看

alert

日志里有没有什么信息显示：

很显然，数据库在

19:41

时被

ASMB

进程给终止了，在终止前产生了一些

trace

文件；

ASMB

进程是什么进程呢？顾名思义，

ASMB

进程就是数据库实例与

ASM

实例进行交互的进程，从这里的报错也可以到，

ASMB

已经无法连接到

ASM

实例了；

一般来说，出现这种情况，通常的可能是

CRS

发生了重启，然后这里我们通过

ps –ef

查看

CRS

关键进程发现并未发生过重启；这样看来与

ASM

有关；于是我们再看

ASM

的

alert

日志，关键部分如下



：

可以看到

ASM

实例发生了重启，而重启的原因则是：

参数

parallel_max_servers

被设置为

4505

，而这个参数值是不合法的，该值的设定范围应该是


到

3600

之间；在发现了这个错误后

CKPT

进程终止了

ASM

实例。

似乎问题就很简单了，


parallel_max_servers



被置为

4505



，

ASM



实例终止，进而导致

DB



实例终止



。

那么，这里我们就需要搞清楚几个问题：

对于这种硬性设定，我们不妨先查一下官方手册，查看该参数是否有上限值：

可以看到，该值设定的上限就是

3600

；

正常情况下，如果我们在数据库中的

修改

参数，


修改失败直接抛错即可，显然并不会导致数据库实例的重启；

而这里发生的重启，我们可以看到导致重启的进程是

CKPT

进程：

我们可以认为，


CKPT


进程是数据库实例的关键进程，当它遇到错误时，它直接终止了整个实例；

通常来说，修改（调大）parallel_max_servers参数的目的是允许系统启动更多的并行进程；而对于ASM实例来说，修改这个参数本身似乎并没有太大的意义，毕竟ASM实例都不会open，基本只服务于Database（可能还有一些监控/管理类的语句）；那么谁会来修改ASM实例上的参数呢？难道是应急的时候错把ASM实例当做Database了？

看到这里，不妨思考一下？原因其实很简单

…..

我们在来看看ASM的日志，相关的信息值得思考：

我们可以看到，在参数调整之前，日志中实例发现了CPU count变成了228，紧接着系统就调整了parallel_max_servers值的大小，随后报错宕实例；

这里我们首先需要确认，CPU数的调整会引起parallel_max_servers参数的调整吗？我们再来看看这个参数的相关属性，其默认值确实就是与CPU_COUNT有关的，而且参数本身就是可以动态调整的；

很显然，这里Oracle的代码中似乎在系统调整CPU进而导致parallel_max_servers参数的动态调整时，忘记了该考虑parallel_max_servers还有一个3600的上限，这应该定义为一个bug；我们上MOS核查也很快能找到这个bug：

问题发生在11.2.0.2和11.2.0.3的版本上，在11.2.0.4版本上已经修复；

看着问题是得到了圆满的分析，然而还有不少疑惑萦绕在我的心头，也是客户所关注的，所以这里先来解答这些问题；

1.



为什么

Database



实例没有因为

parallel_max_servers



的参数调整而直接重启呢？

这里我们可以再回过头来看

database instance

的

alert

日志信息



：

同样也看到了

CPUcount

的变化，调整到了

228

；但是并没有出现

parallel_max_servers

参数的动态调整，其实这里主要的原因是，在

Database

实例中，我们已经在参数文件中指定了

parallel_max_servers

参数的大小了，在指定了参数的情况下，系统不再根据

CPU

数动态调整

parallel_max_servers

参数的大小；

2.



为什么

ASM



实例启动时，没有再因为该参数而无法启动？

在

ASM

再次重启的时候是怎么计算

parallel_max_servers

参数值的呢？实际上我们搜索

asm

的

alert

日志发现启动实例是并没有设定

parallel_max_servers

参数；而我们手动设定

asm

的

parallel_max_servers

参数值也会报错：

我们发现，在

ASM

实例中压根就无法设置这个

parallel_max_servers

参数，哪怕是设定到

spfile

中也不允许；实际上在启动时不计算、不检查这个参数也就合乎情理了；

3.



刚刚调整上去的

CPU



我再调回来还会宕机吗？

我们从原理上看，这里数据库并不关心

CPU count

是变大还是变小，一次是变十个还是变一个，它都会重新来计算

parallel_max_servers

参数的值，那么显然，这里如果再次调整

CPU count

，如果不是将

CPU count

调整到足够小，那么再次调整只要调整后的

CPU count

数计算

parallel_max_servers

参数的值大于

3600

，问题将再次出现



！

4.



如何预防这样的问题呢？

已经知道了这是

bug

，那么对应的打上相应的补丁一定是根本的解决之道；

而数据中心

11.2.0.3

版本的系统还非常多，而动态调整

CPU

也是常见动作，统一安装补丁也需要时间，同时还需要考虑时间窗口，肯定需要一定的周期；那么在此之前我们是否还有临时的预防之策呢？

根据

bug

文档描述的

workaround

是手动指定

parallel_max_servers

参数为小于

3600

的值，不过我们上面的核查能很明白的看到，

ASM

实例无法调整该参数，看来官方文档没有考虑

ASM

实例的情况，也有纰漏，那么我们该怎么办呢



？

该如何是好呢？如果是你，你会考虑一些什么来规避这类问题呢？

要从根本上来回答上面的这些问题，其实需要了解数据库到底是如何计算

parallel_max_servers

参数的；实际上我们可以看看如下描述：

从上述描述我们可以看到影响参数的若干变量，包括：

PARALLEL_THREADS_PER_CPU


：该参数基于操作系统，通常是

2；

CPU_COUNT


：该参数基于数据库的实际

CPU

数，但是可以调整；

concurrent_parallel_users


：该参数基于实例的内存管理模式配置，默认系数为

1/2/4

不等；

PROCESSES



：该参数值来实例启动时的


PROCESSES


参数；

可以看到，

parallel_max_servers

的参数值通过两方面的计算取

min

值，也就是取自

min(parallel_threads_per_cpu*cpu_count*concurrent_parallel_users * 5,processes-15)

；这两个方面来看，其中一部分确实与

CPU

有关，而另一方面似乎只与

processes

有关，我们再查

11.2

的

references：

processes

参数的值默认是

100

；如果没有人调整过

ASM

实例的

process

参数的值的话，那么这里计算

parallel_max_servers

的值应该是

min(

PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5,100-15

)

，




这里即使前面计算的值再大，这里计算出来的值也只应该是



85


而已



，也就远不会超过

3600

；

 难道

真的是又有谁修改了


ASM


实例的


PROCESSES


参数值吗？还是官方的


reference


是错误的呢？如果是你，你会怎么进一步核查这个参数呢？

遇到这样的情况，我们首先检查并没有发现两个节点

alert

日志存在修改记录；那么难道

reference

真的有误？事实上我们看的是

11.2

的

reference

，当前的

11.2.0.3

版本发布时间在

reference

之后很久，我们不妨再通过

MOS

核查确认

processes

值默认值的计算方法：

在

MOS

文档

“

升级到

11.2.0.3/11.2.04 Grid/ASM

所需要知道的事

”

中指出，

ASM

的

processes

参数的默认值计算是“


available CPU cores * 80 + 40


”，当然，这里

processes

参数不会随着

CPU

数动态改变，只会在实例启动时计算；

我们截取之前时段

AWR

报告中拿到的

CPU cores

数



：

那么这里，

parallel_max_servers

的值计算就是：

min(PARALLEL_THREADS_PER_CPU*CPU_COUNT*concurrent_parallel_users*5,last_CPU_cores*80+40-15)

代入实际值即为：

min

（

2*228*4*5, 56*80+40-15

）即

如无必要，我们在没有充足理由调整系统CPU/内存的时候，不要轻易调整系统资源


；