数据库管理-第115期 too many open files（202301107）

数据库管理-第115期 too many open files（202301107）

这是我上周末帮朋友站台过程中处理的一个问题。

1 背景

其实这是别人搭的一个使用CentOS 7.8系统安装的一套11.2.0.4（无补丁）的双节点RAC，用于迁移以前运行在Solaris小机上的同版本数据库，当然这个迁移操作也不是我来做，我只是在迁移完成后看看数据库有没有啥问题。其实之前就帮忙过一次，把AMM从64G改到了200G（也不晓得256G的机器开那么低内存干啥）。这盘最大的问题其实是迁移过程中parallel没开，并行度就1，到了统计信息更新的时候就非常的慢（object有丢丢多），而且只剩下了统计信息和JOB（JOB也就几个）了，因此就尝试改了parallel并重启导入进程，结果挂了报了以下的错：

ORA-39097: Data Pump job encountered unexpected error -xxxx
ORA-39065: unexpected master process exception in DISPATCH
...
1
2
3

经过基本检查应该是dump相关组件出现了一些问题，因此就运行了下面的脚本进行处理：

@?/rdbms/admin/catmeta.sql
@?/rdbms/admin/catmet2.sql
@?/rdbms/admin/utlrp.sql
1
2
3

在执行完最后脚本后，发现集群数据库挂了，同时有一个节点都重启。检查告警日志就是一大把的：

too many open files
1

2 处理过程

首先统计信息和剩下的JOB就想着手工迁移了，但是得先处理跑utlrp.sql的问题，这个脚本是处理数据库的失效对象，会调用比较多的CPU线程，虽然CPU占用率不会上去，但是对操作系统压力也不小。数据库因为too many open files的问题造成关键进程挂掉引起数据库挂掉，crs进程也因为这个原因挂掉而重启操作系统。
经过多次尝试问题依旧，因此重新检查了sysctl.conf和limit.conf。首先grid和oracle的nofile限制soft是1024，hard是65535，就一般情况来说是足够的；而kernel.shmmax对应则大概是40G左右。查了一些相关资料做了一些调整：

/etc/sysctl.conf
kernel.shmmax=225485783040（210G，大于AMM配置的200G）

/etc/security/limit.conf
oracle soft nofile 10240
oracle hard nofile 131070
grid soft nofile 10240
grid hard nofile 131070
1
2
3
4
5
6
7
8

完成后为避免异常，分节点重启了整个集群，然后再尝试执行utlrp.sql，多次尝试后没有再出现问题。同时utlrp.sql脚本的执行速度也比之前快。

3 怀疑

首先，就一般Oracle安装配置来说，是足够的，遇到too many open files的问题，结合没有打任何补丁，CentOS 7上11g的支持可能也不是太好，姑且当是一个bug吧。以后遇到装数据库，nofile还是都弄到400000（一体机是这么配置的），shmmax都整到内存80%以上。

总结

老规矩，知道写了些啥。