应用人员
反馈数据库异常
，
连不上数据库
，报错
检查
alert
日志，无法打开日志：
服务器后台无法正常登录数据库，通过prelim方式也登录不了数据库：$ sqlplus / as sysdbaSQL*plus: Release 11.2.0.4.0 Production on Thu oct 10 12:11:40 2024copyright(c)1982,2013,oracle. All rights reserved.ERROR :ORA-09925:Message 9925 not found; No message file for product=RDBMS,facility=ORALinux-x86_64 Error:23:Too many open files in systemAdditional information: 9925ORA-01017:Message 1017 not found; No message file for product-RDBMS,facility=ORA杀掉业务会话，可以登录数据库。
检查
alert
日志：
Process startup failed, error stack:
Errors in file /app/oracle/diag/rdbms/his/his/trace/his_psp0_7628.trc:
ORA-27300: OS system dependent operation:fork failed with status: 2
ORA-27301: OS failure message: No such file or directory
ORA-27302: failure occurred at: skgpspawn5
Process m000 died, see its trace file
：
原因是服务器open files
参数配置的资源不够导致的
。
检查/etc/security/limits.conf 文件相关的配置 ， 没有问题 。 检查oracle 用户环境参数配置 ；
# su - oracle $ ulimit -a
发现open files才1024，这个参数明显过低。
编辑 / etc/profile 配置文件 ， 添加参数 ： if [ $USER = "oracle" ]; then if [ $SHELL = "/bin/ksh" ]; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fi umask 022 fi 重启数据库 ，问题临时解决。 检查操作系统日志 ： Oct 10 10:50:21 hisdb abrtd: Directory 'ccpp-2024-10-10-10:50:20-29625' creation detected Oct 10 10:50:21 hisdb kernel: VFS: file-max limit 6815744 reached Oct 10 10:50:21 srmsql abrtd: Executable
检查 / etc/sysctl.conf 配置文件 ：
fs.file-max = 6815744
操作系统报错的和配置文件两边的数值是一致的 ，很明显，根据报错信息来看 file-max 参数值不够 。 6815744 这个数值按照 oracle 最佳实践是足够的 ， 可以推断肯定是有其他原因导致这个数量增加导致的 。
多个数据库进程打开的文件数量基本一样，而且打开的文件都位于 / dev/shm 目录 。
ls -l /dev/shm |wc -l
8950
如果只检查 /dev/shm 下同进程统计
lsof -n | grep /dev/shm|awk '{print $2}'|uniq -c 会发现大部分进程打开文件数结果确实是 8951 个。
检查会话 ：
ps -ef | grep -i $ORACLE_SID |wc -l
325
检查操作系统总共打开的文件描述符数量 ：# lsof -n|grep /dev/shm | wc -l2868699
从上面可以看到数据库会话总共 3 25 个 ，如果按照 每个会话打开 8 985 个左右的文件描述符 ，那么只需要 7 00 个左右的会话 ， 就可以达到file-max 限制 。
检查数据库发现，数据库在dedicated server 模式并且使用 AMM
根据MOS上面提供的计算规则，每个会话默认会打开MEMORY_TARGET/<granule size>个文件描述符，即/dev/shm中的文件数，根据上面的数据库设置，58*1024/4大概是14848多个文件描述符，跟上面8000多个描述符是有差异的。
granule size查询：
select bytes/1024/1024 from v$sgainfo where name like 'Granule Size';
所以，这个计算规则是有问题的，经过测试，实际使用的文件描述符是使用SGA大小进行计算的，数据库启动SGA大小默认使用MEMORY_TARGET*60%，如果使用MEMORY_TARGET*60%*1024/4方式计算，可以得出大概是8900多个文件描述符。
可以判断本次的故障是由于在故障时间点会话数上涨（包括活动和非活动的会话），并且会话没有及时释放连接，从而导致打开的文件描述符达到file-max限制，最终导致oracle出现问题。
