HP的查看打开文件数工具:crashinfo

一天,在一个业务高峰期,某省的一个数据库突然宕机了,根据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命令的其他用法:

相关文章

5条评论

  1. re David.Guo:我们也是有监控的,不过没引起监控人员的注意。唉,失败呀~~~
    不过更失败的是SA的service guard没配好,没monitor到oracle进程,数据库宕机后竟然没自动切换到B机。

  2. 最近也遇到这个问题了,但是没有工具进行分析查看。
    能否把这个crashinfo的工具共享下,网站上下载不下来,
    发我邮箱也可以
    ora315@gmail.com
    谢谢!

  3. 我也遇到这个问题,按照metalink的提示增加了
    nproc = Max Number of Processes
    nfile = Max Number of Open Files
    nflocks = Max Number of File Locks
    的值,但是file-sz 的值一直在涨(要是股票就好了),最后又down了,再增大,再dwon,我晕了。请何大师指点

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据