一: 19 c
12 c迁移工程,针对大数据相关定时作业进行性能对比,发现部分作业连接19 c出现套接字读取超时问题,并且可以复现,该部分作业连接12 c并无异常
初步排查情况如下:
1)在执行到某部分sql时jdbc抛出错误:. io .IOException: SQLException nextKeyValue错误,导致的原因是由于:java.sql。SQLRecoverableException: IO错误:套接字读取定时out
2) jdbc堆栈信息无奥拉错误,看起来是一个客户端单方面错误
3)连续查看几次报错日志,发现每次报错都是在发起sql后的第11分钟才抛出异常,询问客户是否有进行超时相关测试,客户反馈连接串中未设置任何参数
4)对该场景进行重现测试,发现客户端报出套接字读取超时,数据库会话依然在执行直到sql执行结束
5)关于套接字读取超时初步了解到是客户端在向数据库发起查询时等待数据返回时超过了某个时间限制导致超时
6)了解到jdbc驱动程序版本是11.2.0.1.0
二:
1) jdbc驱动程序版本11.2.0.1是不兼容19摄氏度,建议客户先进行升级测试
2)需要进一步排查网络是否有超时设置
3)通过以上步骤来缩小排查范围
2。讨论进展如下:
1)客户否认网络存在问题,但我认为是否可以继续进行抓包排查
2)客户表示驱动包问题可以进行升级驱动测试,确认是否驱动包问题
3)提出每次报错都是在第11分钟开始报错,客户提出可能应用平台有配置过10分钟的超时设置,开发排查代码发现有10分钟超时设置,后面增加超时时间再进行测试,发现不再报错
4)客户存在疑问,为何同样的配置在12 c不生效,而在19 c能够生效
5)现场同时排查了数据库端sqlnet参数,12和19 c并无差别
三:
1)询问中间件同事,表示针对不同数据库版本可能会有不同的超时时间设置,这一点找不到相关资料,询问老,gcs表示没有不同的设置说法
2)中间件同事和sr同时也建议排查操作系统层,目前只能看到数据库端操作系统,目前看到的网络相关参数不确认。
3)客户在测试环境使用11.2.0.4版本jdbc进行测试,发现同样在12 c不会超时,而在19 c会出现超时
4)为了排除数据版本不同造成插座超时不生效原因,我使用一段java代码指定不同版本的jdbc驱动程序分别连接12 c和19 c进行查询操作一段,设置套接字超时时间为10年代,发现11.2.0.1和11.2.0.4的jdbc驱动程序连接12 c和19 c查询超过10 s后都能出现超时情况,进一步可以说明超时是否生效与数据库版本无关,同时也和jdbc版本无关,所以问题还是出现在应用端配置上,将此情况向客户反馈。
四:
1)将java测试代码readtimeout从10秒钟调整为10分钟,看是否能复现客户的问题。
2)调整为10分钟进行测试,结果是19 c正常10分钟超时,12 c 10分钟超时。
3)与gcs jdbc工程师讨论,怀疑12 c超时不生效是因为客户端套接字api在监测时不断接收到数据包,导致超时时间被不断延长。
4)协调系统工程师进行连接12 c和19 c的网络抓包测试,发现连接12 c时,db端每2分钟会发送一个10字节的tns包到客户端,随后客户端会返回ack包。而连接19 c时,db端每2分钟发送一个点火电极包到客户端。从db端来看,目前配置了sqlnet.expire_time=2,可能与此有关。
5)与gcs工程师讨论,12 c为何超时不生效就应该是定时tns包影响,而19 c超时生效是因为维生包是相对比较底层的数据包,客户端操作系统直接过滤掉。
五:
1)查询文档Oracle Net 12 c:改变死亡的功能连接检测(以便)(1591874.1文档ID)发现在12 c后,开启DCD计划后db端检测死连接的方式是从每n分钟发送10个字节tns包改成了tcp维生包,这里可以解释19 c网络抓包中看到的每2分钟一个的维生包。
2)但目前来看,连接12 c是使用了传统的tns包,而19 c是使用了新的维生包,从文档1591874.1中看是12.1之后就默认使用了新的模式,但如果操作系统不支持或者认为设定,可以改为传统发送tns包的模式,目前12 c是solaris 11.3操作系统,是支持保持活着的,理论是应该支持新模式的,目前找不到更多资料说明,这仍是是个谜团。
