一、【問題描述】

最近，在系統高峰期的時候，會提示如上的錯誤，致使無法連接到服務器上的數據庫。

二、【分析過程】

1、首先判斷是否由于監聽配置不正確的原因導致?

系統在正常情況下都可以正常的使用，檢查監聽配置，完全正確，監聽配置不正確的可能性排除.

2、是否因為數據庫服務器處于共享服務器模式，是否會因為DISPATCHERS的數量太少，導致在高峰期的時候無法及時的分配客戶機連接呢？

把ORACLE的DISPATCHER數量增加到3個，發現在系統高峰的時候還是會出現如此的問題，可確定不是DISPATCHER的問題。

3、判斷是否PROCESS、SESSION數量設置的不夠，導致ORACLE在高峰期的時候，沒有足夠的PROCESS對連接上來的客戶服務進行分配？

增大PROCESS、SESSION的設置，這種情況基本能夠得到解決，出現的頻率已經很少，但在一定的情況下，還是會出現以上的提示。

4、在網上查找資料后發現，32位的WIN2003系統ORACLE單進程的限制為1.7G，對于超過的內存，ORACLE也無法使用，導致ORACLE在高峰期對客戶機分配到一定數量的時候，導致ORACLE可用的內存不足，導致以上提示..此時，只有通過降低SGA的大小，以使得ORACLE有更多的內存可以對客戶端進行分配.

經檢查，現場的托管服務器環境為：32位的WIN32以及32位的ORACLE..直接導致ORACLE能夠使用的內存不超過1.7G，對SGA的大小進行一定量的減少，系統基本不再出現無法分配的問題。

三、【解決途徑】

1、首先修改ORACLE的PROCESS、SESSION數量

查看當前ORALCE PROCESS數量

SQL> show parameter process

查看當前ORALCE SESSION數量

SQL> show parameter session

修改PROCESS數量：

SQL> alter system set processes=1000 scope = spfile;

修改SESSION數量：

SQL> alter system set session=1105 scope = spfile;

注：sessions是個派生值,由processes的值決定,公式sessions=1.1*process + 5

2、降低系統的SGA大小

查看SGA的大小:

SQL> show parameter sga

同時修改sga_max_size和sga_target

SQL> alter system set sga_max_size=1000M scope = spfile;

SQL> alter system set sga_target=1000M scope = spfile;

重啟ORACLE服務，問題基本解決。

四、【經驗總結】

雖然通過增加PROCESS、SESSION數量并且降低了SGA的大小，使得整個托管的服務器的問題得到解決。但是，通過上面的問題分析可以知道，這只是治標不治本的處理方式，問題的最終原因還是因為32的WIN 2003操作系統+32位的ORACLE導致單進程最高內存不能超過1.7G導致的。所以在以后縣區的數據加至現在的服務器中，必將導致這個問題的重現.

所以，最終的解決辦法是，將數據庫和服務器的操作系統全部升級至64位，或者將服務器使用UNIX的操作系統.

所以，在以后類似的托管服務器或者其他數據庫服務器搭建時，一定要注意這個問題，如果客戶提供的服務器為32位的，那么，一定要反應出這個問題.

總結

以上是生活随笔為你收集整理的aix oracle监听配置_Oracel：ORA-12518：监听程序无法分发客户机连接的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。