Oracle出现maxnum processes 达到最大连接数

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/chuan_day/article/details/71440167


今天公司的开发库出现了连不上Oracle的情况,大家的工作就会开展不顺,毕竟很多人都需要测试的嘛,然后就找到了我,看了下情况

sqlplus / as sysdba

登录时,出现了maxnum process 超出最大个数,那句英语已经不能完全记得清了,于是去看alert告警日志,发现了如下情况:

ORA-00020: No more process state objects available
ORA-20 errors will not be written to the alert log for
 the next minute. Please look at trace files to see all

以上错误是已经查获的,还有:

Corrupt block relative dba: 0x00811aa7 (file 2, block 72359)

这个是默认的sysaux表空间的数据文件,有坏块,有坏块后,告警日志中又出现了以下情况:

Reread (file 2, block 72359) found same corrupt data
Process m000 submission failed with error = 20
Process m001 submission failed with error = 20
Process m002 submission failed with error = 20
Process m001 submission failed with error = 20
Process m000 submission failed with error = 20
Process m003 submission failed with error = 20
Process m004 submission failed with error = 20
Process m005 submission failed with error = 20
Process m006 submission failed with error = 20
Process m007 submission failed with error = 20

类似这些信息,一段时间后会重复,本来1000的连接数,就是这么慢慢被耗完的,因为我碰到这个问题时查看默认的processes值为150.后来改的1000,很快就被用完了。

这里需要注意的是,当最大连接数超限的时候,因为sqlplus / as sysdba是登不进的,我的办法是先把一些应用程序关掉,先登进去再说。其他我没有非常好的办法,除非就是强制关进程或者停服务。

继续查看告警日志:

ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 2, block # 72359)
ORA-01110: data file 2: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF'
Corrupt Block Found
         TSN = 1, TSNAME = SYSAUX
         RFN = 2, BLK = 72359, RDBA = 8460967
         OBJN = 269, OBJD = 267, OBJECT = SMON_SCN_TO_TIME_AUX, SUBOBJECT = 
         SEGMENT OWNER = SYS, SEGMENT TYPE = Cluster Segment
以上的日志很清楚的说明,在sys用户下的聚簇SMON_SCN_TO_TIME_AUX有坏块,并且在第二个数据文件,72359块中((file # 2, block # 72359)
开始抱着试试看的心态,因为这个段是smon会每个一段时间大概5分钟吧去添加更新,scn与时间的关系,由于其不是必须的,11g中用来闪回。
先通过事件来测试下问题能否解决:
alter system set events '12500 trace name context forever,level 10';
开启应用服务,观察了一段时间,没有了告警,那么这条路是通的,因为会影响闪回,所以完全关闭也是不对的,因此,在事件关闭的情况下执行:
truncate cluster SMON_SCN_TO_TIME_AUX;
执行成功,在执行这条语句时会相应的将smon_scn_to_time表删除数据,因为有坏块直接delete肯定是不行的,因此只能truncate。
执行完后,将事件关闭:
alter system set events '12500 trace name context off';
继续观察告警日志,经过两个小时的观察,不再出现相关的问题了,就算解决了吧。


展开阅读全文

没有更多推荐了,返回首页