【故障處理】ORA-12162: TNS:net service name is incorrectly specified

swq618發表於2016-07-26
【故障處理】ORA-12162: TNS:net service name is incorrectly specified

本文將給大家闡述一個因未設定系統環境變數ORACLE_SID導致ORA-12162錯誤的案例。希望大家有所思考。

1.獲得有關ORA-12162報錯資訊的通用表述資訊
[oracle@asdlabdb01 ~]$ oerr ora 12162
12162, 00000, "TNS:net service name is incorrectly specified"
// *Cause:  The connect descriptor corresponding to the net service name in
// TNSNAMES.ORA or in the directory server (Oracle Internet Directory) is
// incorrectly specified.
// *Action: If using local naming make sure there are no syntax errors in
// the corresponding connect descriptor in the TNSNAMES.ORA file. If using
// directory naming check the information provided through the administration
// used for directory naming.

2.故障現象
本文所要描述的故障與這個通用的問題描述不同，在資料庫伺服器端使用TNSNAMES.ORA中記錄的連線串連線沒有問題，但如若未指定連線串，將會報出ORA-12162錯誤。

1）使用system使用者嘗試登入系統，此時便會收到報錯如下資訊
[oracle@asdlabdb01 ~]$ sqlplus system/sys

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Aug 27 22:54:02 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

ERROR:
ORA-12162: TNS:net service name is incorrectly specified


Enter user-name:

2）使用sysdba身份登陸會得到同樣的錯誤資訊
[oracle@asdlabdb01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Aug 27 22:54:48 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

ERROR:
ORA-12162: TNS:net service name is incorrectly specified


Enter user-name:

3）但此時，如果使用服務名方式連線資料庫，是可以成功的，這也是該問題現象的詭異之處。
[oracle@asdlabdb01 ~]$ sqlplus system/sys@ora10g

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Aug 27 22:53:41 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

system@ora10g>

想象一下，你的目標是快速的進入到資料庫中進行維護操作，但此時登入都遭遇障礙，會感到非常的彆扭。更讓人抓狂的是，如果此時使用連線串登入到資料庫進行停起操作，結果將會處於更加慘烈境況：資料庫將因為無法正常登入導致無法啟動資料庫。

3.故障原因
詭異的故障背後的原因竟然是那樣的基礎：ORACLE_SID沒有指定！
確認系統當前的ORACLE_HOME和ORACLE_SID環境變數
[oracle@asdlabdb01 ~]$ echo $ORACLE_HOME
/oracle/app/oracle/product/10.2.0/db_1
[oracle@asdlabdb01 ~]$ echo $ORACLE_SID

[oracle@asdlabdb01 ~]$

可見，此時只設定了ORACLE_HOME環境變數，但ORACLE_SID此時為空，這就是該問題的真實原因。

4.故障處理
給出ORACLE_SID，重新嘗試登入。
[oracle@asdlabdb01 ~]$ export ORACLE_SID=ora10g
[oracle@asdlabdb01 ~]$ echo $ORACLE_SID
ora10g
[oracle@asdlabdb01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Sat Aug 27 23:27:34 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

sys@ora10g>

OK，此時問題處理完畢。

5.小結
這個案例給我們的啟迪是什麼？
1）系統預設的錯誤提示資訊有時不具有參考價值。而且，某些情況下這些錯誤提示還可能給我們帶來誤導。原因很簡單，系統預設的錯誤提示資訊不可能囊括所有故障現象；
2）任何系統級別的設定問題都有可能導致資料庫系統出現異常；
3）在遇到故障的時候，我們需要沉著冷靜。有些時候可能需要我們Check最原始的資訊，切莫想當然。

建議：為了避免出現文章中提到的問題，第一，可以將ORACLE_SID等環境變數寫入到系統profile中，但需要確保系統profile檔案內容的有效性；第二，不在profile中進行填寫，每次登入資料庫伺服器時手工完成資料庫環境變數的指定，這種方法雖然增加了鍵盤的敲擊，但它更直觀、更有保障。

Good luck.

secooler
10.08.27

-- The End --

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29674916/viewspace-2122559/，如需轉載，請註明出處，否則將追究法律責任。

相關文章