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