OracleBlog.cn -天堂向左 DBA向右

一天，在一个业务高峰期，某省的一个数据库突然宕机了，根据alertlog中发现的报错：

看来是打开文件数太多，导致了此次数据库宕机。

通过监控打开文件数发现，其实在前一天的时候，打开文件数已经到98%，在上午8点多的时候，打开文件数已经到99%，但是一直都没有引起监控人员的注意，终于导致打开文件数被撑爆。

我们通过sar -v可以发现打开文件数的总数：

其中的file-sz就是指打开文件数。其中20多万的那个值是打开文件数的阈值，前者是当前实际打开的文件数。这阈值是有核心参数nfile决定的。我们在设置nfile的时候，建议是(15 * NPROC + 2048)；提醒值是oracle的process数乘以datafile数再加2048；极限值，在存数据库环境应该是os的极限进程数乘以数据文件数，即每个进程都打开所有的数据文件。

根据计算，如果根据建议值，那么nfile将设置成63488，如果根提醒值，将有141万，如果根据极限值，将有386万：

对于设置6万，肯定是完全不适合我们这个系统；如果设置141万或者设置386万，这似乎又太大了。

到底是什么进程需要打开那么多文件数？在sar -v的命令中，我们只看到了一个总数，能具体的去看什么进程打开多少文件数吗？

在这里，HP提供了一个工具：crashinfo。可以查看各个进程的打开文件数：

crashinfo

用法是：

此时能看到各个进程的打开文件数情况：

通过ps -ef |grep 打开文件数最多的几个进程号，发现打开文件数最多的进程是dbwr，smon，lgwr，chkpt。每个进程基本上800～900个打开文件数，且dbwr进程有8个，打开文件数那就更加多了。其他打开文件数较多的进程是LOCAL=NO的进程，通过观察spid关联sql_text，发现是对历史表的操作。历史表是大表，表空间有300多个数据文件，因此，这些进程的打开文件数，也在每个600左右。

此时忽然记起，前段时间该省做优化时，当时DBA将dbwr进程数从2调整到了8，dbwr数增加了4倍，导致打开文件数也相应的增加，这应该就是造成nfile在近期慢慢增长到撑爆为止的原因了吧。

找到了原因，问题就比较好解决了。找了一个停机的时间，把db_writer_processes调整回2，且为了以防万一，再将nfile值改为40万。

附：crashinfo命令的其他用法：