开篇第一个 windows ora-12170

据应用反馈，连不上数据库，提示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

待确认。