升级11.2.0.3到11.2.0.4你可能不知道的事情

升级patchset是小事？不是，patchset的升级从来都不是小事。如12.1.0.1到12.1.0.2就多了一个引人注目的in-memory options。今天说一个你可能不知道的从11.2.0.3升级到11.2.0.4的变化。（Solaris操作系统）

在高并发的连接时，如果listener“太忙”，就会在tcpip这一层把包丢弃，我们可以在操作系统上用命令看：

如果上述两个值长时间大于0，说明有排队现象，会导致系统网络速度变慢。

对应于listener，我们可以适当的加大queuesize参数，来解决上面的问题。

可是问题是，在没有设置的情况下，默认值是多少？

在文档TNS-12535 / ORA-12535 on Connection to Database (Doc ID 214122.1)中有提及：

也就是说，在10.1之后，11.2.0.4之前，queuesize的大小是固定值32，而11.2.0.4（含）之后，大小就直接使用操作系统参数SOMAXCONN。

我们来验证一下：

我当前系统是11.2.0.4，也就是说，是受到SOMAXCONN的限制。我先设置了queuesize=123。

然后用truss开始跟踪：

从truss中，我们看到第三行变成了我预设的那个值（注：不同的主机，不同的操作系统版本，grep出来的行数可能不同，不一定在第三行）：

好，我们取消queuesize的设置，恢复成默认值。

然后我们继续truss，继续grep看truss的结果：

看到第三行已经变成了128。

也就是说，在我不设置queuesize的情况下，我的11.2.0.4的数据库的listener的queuesize取决于操作系统参数SOMAXCONN，这个值是128。

而操作系统SOMAXCONN的值，我们其实可以看/usr/include/sys/socket.h文件，里面有SOMAXCONN的值：

最后，再说一下，在同一台主机上，还有一个11.2.0.3的数据库，按照上面的truss方法，得到的默认queuesize值为32。确实如文档所说。

所以，这篇文章介绍了用truss验证listener默认queuesize的大小。如MOS文档所说，不同版本的数据库，queuesize的大小是不一样的。

有时候，你从11.2.0.3升级到11.2.0.4，发觉连接风暴的问题缓解了，其实是内部行为不一样了，11.2.0.4默认取操作系统SOMAXCONN值，而现在的主机的SOMAXCONN，一般都比32要大。而这些变化，是Oracle Database 11g Release 2 (11.2.0.4) New Features不会提到的。:)