探究Oracle監聽超時故障

2019-04-03 05:06:20江蘇繆振龍

網絡安全和信息化 2019年3期

關鍵詞：故障服務

■ 江蘇繆振龍

編者按：本文是筆者親歷的一次Oracle TNS連接超時引起的故障，雖然看似疑難，但最終發現是由于一個簡單的配置文件錯誤導致。

筆者最近準備對一臺Oracle 10g數據庫進行數據備份，采用exp方式全庫導出。但嘗試多次，一直提示如下錯誤：

EXP-00056: ORACLE error 12170 encountered

ORA-12170: TNS:Connect timeout occurred

EXP-00000: Export terminated unsuccessfully

經查閱相關資料得知，“EXP-00056”產生錯誤的原因是“ORA-12170”。具體來說是由于TNS連接超時導致。

TNS是Oracle Net的一部分，用來管理和配置Oracle數據庫和客戶端的連接工具，客戶端只有正確配置TNS相關文件才能訪問Oracle服務器。

故障分析

在日常維護中通常使用tnsping命令檢查Oracle監聽服務和網絡連通性。筆者首先在服務器上tnsping實例名orcl，發現等了很久，返回操作超時錯誤。信息如下：

-bash-3.2$ tnsping orcl

TNS Ping Utility for Solaris: Version 10.2.0.1.0 - Production on 18-JAN-2019 19:58:22

Used parameter files:

/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact(DESCRIPTION = (ADDRESS= (PROTOCOL = TCP)(HOST= SUN)(PORT = 1521))(CONNECT_DATA = (SERVER =DEDICATED) (SERVICE_NAME= orcl)))

TNS-12535: TNS:operation timed out

接下來，筆者tnsping本機IP，返回結果正常。如下：

-bash-3.2$ tnsping 172.28.28.36

TNS Ping Utility for Solaris: Version 10.2.0.1.0 - Production on 18-JAN-2019 20:08:50

Used parameter files:

/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora

Used EZCONNECT adapter to resolve the alias

Attempting to contact

(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=172.28.28.36))(ADDRESS=(PROTOCOL=TCP)(HOST=172.28.28.36)(PORT=1521)))

OK (0 msec)

筆者懷疑監聽服務存在問題，執行“lsnrctl stop” 和“lsnrctl start”命令來重啟監聽服務，發現故障提示依舊。接著執行“lsnrctl status”查看監聽服務狀態。返回結果如圖1所示。

通過最后兩行，我們可以看出實例orcl監聽處于未知狀態。orcl實例沒有注冊到監聽服務中。于是，通過SQLPlus工具登錄數據庫進行實例注冊。具體方法如下：

-bash-3.2$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jan 18 20:10:51 2019

SQL> conn system/rs_789 as sysdba;

Connected.

SQL> alter system register;

System altered.

圖1 執行lsnrctl status查看監聽服務狀態

圖2 查看Oracle監聽服務相關日志

再次使用“lsnrctl status”命令查看監聽服務狀態，發現故障提示依舊。那看看配置文件是不是有問題呢？查看tnsnames.ora文件。配置如下：

ORCL =

(DESCRIPTION =

(ADDRESS =(PROTOCOL = TCP)(HOST =SUN)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME =orcl)

)

EXTPROC_CONNECTION_DATA =

(DESCRIPTION=

(ADDRESS_LIST =

(ADDRESS =(PROTOCOL = IPC)(KEY = EXTPROC1))

)

(CONNECT_DATA =

(SID =PLSExtProc)(PRESENTATION =RO)

)

該配置文件并未發現什么異常。接下來，筆者又查看了Oracle監聽服務相關日志。最后幾行日志如圖2所示。

上面一直有警告提示，“Subscription for node down event still pending”。

故障解決

經上網查詢相關資料，此錯誤引起的原因可能由于監聽無法在指定端口啟動，前一次監聽服務未正常退出或有其他程序占用端口。提示查看/etc/hosts相關配置。于是，筆者打開/etc/hosts文件，配置如下：

-bash-3.2$ cat /etc/hosts

# Internet host table

::1 localhost

127.0.0.1 localhost

222.*.*.* SUN loghost

172.28.28.36 WWW

果然發現一些問題，由于當時服務器要對外網開放使用，服務器同時接入內網和外網。但后來處于網絡安全考慮，所有服務器的外網都統一轉移到上層硬件防火墻進行訪問控制。服務器只接入內網。但/etc/hosts的配置信息并沒有做相應修改。既然問題已找到，于是修改/etc/hosts文件，注意要先切換到root用戶，配置完成后要使用“wq!”，強制保存退出。更改后配置如下：

-bash-3.2# cat /etc/hosts

# Internet host table

::1 localhost

127.0.0.1 localhost

172.28.28.36 SU

最后再切換到Oracle用戶下，執行lsnrctl stop命令和lsnrctl start命令重啟監聽服務。剛開始監聽服務還處于未知狀態，稍等約1分鐘，再次執行lsnrctl status命令，可以看到實例監聽處于Ready狀態。返回如下信息：

-bash-3.2$ lsnrctl status

LSNRCTL for Solaris:Version 10.2.0.1.0 -Production on 18-JAN-2019 20:11:35

Connecting to (DESCRI PTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))

STATUS of the LISTENER

……

(DESCRIPTION=(AD DRESS=(PROTOCOL=tcp)(HOST=172.28.28.36)(PORT=1521)))

Services Summary...

Service "PLSExtProc"has 1 instance(s).

Instance"PLSExtProc", status UNKNOWN, has 1 handler(s)for this service...

Service "orcl" has 2 instance(s).

Instance "orcl",status UNKNOWN, has 1 handler(s) for this service...

Instance "orcl",status READY, has 1 handler(s) for this service...

Service "orclXDB" has 1 instance(s).

Instance "orcl",status READY, has 1 handler(s) for this service...

Service "orcl_XPT"has 1 instance(s).

Instance "orcl",status READY, has 1 handler(s) for this service...

The command completed successfully

通過本次故障可以發現，一個看似疑難的故障問題往往是由一個簡單的配置文件錯誤導致。所以，在我們今后的工作中，一定要扎扎實實學好理論基礎，面對故障問題才能迎刃而解。