最近在做线上oracle11g thin链接升级的时候,搞出一个线上故障,原因是增加的oracle.jdbc.ReadTimeout参数设置有问题。
系统中一个以前配置了以下几个参数:
1.blocking-timeout-millis 500ms
2.query-timeout180s
3.idle-timeout-minutes 30m
升级后增加了2个参数:
1.oracle.jdbc.ReadTimeout 60000ms
.CONNECT_TIMEOUT 10000ms
先来解释下这几个参数的作用:
blocking-timeout-millis :是应用获取数据库链接的等待时间。一般数据库链接都是一个池子,当链接数已经达到了最大链接数的时候,应用如果还要获取链接就会出现等待的现象,等待链接释放并回到链接池,如果等待的时间过长就应该踢掉这个等待,不然应用很可能出现雪崩现象。而这个blocking-timeout-millis就是控制这个等待时间的。
query-timeout:是一个sql执行的时间,如果该sql执行的时间超过它配置的时间就会出现ora01013,用户取消请求操作的异常。
idle-timeout-minutes:是一个数据库链接在多久没有被使用彻底销毁的时间。如果对于资源的要求不是那么高的话,一般配置30m就行了。配置久一点无非是没有使用的链接占用一点内存而已。
oracle.jdbc.ReadTimeout 这个参数实际上是从socket读取数据的时间,总体上说这个时间应该包含了query-timeout的时间。如果这个时间配置得比query-timeout短的话就会出现query-timeout的设置值无效,变为更短的oracle.jdbc.ReadTimeout的值。我搞出的故障也是这个值设得太短导致。
.CONNECT_TIMEOUT 是应用去获取数据库链接的时候,发现还没有达到最大链接数,还需要重新创建链接的创建时间。这个时间一般10s也足够了,如果10s还没有创建好链接,该请求尽早的滚蛋也好,免得应用僵死。
如果觉得《oracle 11G 链接超时 oracle 11g thin链接的超时参数设置》对你有帮助,请点赞、收藏,并留下你的观点哦!