最近遇到一个奇怪的事情，每天晚上22点到第二天8点，使用系统经常会报错。数据库是Oracle，三个实例组成的RAC，中间件是weblogic。
1.从中间件层面上看，这种错误意识是weblogic连不上数据库后，自动重连都连不上，就会出现这种问题。
<2019-10-29 下午10时57分37,679秒 CST> <Received exception while creating connection for pool “ggDataSource”: IO 错误: Connection reset by peer, Authentication lapse 1 ms…>
2.从数据库日志上可以看到，数据库的监听接收到了中间件的连接，不过超时了，10.10.65.15是报错weblogic的IP。
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.65.15)(PORT=21716))
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.65.15)(PORT=21722))
nt main err code: 0
ns main err code: 12535
WARNING: inbound connection timed out (ORA-3136)
3.数据库服务器接收有效的客户端连接请求，但客户端需要很长时间进行身份验证（默认60s）。有可能DB服务器负载很重，因此无法在指定的超时内完成客户端登录。
- 这是临时解决问题的办法：修改"sqlnet.ora"，然后把监听重启一下
SQLNET.EXPIRE_TIME=20
TCP.CONNECT_TIMEOUT=300
SQLNET.OUTBOUND_CONNECT_TIMEOUT=300
SQLNET.INBOUND_CONNECT_TIMEOUT=300
5.分析数据库报告发现负载很小。
6.由于数据库服务器上没有安装nmon，于是安装上，5s采集一次，从22点开始运行，8点结束。采集的文件很大，需要找一台内存比较大的服务器分析。发现IO经常到2GB/s，当IO发生瓶颈的时候数据库的alert日志有大量的WARNING: inbound connection timed out (ORA-3136)。
7.问题已经很明显了，这几台服务器上有别的进程在消耗IO。找运维厂家确认，这三个服务器上，每台有5个实例。为今之计，只有每个实例通过获取AWR报告确认，是那台消耗的IO最多。
总结：现场的环境往往是不可知的，运维厂家的水平参差不齐，只能靠当前信息一步步分析。加超时的配置并不是治本的方法，找到IO的瓶颈才是。