Oracle備庫TNS連線失敗的分析

今天在測試12c的temp_undo的時候，準備在備庫上測試一下，突然發現備庫使用TNS連線竟然失敗。

丟擲的錯誤如下：

$ sqlplus sys/oracle@testdb as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 8 15:30:10 2016
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor

嘗試連線PDB也是同樣的錯誤。

檢視$ORACLE_HOME/network/admin/listener.ora的配置。

已經做了靜態註冊.

SID_LIST_LISTENER_12c_1526=
(SID_LIST=
      (SID_DESC=
      (GLOBAL_DBNAME=testdb)
      (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1)
      (SID_NAME=testdb)
     )
     (SID_DESC=
      (GLOBAL_DBNAME=test)
      (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1)
      (SID_NAME=testdb)
））   

檢視tnsnames.ora的配置也沒有問題，

test =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = xxx)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = test)
      (SERVER = DEDICATED)
    )
  )

隨便檢視了一個監聽的配置，比如1526

lsnrct status listener_12c_1526,輸出也全然沒有什麼問題，所以自己感覺這問題越發奇怪，甚至還想，莫非又碰到了12c的一個bug了。

如果備庫在ADG模式，備庫TNS不可用，那備庫就沒有什麼其他的意義了。

這個時候我們還是來看看監聽日誌，到指定目錄下，發現了下面的內容。Thu Dec 08 14:43:17 2016
08-DEC-2016 14:43:17 * (CONNECT_DATA=(SERVICE_NAME=test)(SERVER=DEDICATED)(CID=(PROGRAM=sqlplus)(HOST=testdb2.cyou.com)(USER=oracle)
)) * (ADDRESS=(PROTOCOL=tcp)(HOST=xxxx)(PORT=2437)) * establish * test * 12514
TNS-12514: TNS:listener does not currently know of service requested in connect descriptor
Thu Dec 08 14:44:46 2016

看著這段內容，感覺哪裡好像不大對勁，但是又實在說不出。

檢視MOS，和主庫反覆做監聽配置的比對，也沒有發現問題，一籌莫展的時候，決定從頭開始來看待這個問題。

監聽的配置沒有問題，根據錯誤只能指向監聽的狀態了。

我們來看看監聽的程式狀態

00:14:32 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1522 -inherit
00:13:43 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1528 -inherit
00:25:48 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1525 -inherit
00:14:35 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1523 -inherit
00:00:47 /home/U01/app/oracle/product/12c/db_1/bin/tnslsnr listener_12c_1526 -inherit
00:17:28 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER -inherit

看到這裡，決定面壁5分鐘。

原來我這個庫上最早是安裝了11g的ORACLE_HOME,沒想到後來整合系統的時候，用了12c,搭建備庫的時候，因為主備庫的連線配置只設定了1526的埠，其它的都沒動，所以n多天後用起來的時候，栽在了這裡。

所以修復方式就很簡單了，切換到11g的ORACLE_HOME，把之前的監聽都停止，然後重新啟動12c的監聽即可。

所以說透過這個簡單的問題，其實可以總結出很多小經驗。

1. 問題解決不能止步於當前，因為偷懶，疏忽導致的後來的潛在問題，遺留問題

2. 另外一個是標準化，規範化的使用。無規矩不成方圓。

3. 測試驗證，備庫搭建完成後，可以做一些簡單的應用測試，保證備庫在ADG模式下可用

4. 這個過程中，有一個推理的邏輯不夠嚴謹，連線的埠是1521，而我是用1526來做的簡單驗證。

5. 儘管這是一個測試環境，但是還是需要引以為戒。