TNS-12520: TNS: 监听程序无法为请求的服务器类型找到可用的处理程序

今天上午正在做oracle性能的评分，使用的是toad for oracle，中午回来后，在tnsname.ora中有增加了一个网络服务，以便与连接linux服务器上面的数据库进行模拟数据库故障，之后在使用toad连接oracle的时候出现”TNS-12520: TNS: 监听程序无法为请求的服务器类型找到可用的处理程序“，连接失败

在dos中使用网络名来连接也是报同样的错误：

C:\Documents and Settings\Gavin>sqlplus scott/tiger@orcl
SQL*Plus: Release 10.2.0.3.0 - Production on 星期三 12月 14 17:01:40 2011
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
ERROR:
ORA-12520: TNS: 监听程序无法为请求的服务器类型找到可用的处理程序
请输入用户名:  scott/tiger
连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining option
SQL> 

同样的错误提示，但是使用系统验证的用户比如说是sqlplus / as sysdba登录，确实可以登录的；

使用系统验证的用户登录后重启还是连接不上，网上找了一下错误的原因，有两种方式解决：

1)数据库是专用服务器,但是在tnsname.ora配置中设置了连接方式为shared,这种情况下打开tnsname.ora,
   把(server = shared) 改成 (server = dedicate)
2)是由于process不够引起的
后来查看到v$process一直涨到140多,而我的数据库设置的是150.据此大致能断定process不够,用以下语句修改数据库的processes值  

怀疑是连接这台服务器的客户太多啦，于是查看了一下processes和session是多少，

SQL> show parameter processes;


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
aq_tm_processes                      integer     0
db_writer_processes                  integer     1
gcs_server_processes                 integer     0
job_queue_processes                  integer     10
log_archive_max_processes            integer     2
processes                            integer     350
SQL> show parameter session;


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
java_max_sessionspace_size           integer     0
java_soft_sessionspace_limit         integer     0
license_max_sessions                 integer     0
license_sessions_warning             integer     0
logmnr_max_persistent_sessions       integer     1
session_cached_cursors               integer     20
session_max_open_files               integer     10
sessions                             integer     170
shared_server_sessions               integer

processes达到了350，于是增加了processes
SQL> alter system set processes=500 scope=spfile;


系统已更改。


SQL>

再次尝试还是同样的错误提示，遇事尝试了第一种修改方式，将shared改成了dedicate

重新载入了监听

LSNRCTL> RELOAD
正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
命令执行成功
LSNRCTL>

再次连接可以成功连接

如果早点查询下连接模式就可以避免这些不必要的操作啦

我们可以查询一下当前的连接模式，既然出现这种错误，如果是连接模式引起来的，那我们的tnsname.ora一定是shared,所以我们查看tnsname是不可能得到正确答案的，

我们可以通过

select server from v$session；

如果server = 'DEDICATED'则是DEDICATED方式
:X9Eh yR:Aj1@3Q)Y24585765server='SHARED'则是shared方式，并且正有shared_server_process为其服务ITPUB个人空间(_5F.Rf3K:t
server='NONE'的话，则是shared方式，并且当前没有shared_server_process为其服务。

网上还有一种方法是：

select p.program,s.server from v$session s,v$process p where s.paddr=p.addr;

如果program中有

如果 program 为xxxx(S0NN) 的，则是shared方式，并且正有shared_server_process为其服务
r2}:x8[z;U^ wOp24585765如果 program 为 xxxx(D0NN) 的，则是shared方式，并且当前没有shared_server_process为其服务
/n3ZBB!N24585765如果 program 为 其它的，则是'DEDICATED'方式

但是我在测试的时候验证这种方式都查不到xxxx(SONN)或是xxxx(D0NN)

希望哪位验证了后一种方式可以共享一下