据应用反馈,连不上数据库,提示ora-12170
重启数据库后正常,12170只能开启跟踪来分析,过了一段时间问题复现:
-
2022-01-05 09:27:14.578549 : ntctst:size of nttest list is 1 - not calling poll
-
2022-01-05 09:27:14.579473 : sntseltst:testing for write on socket 864
-
2022-01-05 09:27:15.604874 : sntseltst:found: write request on socket 864
-
2022-01-05 09:27:15.604957 : ntt2err:entry
-
2022-01-05 09:27:15.604980 : ntt2err:soc 864 error - operation=1, ntresnt[0]=511, ntresnt[1]=61, ntresnt[2]=0
-
2022-01-05 09:27:15.604998 : ntt2err:exit
-
2022-01-05 09:27:15.714074 : nttcni:exit
-
2022-01-05 09:27:15.714126 : nttcon:exit
-
2022-01-05 09:27:15.714538 : nserror:entry
-
2022-01-05 09:27:15.714580 : nserror:nsres: id=0, op=65, ns=12541, ns2=12560; nt[0]=511, nt[1]=61, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
-
2022-01-05 09:27:15.714605 : nsopen:unable to open transport
-
2022-01-05 09:27:15.714893 : nsiocancel:entry
-
2022-01-05 09:27:15.714923 : nsiofrrg:entry
-
2022-01-05 09:27:15.714940 : nsiofrrg:cur = 52f7d18
-
2022-01-05 09:27:15.714956 : nsbfr:entry
好像是12541 12560问题呀,搜索一下mos,看到 doc id 1532405.1,说是 netstat -an|find "1521"应该看到last_ack的一些连接。
解决方法是打windows补丁,可操作系统版本不对,微软的相关kb补丁已经找不到了。
又搜索了一下last_ack,发现似乎可以设置 tcptimedwaitdelay 参数来规避。
-
-
tcptimedwaitdelay的值表示系统释放已关闭的tcp连接并复用其资源之前,必须等待的时间。这段时间间隔就是以前的blog中提到的time_wait状态(2msl,数据包最长生命周期的两倍状态)。如果系统显示大量连接处于time_wait状态,则会导致并发量与吞吐量的严重下降,通过减小该项的值,系统可以更快地释放已关闭的连接,从而为新连接提供更多的资源,特别是对于高并发短连接的server具有积极的意义。
-
该项的缺省值是240,即等待4分钟后释放资源;系统支持的最小值为30,即等待时间为30秒。具体操作:
-
浏览至hkey_local_machine\system\currentcontrolset\services\tcpip\parameters注册表子键,在parameters子键下创建或修改名为tcptimedwaitdelay的reg_dword值,该值的范围是从0到300,建议将该值设置为30。
-
引自: www.cnblogs.com/xiaoleiel/p/11160711.html
待确认。
阅读(1006) | 评论(0) | 转发(0) |