資料庫伺服器
系統：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/

[email protected]連線資料庫，不能進入到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/

[email protected]和sqlplus system/[email protected]來連線資料庫的時候完全正常！！！但使用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/

[email protected]和sqlplus system/[email protected]連線資料庫也完全正常，但試圖sqlplus system/[email protected]時依然無法連線，這時我按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，但出故障的時候，為什麼沒有一個客戶連線會連線到空閒的例項上（正常的時候）？

不管怎樣，共享伺服器上的問題已經找到原因了，如果還有問題，大不了再增加共享伺服器的數量，或者直接使用專用伺服器！感謝達人們的幫忙！先給分！以後有關這問題的新發現，我再貼上來