HP平台的asm要求maxfiles_lim参数为32767

最近在客户遇到一个案例，和大家分享一下，大家如果客户那里也有HP平台，那么要注意在11gR2中kernal参数maxfile_lim要设置成32767，而在11gR1以及之前，这个参数是65536的。（在169706.1文档上，11gR1之前是设置65536的，在11gR2上要求参考install guide，而install guide上写的是32767）

故障现象：

加asm磁盘的时候，无法加成功，报错disk is not visiable in cluster-wide，同时伴随报错ora-27070。

其实盘在2个节点上都是能看得到的。

创建test diskgroup的时候，节点1上创建成功，节点2上mount，mount了一会就dismount了，报错ora-27072。

两次报错，在alertlog中都有关于rebalance进程的trace文件，在trace文件中，可以看到关于异步IO的一些报错问题。

初步怀疑和Bug 17264575 : ORA27070 AND HPUXIA64 ERROR: 15 AND DISKGROUP DISMOUNT AFTER ADDING NEW吻合。根据Bug 17264575和Doc ID 1604055.1，虽然研发说要将maxfiles_lim改小到32767。但最后问题总结却说是加大了参数。前后是有矛盾的。

开SR确认是改大还是改小，GCS说无法确认，the only available solution是让我找客户试试。尼玛人家生产系统能随便试么？！

maxfiles_lim是每个process的打开文件句柄数，检查客户当前的打开文件句柄数，他们设置的是65536，实际已经使用率5万多，那么有出现了一个问题，哪怕hit中Bug 17264575，是要求改小到32767，那么我当前已经使用了5万多个打开文件句柄数，那么改小之后，不会有问题吗？是否会有too many open file的报错出现？

进一步分析当前打开文件数的情况，发现打开文件句柄数最多的进程是rebalance进程，其他进程最多就打开4000多个文件，而rebalance进程打开了近5万个文件，其中打开了disk78有4万多个，且disk78不是用在生产diskgroup上的disk，是一个former的disk。

单个进程，打开那么多文件数，且都是同一个文件，根据这个情况，怀疑也是bug，继续查询mos，发现 Bug 18243382 : RBAL PROCESS OPENED TOO MANY FILE DESCRIPTORS ON CANDIDATE ASMDISK。但是这个bug也是基于Bug 17264575，原因也是没有设置正确的maxfiles_lim。客户也是设置了过大的 maxfile_lim，解决方法是缩小maxfiles_lim到32767.

因此我们可以确定是需要缩小maxfile_lim。且缩小后，rebalance进程不会打卡那么多文件数，所有的进程最多只有4000多，不会超过32767，因此不会有too many open files的报错风险。

修改maxfile_lim不用重启，但是连带的参数maxfile需要重启。

另外，修改maxfile_lim也需要重启asm才能是asm的进程获得新的参数。

最后，客户进行了变更，修改参数，减小到32767，重启主机，加盘成功，不再报错。