Oracle在RAC环境下远程客户端连接的问题

数据库服务器
系统：Solaris 5.9 两台做cluster，共享磁盘阵列柜
数据库：Oracle 9.2.0.5 做的是RAC
现象：最近2个月发现不时的客户端应用程序无法登录，像死机一样一直等待（2个月前一直正常，这套系统已经投入使用5年）。
应用服务器
  Windows 2003，安装了oracle客户端工具，版本9.2.0.1。这套系统是三层结构体系，客户端应用程序通过应用服务器来对数据库进行访问。这是应用服务器tnsnames.ora的部分内容，应用程序就是通过NODEORA这个服务名来连接数据库的。
NODEORA =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun1)(PORT = 1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun2)(PORT = 1521))
  (LOAD_BALANCE = yes)
  )
  (CONNECT_DATA =
  (SERVICE_NAME = fmis.lsdyj)
  (FAILOVER_MODE =
  (TYPE = session)
  (METHOD = basic)
  )
  )
  )

NODE1 =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun1)(PORT = 1521))
  )
  (CONNECT_DATA =
  (SERVICE_NAME = fmis1)
  )
  )

NODE2 =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun2)(PORT = 1521))
  )
  (CONNECT_DATA =
  (SERVICE_NAME = fmis2)
  )
  )

当客户端应用程序无法登录时，我登录到应用服务器，使用sqlplus system/manager@nodeora连接数据库，不能进入到sql>提示符下，没有提示任何错误，会一直等待，按Ctrl+c中止也没有用。这时候查看alert_sid.log和listener.log在这个时间段都没有任何错误信息。
为了马上解决问题，我只能startup force重新启动一台数据库，一般来说就能恢复，但偶尔，还必须重启另一台数据库。
（用户是上帝啊，NND，不然我的工作早丢了）

为了复现这样的故障，我进行了大量测试，终于发现当客户端进行了大任务查询时（需要数分钟才能完成的综合查询），就会出现这种故障。当客户端这个大任务完成后竟然发现数据库自动恢复正常了。于是我想到可能是数据库工作不正常导致CPU资源占用太高的原因，于是故障时登录solaris，使用prstat命令查看进程信息，会发现其中一台数据库服务器的cpu占用率25%，另一台完全是空载。对于大型的查询，这样的负载为过么？
  PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
 20735 oracle 4126M 4087M cpu0 0 0 2:37:37 25% oracle/2
 20729 oracle 3995M 3950M sleep 59 0 0:00:50 0.6% oracle/2
  761 root 60M 24M sleep 29 10 74:45:18 0.1% java/12
 10936 root 5896K 4952K cpu2 59 0 0:00:00 0.0% prstat/1
…………

我也仔细检查了oracle各项参数和状态，或许是我水平太差，看不出哪里与这种故障有关
没法了，用explorer工具导出了solaris系统状态并发给solaris工程师，看看是不是系统出现毛病，solaris工程师的回答是：系统完全正常……

有一次发生故障时，我发现在应用层服务器上使用sqlplus system/manager@node1和sqlplus system/manager@node2来连接数据库的时候完全正常！！！但使用nodeora服务名连接数据库依然是漫无天日的等待。
为了进一步缩小故障范围，我在两台solaris的tnsnames.ora添加了如下代码：
FMIS =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun1)(PORT = 1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun2)(PORT = 1521))
  (LOAD_BALANCE = yes)
  )
  (CONNECT_DATA =
  (SERVICE_NAME = FMIS.LSDYJ)
  )
  )
FMIS1 =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun1)(PORT = 1521))
  )
  (CONNECT_DATA =
  (SERVER=DEDICATED)
  (SERVICE_NAME = FMIS.LSDYJ)
  (INSTANCE_NAME = FMIS1)
  )
  )
FMIS2 =
  (DESCRIPTION =
  (ADDRESS_LIST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = fmislssun2)(PORT = 1521))
  )
  (CONNECT_DATA =
  (SERVER = DEDICATED)
  (SERVICE_NAME = FMIS.LSDYJ)
  (INSTANCE_NAME = FMIS2)
  )
  )
再登录到solaris，使用sqlplus system/manager@fmis1和sqlplus system/manager@fmis2连接数据库也完全正常，但试图sqlplus system/manager@fmis时依然无法连接，这时我按Ctrl+c后等了2分钟，终于看到oracle报错(破天荒头一回啊，老天开眼了，再不开眼我的工作就除脱了)：
ORA-03106: fatal two-task communication protocol error

可是对于ora-03106，说的是通信的问题，我在数据库服务器上测试也会有些故障，不可能是网络通信或者客户端连接程序版本的问题，但那又是什么原因引起的？
并且ora-03106并不是正常情况出现的，只有我在数据库服务器上测试时，强行按Ctrl+c才出现的提示？那么这个错误会不会是一种误导？
那么还能有什么原因？

 

 

 

今天下班我再次手动复现故障，然后查询了与共享服务器有关的视图，其中gv$queue视图结果如下：
SQL> select * from gv$queue;

INST_ID PADDR TYPE QUEUED WAIT TOTALQ
------- ---------------- ---------- ------ ---- ------
  2 00 COMMON 0 0 30083
  2 000000040F4852D8 DISPATCHER 0 0 30505
  1 00 COMMON 15 0 10788
  1 000000040F4852D8 DISPATCHER 0 0 10924
发现queued列有一个值为15，按照Oracle的解释，理想情况不应该存在排队！
common队列存在排队，说明没有足够的共享服务器进程被用于清空队列，而恰好oracle的参数shared_servers值为 1。
  于是我把shared_servers的值改为3，重启数据库后再运行大型查询，这是队列仍然为空，故障没有出现！

  问题好像解决了，不过我又想到新的问题：
1. 实例参数max_shared_servers的值为20，那么在共享服务器进程不够用的时候，oracle为什么不启动新的进程而在原有的唯一的共享服务器进程上排队？
2. 我启动了三个共享服务器进程才让排除没有发生，但如果这时同时有3个或者更多的人在运行这样的大查询，那么三个服务器可能也不够，那时故障将再次发生！
3. 我重新修改了所有应用服务器上的tnsnames.ora，保证所有连接都启用了load_balance和failover，但出故障的时候，为什么没有一个客户连接会连接到空闲的实例上（正常的时候）？

不管怎样，共享服务器上的问题已经找到原因了，如果还有问题，大不了再增加共享服务器的数量，或者直接使用专用服务器！感谢达人们的帮忙！先给分！以后有关这问题的新发现，我再贴上来