3月8日下午发现主机130.31.1.234无法登录，尝试登录Oracle，系统返回ORA-12500错误（TNS:listener failed to start a dedicated server process）。可能引起该错误的原因有多种，包括以下：
Oracle服务进程使用的session或process数达到了参数设置的上限，导致无法再分配新的服务进程。
系统资源耗尽，Oracle在启动新进程时调用的系统调用fork函数因资源不足而出错。
AIX下sys0对象上的属性maxuproc代表用户可以使用的最大进程数，若用户进程数接近该设定值可能导致Oracle无法启动新进程。
因主机无法远程登录，故在晚间进行了重启。重启后查看Oracle告警日志发现记录：“skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3”，该段信息表示模块skgpspawn在fork一个新进程是出现了错误；由此可以判断不是由于session或process数达到参数设置的上限，因为若是session或process数不足，Oracle应当显示地返回ORA-00018（maximum number of sessions exceeded）或ORA-00020（maximum number of processes (%s) exceeded）错误。
通过在主机上查看sys0对象属性，发现maxuproc参数的设置值达到了4096，故基本可以排除因该参数不当引起连接问题的可能性。
系统资源耗尽将导致Oracle监听器无法为新的连接分配新的服务进程，而老的服务进程上的内存资源等可能一直没有得到释放；statspack是Oracle9i中反映Oracle运行性能的工具，以JOB形式在后台运行，目前设置为每两小时运行一次快照。分析快照发现，在主机重启前最后一次快照为下午14:15分开始的，之后系统进入资源紧张阶段，Oracle无法分配新的JOB(j00n)进程,故最后的快照发生在系统出现问题之前。
分析快照内容，在12:06到14：15之间，数据库参数没有改动的记录，sga_max_size设置为10GB, pga_aggregate_target设置为4GB,考虑到Oracle在启用RAC特性后SGA的实际内存使用量将会超过sga_max_size的设置，故Oracle总的内存最大使用量应控制在20GB内。而目标主机的实际物理内存达到了64GB,且专业计费系统一直以来运行良好，故可以排除因Oracle内存参数设置不当，而造成了本次问题的出现。
进一步分析快照发现这一阶段内Oracle数据库高速缓冲的命中率buffer hit为55.90,这个值要较平时水平低很多，可以判断该阶段内数据库可能执行了一些不同于日常业务的操作，这些操作引起较大的物理读表现为缓冲池的命中率明显降低。分析等待事件可以发现，db file scattered read事件即数据库多块物理读是这一阶段的主要等待事件，进一步印证了上述的判断。
通过对数据库快照的分析，证实在连接问题发生之前的短暂时间内,在P6702实例上的确有过引起较大物理读的操作，但实际Oracle使用的内存受到sga_max_size与pga_aggregate_target参数的限制应控制在20GB的范围内，且专业计费系统数据库使用裸设备数据文件，不存在过度使用文件系统缓存的可能，故可以排除由Oracle数据库导致系统资源耗尽的可能性。
因为没有该阶段内系统内存使用量的日志文件，故无法了解到目标主机上当时其他服务的实际内存使用量，但可以排除是问题因Oracle引起的。