升级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这一层把包丢弃，我们可以在操作系统上用命令看：
TCP tcpListenDrop = 0
tcpHalfOpenDrop = 0
如果上述两个值长时间大于0，说明有排队现象，会导致系统网络速度变慢。
对应于listener，我们可以适当的加大queuesize参数，来解决上面的问题。
可是问题是，在没有设置的情况下，默认值是多少？
在文档TNS-12535 / ORA-12535 on Connection to Database (Doc ID 214122.1)中有提及：
Solaris
Oracle Version Default QUEUESIZE Value
9.2 20423: listen(10, 5, 1)
10.1 26948: listen(10, 32, 1)
10.2 4621: listen(10, 32, 1)
11.1 12585: listen(10, 32, 1
11.2 552: listen(10, 32, SOV_DEFAULT)
From 10.1 onwards Solaris Oracle Net code is set to use value of 32.
This is fixed from release 11.2.0.4 and 12c onwards, that is Solaris QUEUESIZE will default use SOMAXCONN.
Note Unpublished Bug:13113888 Default Queuesize From Solaris not using OS Default
也就是说，在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不会提到的。:)