前言
每一個DBA在進行數據庫治理的過程中不可避免的要碰到形形色色的錯誤(ORA-1547 ,ORA-904,ORA-1578 ......)。有些錯誤由于頻繁出現、原因復雜而被 Oracle DBA 們戲稱之為"經典的錯誤"。 其中ORA-3113 "end of file on communication channel" 就是這樣的一個。
我們可以簡單的把這個錯誤理解為Oracle客戶端進程和數據庫后臺進程連接中斷。不過，導致這個錯誤的原因實際上有很多種：對數據庫設置不當、任何能導致數據庫后臺進程崩潰的行為都可能產生這個錯誤。這個錯誤的出現還經常伴隨著其它錯誤，比如說：
ORA-1034 ORACLE not available
此外，該錯誤出現的場景復雜，可能出現在：
啟動的Oracle的時侯
試圖創建數據庫的時侯
試圖對數據庫進行連接的時侯
在客戶端正在運行SQL/PL/SQL的時侯
備份/恢復數據庫的時侯
其它一些情況下．．．．．．
在論壇上也時常可以看到初級DBA對這個問題的求救。在這里簡單的對該問題進行一下整理。
錯誤原因種種
根據網絡上大家反映的情況來看,錯誤原因大約有這些：
Unix核心參數設置不當
Oracle執行文件權限不正確／環境變量問題
客戶端通信不能正確處理
數據庫服務器崩潰/操作系統崩潰/進程被kill
Oracle 內部錯誤
特定SQL、PL/SQL引起的錯誤
空間不夠
防火墻的問題
其它原因
在開始解決問題之前,作如下幾件事情：
回憶一下在出現錯誤之前你都做了什么操作，越具體越好;
查看 background_dump_dest 目錄中的 alertSID.log 文件也是你必須要的事情;
用Google.COM 搜索一下,在互聯網上有很多信息等著你去發現,不要什么都問別人。
當然, 假如你找到了一些對你更有幫助的東西--這篇文檔就不用看了 :-)
錯誤原因情景分析
Unix核心參數設置不當 / init參數設置不當
假如數據庫在安裝過程中沒有設定正確的操作系統核心變量，可能在安裝數據庫文件的時侯沒甚么問題，在創建數據庫的時侯經常會出現03113錯誤。和此有關的另一個原因是init.ora 參數文件中的PRocesses參數指定了不合理的值，啟動數據庫導致錯誤出現(當然這個歸根到底也是核心參數的問題)。
這個錯誤信息一般如下：
ORA-03113: end-of-file on communication channel
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
解決辦法有兩個：
1、修改核心參數,加大相應核心參數的值(推薦);
2、減小init.ora參數的Processes的值。
需要注重的是：
SEMMSL必須設定為至少要10 + '進程數的最大值'；
SEMMNS 也依靠于每個數據庫上的進程參數值。
注：
這個錯誤類型只在Unix平臺上出現。在Windows上假如processes的值過大，則會出現類似如下的錯誤：
ORA-00068: invalid value 24200001 for parameter max_rollback_segments,
must be between 2 and 65535
/* 此時指定的參數值超過了65535 */
或者 ORA-27102: out of memory /* 小于65535的一個大參數值 */ 軟件環境：
windows 2000 Version 5.0 Service Pack 3, CPU type 586
ORACLE RDBMS Version: 8.1.7.0.0
在特定平臺上更改核心參數可能會有差別，請參考Oracle Technet(http://otn.oracle.com) 上的安裝文檔。
對特定Unix平臺的安裝文檔也有對核心參數意義的解釋。 Init.ora中的參數假如設置不當，會產生該錯誤。有經驗表明：shared_pool_size設置過小會出現錯誤，此外timed_statistics=true的設置也會帶來問題。
Oracle執行文件權限不正確/環境變量問題
這個問題只出現在Unix平臺上。常見情況是有的時侯治理員為了方便而使用Unix的tar命令處理過的壓縮包進行的安裝，或者是系統治理員指定了額外的OS用戶也可以治理數據庫卻沒有指定正確的環境變量。
Oracle執行文件在$ORACLE_HOME/bin目錄下,假如出現問題,應該用如下Unix類似命令來糾正 ： #chmod 7755 $ORACLE_HOME/bin/oracle
有的時侯要對Oracle進行relink操作。
在Unix上通過cp拷貝安裝的時候，經常會出現環境變量的問題，和個別執行程序連接問題。 LD_LIBRARY_PATH假如設置的不正確會導致問題，在這種情況下，需要對Oracle進行relink。假如可執行文件oralcle被破壞，也要對其relink。 假如安裝了并行服務器選項而Distributed Lock Manager沒有安裝或正確運行也會導致錯誤。
客戶端通信不能正確處理
1.SQL*Net驅動器的問題：
假如使用的版本比較低的驅動器，請更換到新版本的驅動。 SQL*Net 的驅動沒有連接到Oracle可執行文件會導致錯誤。
2.檢查TCP/ip網絡是否通暢；
3.Windows平臺的常見網絡問題：
在Windows平臺創建數據庫的時侯,假如出現該問題可以考慮用如下的方法：
首先檢查本地網絡設置.查看網絡上是否有同名的結點或有沖突的IP.假如問題依舊,可以保守的用下面的方法：
1). 禁用網卡：將本地連接狀態改為禁用;
2). 將sqlnet.ora文件打開(以記事本形式)將nts驗證注釋掉：
#SQLNET.AUTHENTICATION_SERVICES= (NTS)
3). 創建數據庫;
4). 創建成功后,恢復本地連接；
數據庫服務器崩潰/操作系統崩潰/進程被異常的Kill
在連接過程中，假如Oracle數據庫的服務器崩潰或者數據庫所在的操作系統崩潰，就會出現這 個錯誤，Oracle Server崩潰的原因可能因為主要后臺進程死掉，被錯誤的進行了Kill操作。假如是這個原因還是比較輕易解決的。此外,和OS有關的應用程序存在內存泄漏(或者有病毒)的時侯也會導致Oracle后臺程序問題。 推薦排錯步驟：
1、 查看應用軟件相關進程是否正常運行；
2、 查看有無內存泄漏；
3、 查殺病毒；
4、 確定系統治理員沒有進行誤操作；
5、 確定無黑客入侵行為；
6、 其它不確定因素．．．．．．
Oracle 內部錯誤 / Bug
假如查看background_dump_dest目錄中的alert.log發現有ora-600/ora-07445等錯誤,可以到Metalink站點上查看具體信息及其解決方案。一般情況下要打軟件補丁。
特定SQL、PL/SQL引起的錯誤
嘗試把SQL進行分開執行,也可以用SQL_TRACE來進行跟蹤,找到導致問題的SQL語句。在SQLPlus下： ALTER session SET sql_trace=TRUE;SQL語句中的非法字符和不合理的處理結果，甚至一些不可解釋的原因偶然會帶來問題.
SQL問題舉例： SELECT *
FROM (SELECT ROWNUM AS num, k.*
FROM (SELECT a.cp_code, c.cp_cha_name, a.service_code,
a.service_name, a.content_name,
SUBSTR (a.access_time, 1, 8) thedate,
COUNT (*) AS hit_count
FROM sm_wap_log_daily_tab a, t_cp_info c
WHERE (SUBSTR (a.access_time, 1, 8) BETWEEN '20040301'
AND '20040304'
)
AND c.cp_code LIKE '%%'
AND a.cp_code = c.cp_code
AND a.service_code LIKE '%%'
GROUP BY a.cp_code,
c.cp_cha_name,
a.service_code,
a.service_name,
a.content_name,
SUBSTR (a.access_time, 1, 8)
ORDER BY a.cp_code,
a.service_code,
a.content_name,
SUBSTR (a.access_time, 1, 8) DESC) k) n;
上面這條語句在9204/linux 系統上始終出現03113 的錯誤。
對語句進行細化，分成小一點的子語句逐步執行，最后判定問題出現在 ORDER BY a.cp_code,
a.service_code,
a.content_name,
SUBSTR (a.access_time, 1, 8) DESC) k) n;
中的 SUBSTR (a.access_time, 1, 8) 這里。去掉SUBSTR (a.access_time, 1, 8)則問題不再出現。嘗試調整SUBSTR (a.access_time, 1, 8) 的位置，語句得到通過。之后，順便優化一下該語句。:) SELECT *
FROM (SELECT ROWNUM AS num, k.*
FROM (SELECT a.cp_code, c.cp_cha_name, a.service_code,
a.service_name, a.content_name,
SUBSTR (a.access_time, 1, 8) thedate,
COUNT (*) AS hit_count
FROM sm_wap_log_daily_tab a, t_cp_info c
WHERE (SUBSTR (a.access_time, 1, 8) BETWEEN '20040301'
AND '20040304'
)
AND c.cp_code LIKE '%%'
AND c.cp_code = a.cp_code
AND a.service_code LIKE '%%'
GROUP BY a.cp_code,
c.cp_cha_name,
a.service_code,
a.service_name,
a.content_name,
SUBSTR (a.access_time, 1, 8)
ORDER BY (SUBSTR (a.access_time, 1, 8)),
a.cp_code,
a.service_code,
a.content_name DESC) k) n;系統空間不夠
任何時侯都要確保數據庫系統有足夠的空間.假如 USER_DUMP_DEST和BACKGROUND_DUMP_DEST沒有剩余空間的話,會導致此問題.此外,假如打開了審計,AUDIT目錄要由足夠的空間.假如激活了Trace的話,Trace目錄要由足夠的空間. Dave Wotton的文檔 (Local Copy) 表明,在對表進行插入數據的時侯,假如文件超過了2G (而文件系統有2G限制),會導致該問題.
防火墻的問題
假如數據要通過防火墻，請聯系系統治理員，詢問是否對數據庫數據進行了過濾或者是忽然禁止了通信端口。如本地安裝有個人防火墻，請檢查本地設置。
其它方面說明
導致這個錯誤的原因有很多種，上面列到的只是一些典型情況。經常去一些數據庫技術論壇可能會有幫助。比如說ITPUB( http://www.itpub.net)、CNOUG(http://www.cnoug.org)等。
