Oracle Data Guard PING[ARC2]: Heartbeat failed to connect to standby ”. Error is 12514 故障分析

 

 

朋友搭建的一套DG，折騰了很長時間，一直都是報如下錯誤：

ORA-12514: TNS:listener does not currentlyknow of service requested in connect descriptor

PING[ARC2]: Heartbeat failed to connect tostandby 'PD'. Error is 12514.

 

這個錯誤最常見的原因，靜態註冊，再就是DG 參數的問題。

 

但這裡參數，我也瞅了半天，並沒有問題：

SQL> show parameter dest_2

 

NAME                                 TYPE        VALUE

----------------------------------------------- ------------------------------

db_create_online_log_dest_2          string

log_archive_dest_2                   string      SERVICE=PD VALID_FOR=(ONLINE_L

                                                OGFILE,PRIMARY_ROLE) DB_UNIQUE

                                                _NAME=PD

 

期間還讓朋友做了很多的測試，包括重建口令檔案，把DG 可能出現的問題，都想了一遍，還是有問題。

 

查看相關的進程：備庫沒有RFS進程，主庫沒有LNS進程。

SQL> select process, status, thread#,sequence#, block#, blocks from v$managed_standby;

 

PROCESS  STATUS          THREAD#  SEQUENCE#    BLOCK#     BLOCKS

--------- ------------ -------------------- ---------- ----------

ARCH     CONNECTED             0          0          0          0

ARCH     CONNECTED             0          0          0          0

ARCH     CONNECTED             0          0          0          0

ARCH     CONNECTED             0          0          0          0

 

後來讓朋友再次tnsping PD看看，其實這個測試，在最開始的時候，我就已經讓朋友測試過了。

 

tnsping 是正常的，也就是說，測試網路是通的，listener是正常的。 這個也是我們的tnsping 能乾的工作，但是tnsping 不能檢查tnsnames.ora 檔案裡的service_name或sid是否正確，所以也讓朋友貼了這2個檔案。

    並用sqlplus 串連了這個配置，也正常。

 

    問題看上去變得非常奇葩，因為DG本身就沒幾個參數，把我能想到的，問題都想了一遍，還有不通，後來看到朋友寫的測試結果：

 

 

 

[oracle@DB11g_ST trace]$ tnsping PD

TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 31-JUL-2013 16:11:18

 

Copyright (c) 1997, 2009, Oracle.  All rights reserved.

Used parameter files:

 

Used TNSNAMES adapter to resolve the alias

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

OK (10 msec)

 

對這裡的HOST 產生了興趣，之前懷疑過防火牆的問題，但防火牆是關閉的，所以讓朋友把這裡改成IP地址，居然OK了。

 

SQL> select process, status, thread#,sequence#, block#, blocks from v$managed_standby;

 

PROCESS  STATUS          THREAD#  SEQUENCE#    BLOCK#     BLOCKS

--------- ------------ -------------------- ---------- ----------

ARCH     CONNECTED             0          0          0          0

ARCH     CLOSING               1        156       2049       1600

ARCH     CONNECTED             0          0          0          0

ARCH     CONNECTED             0          0          0          0

RFS      IDLE                  0          0          0          0

RFS      IDLE                  0          0          0          0

RFS      IDLE                  0          0          0          0

RFS      IDLE                  1        157         27          1

 

這次查詢，RFS進程也出現了。

 

朋友主備庫的/etc/hosts 檔案是直接複製過去的。 如下：

 

[root@DB11g_ST ~]# more /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1               DB11g localhost.localdomain localhost

192.168.0.89            DB11g_ST

192.168.0.88            DB11g

 

問題就出在這裡，DB11g 這裡有個迴環地址：127.0.0.1。 後來朋友把這個注釋掉，使用別名測試，也正常了。

 

在這個問題裡面，饒了很大的一個圈子，之前我們一直圍繞在資料庫方面的思考，思考資料庫方面的哪些配置會導致這個問題。 直到最終發現問題的根源，是/etc/hosts的配置導致的。

 

 

昨天另一個朋友，也和我講了另一個事情，他們有個物化視圖，一直無法重新整理，表才2G，也不算太大。 但就是重新整理不了。 後來也是研究了很長的時間，最後定位出來是防火牆問題，裡面有禁止大包的傳送，把兩邊防火牆這個規則去掉就好了。

 

由這個故障的處理過程，我們要反思的是，在我們處理故障時候，不要總是局限在資料庫這個層面，可能其他的配置，也會導致這個問題。在故障處理過程中，要想起拓展我們的思維，不要在自己的小巷思維裡饒的太久了。

 

 

 

 

 

 

 

--------------------------------------------------------------------------------------------

著作權，文章允許轉載，但必須以連結方式註明源地址，否則追究法律責任!

QQ:      251097186

Skype:    tianlesoftware

Email:    tianlesoftware@gmail.com

Blog:     http://blog.csdn.net/tianlesoftware

Weibo:    http://weibo.com/tianlesoftware

Twitter:  http://twitter.com/tianlesoftware

Facebook: http://www.facebook.com/tianlesoftware

Linkedin: http://cn.linkedin.com/in/tianlesoftware