我们知道当ORACLE数据库启用共享服务器模式时，通过共享服务器模式连接到数据库的会话是有一些特征的。在v$session里面，其SERVER的状态一般为SHARED和NONE， 为SHARED时，表示当前会话正在执行SQL语句，其占用共享服务器进程，会话的STATUS状态为ACTIVE；当会话状态STATUS处于INACITVE时，它的SERVER字段值一般为NONE，意味着此时并没有共享服务器进程服务该会话，这个详细请见v$session中server为none与shared值解析 这篇博客。但是最近在一数据库中突然见到一些会话STATUS为INACTIVE，但是SERVER状态为SHARED的会话，如下所示：
其实发现这个问题是因为在追查一个TNS-12535的问题时发现的。当时突然出现短暂的数据库（Oracle 10g R2）连接不上的情况，nmon监控发现当时的整体资源开销都非常小，也分析过AWR、ASH报告，并没有发现很特殊的情况，但是在bdump下面发现shared server进程生成的trc文件。例如下面一个 epps_d004_24858.trc，截图所示:
在这篇博客”TNS-12535: TNS:operation timed out案例解析”里面我分析、构造过出现TNS-12535错误的场景。但是我们分析ASH报告和查询dba_hist_active_sess_history时发现出现问题的时间段，active会话的数量不超过4个。所以可以排除是这种情形。后面检查发现共享服务器模式的会话居然有STATUS为INACTIVE但是SERVER为SHARED状态的会话，而且数量较多，本身这台服务器的max_shared_servers参数为32，所以当大量INACTIVE会话一直占用shared server进程时，当ACITVE会话需要shared server服务进程时就会由于shared server进程不够而处于等待状态，时间长了就会出现TNS-12535错误。那么就有可能出现active session不多，但是连接不上数据库的这种情况。分析至此，那么就有两个问题需要解决：1 为什么INACTIVE的会话会占用shared server进程不释放？ 2 这个分析必须要经测试验证确认. 3:如何解决这个问题?
SQL> show parameter max_shared_servers;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
max_shared_servers integer 32
SQL>