【故障處理】因GREP“花哨”功能導致ORA-12157錯誤的排查過程
這個ORA-12157錯誤已經糾纏我有三天時間了，這個錯誤曾經一度讓我感到很絕望。
在一步一步的排查後，“罪魁禍首”終於漸漸的浮出水面。
注：這裡講述的ORA-12157發生的原因只是導致發生這個錯誤的一種可能，還有很多種情況會導致這個錯誤發生，ORA-12157錯誤，發生原因的介紹非常的籠統，很難一蹴而就的確認問題的出處，類似7445、600等錯誤，需要一一甄別。
這裡簡單記錄一下排查問題的過程。
作業系統:RedHat 5.3
1.在Oracle的oerr工具中查詢到的錯誤解釋如下
ora10g@testdb183 /home/oracle$ oerr ora 12157
12157, 00000, "TNS:internal network communication error"
// *Cause: Internal error during network communication.
// *Action: Not normally visible to the user. For further details, turn
// on tracing and reexecute the operation. If error persists, contact
// Worldwide Customer Support.
透過上面的解釋，可以認定毫無任何參考價值。
Metalink上也沒有太多的關於ORA-12157錯誤的資料。
2.問題是這樣被暴露出來的
為完成異機RMAN恢復，在測試資料庫上需要將10.2.0.1的資料庫升級到與生產資料庫一致的10.2.0.3版本資料庫，在軟體升級完成後，使用“sqlplus / as sysdba”方式登入資料庫，ORA-12157錯誤發生了，無論使用什麼手段都無法登陸到資料庫中，更不用說完成後續任務了。報錯現象如下：
ora10g@testdb /home/oracle$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on Tue Aug 18 19:17:04 2009
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
ERROR:
ORA-12157: TNS:internal network communication error
Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error
Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error
SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
ora10g@testdb /home/oracle$
3.故障排查過程
1）第一個思路：升級用的介質有問題
順著這個思路，進行了測試。
找來曾經用於生產資料庫升級的10.2.0.3的升級介質，重新升級了兩次，同樣的錯誤又頻繁的出現。
否定了這個原因。
2）第二個思路：主機網路卡有問題
找來網路工程師，進行了從硬到軟的測試，測試結果：一切正常。
問題不在這裡
3）第三個思路：升級後的sqlplus工具問題
升級後，將生產環境的sqlplus工具複製過來，測試，發現故障依舊。
還不是問題的出處。
4）第四個思路：從作業系統開始徹底的重做
重新安裝作業系統，重新部署Oracle環境。
發現這一次的測試，在全新安裝完Oracle軟體之後，同樣的報出這個錯誤，無語~~~
5）第五個思路：既然徹底重新安裝都有問題，我開始懷疑是主機硬體的問題，於是我選擇了一臺最近新到的一臺主機，開始又一次的全新安裝
令我徹底無語的時候發生了，竟然還是報錯，難道是傳說中的RP問題？
6）測試和排查到此我已經倍受打擊，在諸多失敗嘗試後，我選擇了冷靜的思考與迴歸
首先全新的物理主機的安裝都會出現這個ORA-12157錯誤，這是不正常的。
可以肯定，問題一定出在在安裝配置的細節，開始細細的檢查每一個配置細節。
細心的與曾經不下上百次的成功安裝和測試經驗進行對比，真相終於要浮出水面了。
所有的配置都沒有變化，唯一變化的部分是“.bash_profile”內容。
這個檔案中多了“一行”資訊，如下：
export GREP_OPTIONS='--color=always'
曾經新增，設定的目的是高亮的形式顯示grep關鍵字結果。
就是這行的資訊就是導致了無數次的升級和安裝失敗“罪魁禍首”！
在取消了這些資訊之後，一切都恢復應有的“平靜”與“正常”。
4.小結
不可以按照思維定勢去做事，用最樸素的方法做好每一件事件。
不要追求“花哨”的功能，以“簡單實用”為根本準則。
希望這個故障處理過程能給您也起到警示的作用。
鑑於這是在升級後出的問題，如果返工時沒有備份，結果將更加慘烈，所以，在每一次重大操作之前，一定要備份（可以tar整個oracle目錄，也可以exp，也可以RMAN）。
有了備份就有了後路。
Goodluck.
-- The End --
在一步一步的排查後，“罪魁禍首”終於漸漸的浮出水面。
注：這裡講述的ORA-12157發生的原因只是導致發生這個錯誤的一種可能，還有很多種情況會導致這個錯誤發生，ORA-12157錯誤，發生原因的介紹非常的籠統，很難一蹴而就的確認問題的出處，類似7445、600等錯誤，需要一一甄別。
這裡簡單記錄一下排查問題的過程。
作業系統:RedHat 5.3
1.在Oracle的oerr工具中查詢到的錯誤解釋如下
ora10g@testdb183 /home/oracle$ oerr ora 12157
12157, 00000, "TNS:internal network communication error"
// *Cause: Internal error during network communication.
// *Action: Not normally visible to the user. For further details, turn
// on tracing and reexecute the operation. If error persists, contact
// Worldwide Customer Support.
透過上面的解釋，可以認定毫無任何參考價值。
Metalink上也沒有太多的關於ORA-12157錯誤的資料。
2.問題是這樣被暴露出來的
為完成異機RMAN恢復，在測試資料庫上需要將10.2.0.1的資料庫升級到與生產資料庫一致的10.2.0.3版本資料庫，在軟體升級完成後，使用“sqlplus / as sysdba”方式登入資料庫，ORA-12157錯誤發生了，無論使用什麼手段都無法登陸到資料庫中，更不用說完成後續任務了。報錯現象如下：
ora10g@testdb /home/oracle$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on Tue Aug 18 19:17:04 2009
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
ERROR:
ORA-12157: TNS:internal network communication error
Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error
Enter user-name:
ERROR:
ORA-12157: TNS:internal network communication error
SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
ora10g@testdb /home/oracle$
3.故障排查過程
1）第一個思路：升級用的介質有問題
順著這個思路，進行了測試。
找來曾經用於生產資料庫升級的10.2.0.3的升級介質，重新升級了兩次，同樣的錯誤又頻繁的出現。
否定了這個原因。
2）第二個思路：主機網路卡有問題
找來網路工程師，進行了從硬到軟的測試，測試結果：一切正常。
問題不在這裡
3）第三個思路：升級後的sqlplus工具問題
升級後，將生產環境的sqlplus工具複製過來，測試，發現故障依舊。
還不是問題的出處。
4）第四個思路：從作業系統開始徹底的重做
重新安裝作業系統，重新部署Oracle環境。
發現這一次的測試，在全新安裝完Oracle軟體之後，同樣的報出這個錯誤，無語~~~
5）第五個思路：既然徹底重新安裝都有問題，我開始懷疑是主機硬體的問題，於是我選擇了一臺最近新到的一臺主機，開始又一次的全新安裝
令我徹底無語的時候發生了，竟然還是報錯，難道是傳說中的RP問題？
6）測試和排查到此我已經倍受打擊，在諸多失敗嘗試後，我選擇了冷靜的思考與迴歸
首先全新的物理主機的安裝都會出現這個ORA-12157錯誤，這是不正常的。
可以肯定，問題一定出在在安裝配置的細節，開始細細的檢查每一個配置細節。
細心的與曾經不下上百次的成功安裝和測試經驗進行對比，真相終於要浮出水面了。
所有的配置都沒有變化，唯一變化的部分是“.bash_profile”內容。
這個檔案中多了“一行”資訊，如下：
export GREP_OPTIONS='--color=always'
曾經新增，設定的目的是高亮的形式顯示grep關鍵字結果。
就是這行的資訊就是導致了無數次的升級和安裝失敗“罪魁禍首”！
在取消了這些資訊之後，一切都恢復應有的“平靜”與“正常”。
4.小結
不可以按照思維定勢去做事，用最樸素的方法做好每一件事件。
不要追求“花哨”的功能，以“簡單實用”為根本準則。
希望這個故障處理過程能給您也起到警示的作用。
鑑於這是在升級後出的問題，如果返工時沒有備份，結果將更加慘烈，所以，在每一次重大操作之前，一定要備份（可以tar整個oracle目錄，也可以exp，也可以RMAN）。
有了備份就有了後路。
Goodluck.
-- The End --
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/519536/viewspace-613043/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【故障處理】【oerr】【grep】謹防grep“花哨”功能導致oerr工具無法使用
- 【故障處理】因授權資訊丟失導致IMP時出現IMP-00041錯誤的模擬與分析
- 【CREATE DATABASE】因缺失單引號導致手工建庫命令執行報錯的故障排查Database
- Oracle 12c因bug導致ORA-04031問題處理過程Oracle
- 【故障處理】一次RAC故障處理過程
- OGG 配置過程中的錯誤處理
- 【問題處理】dbca建庫過程中報 ORA-04031錯誤的排查
- 編譯過程導致ORA-4068錯誤編譯
- 一次死鎖導致CPU異常飄高的整個故障排查過程
- 【RAC】處理因ons導致CPU使用率過高的問題
- 【故障處理】序列cache值過小導致CPU利用率過高
- 【故障處理】ORA-12162 錯誤的處理
- HSG80故障處理過程
- 【故障處理】CRS-1153錯誤處理
- 【故障處理】ORA-19809錯誤處理
- 一次FGC導致CPU飆高的排查過程GC
- 故障分析 | MySQL convert 函式導致的字符集報錯處理MySql函式
- 【故障恢復】因spfile修改錯誤導致資料庫無法啟動的恢復方法資料庫
- 【故障處理】因AIX非同步IO沒有開啟導致SQL*Plus不可用AI非同步SQL
- 【DataGuard】錯誤的log_file_name_convert引數導致物理Data Guard配置故障分析與處理
- 【問題處理】因ASM磁碟組空間不足導致資料庫例項無法啟動的故障處理ASM資料庫
- 【故障處理】手工刪除歸檔日誌導致RMAN備份時報ORA-19625錯誤
- 【問題處理】恢復因誤生成PFILE 導致RAC的SPFILE無效的問題
- 【恢復】非歸檔模式下因誤刪除資料檔案導致資料庫無法OPEN的故障處理模式資料庫
- WCDMA測試庫故障處理過程
- 一次ORA-00257錯誤的處理過程
- [譯] RxJS: 避免因濫用 switchMap 而導致錯誤JS
- [zt]Logical standby同步故障的處理過程
- imp 匯入遇到 FK (Foreign Key) 導致錯誤處理
- ORA-01591錯誤故障處理
- laravel Route RESTful 因路由先後順序導致的解析錯誤LaravelREST路由
- 錯誤處理：如何通過 error、deferred、panic 等處理錯誤？Error
- 記一次ora-04030錯誤的處理過程
- IMP過程中報ORA-00907錯誤的處理
- domino的java開發，找不到方法故障處理過程Java
- 【RAC】處理因ASM例項異常導致RAC第一節點例項異常終止故障ASM
- 轉載ORA-01591錯誤故障處理
- 【LISTENER】因 tnsnames.ora配置檔案配置問題導致ORA-12154錯誤排查一例