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