怎么解決RAC數據庫環境修改scanip后客戶端連接異常

這篇文章主要講解了“怎么解決RAC數據庫環境修改scanip后客戶端連接異常”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么解決RAC數據庫環境修改scanip后客戶端連接異常”吧！

摘要：在某個項目上需要將1套rac數據庫遷移到另外1套rac，這2套rac的網段一致、數據庫名一致。在遷移之后發現新的數據還是會往老的數據庫插入，然而新數據庫并沒有新增數據

一、場景簡介

在某個項目上需要將1套rac數據庫遷移到另外1套rac，這2套rac的網段一致、數據庫名一致。這里將老的rac環境稱作rac a，新的rac環境稱作rac b，在正式遷移數據庫的時候發現一個問題，即使rac b的scan ip與rac a的rac scan ip相同，然而在遷移后發現程序連的還是是老數據庫rac a，數據全部存在了老的數據庫內，并沒有新數據進新的rac b。

經過排查后發現，rac a，rac b在修改scan ip之后并沒有重啟數據庫或者集群，另外應用端程序的數據庫連接字符串也沒有問題，為什么數據還是會插入到老數據庫，經過如下一番場景模擬之后，可以得到答案。

二、場景復現

本地部署了2套rac環境，網段一致，唯一不同的是db_name不一樣
rac a
db_name:orcldb
部署后scan ip：172.16.4.125
擬修改新scan ip：172.16.4.140

rac b
db_name:orcl
部署后scan ip：172.16.4.135
擬修改新scan ip：172.16.4.125 （rac b使用rac a的scan ip）

以上是為了模擬數據庫遷移后，客戶端程序在不改變數據庫連接字符串的情況下，是否可以連接正確的數據庫

使用客戶端分別連接2套rac scan ip
在連接之前先查看rac a，rac b的dbid方便后面做驗證

情景1：sqlplus使用172.16.4.125連接rac b

結果：無法連接rac b

情景2：sqlplus使用相同的scan ip 172.16.4.125，但是服務名用的是rac a的db_name

結果：查看dbid后，客戶端實際連接的數據庫是rac a，并非是rac b

情景3：在rac b上重啟數據庫，客戶再次連接

結果：rac b重啟之后，查看dbid，sqlplus連接的才是真正的數據庫
在項目環境中遷移數據從一個rac到另外一個rac當時之所以沒有發現問題，是因為遷移之后的scan ip、db_name都與原來一模一樣，但是數據庫并沒有重啟，所以很難在項目現場暴露出問題。

三、驗證總結

經過上述實驗可知，修改rac scan ip之后需要重啟要數據庫，另外在MOS 1373350.1上發現此為11g rac的bug，如果不重啟數據庫，也可以通過重置remote_listener參數解決。mos上雖然說在11.2.0.3已經修復，但是在11.2.0.4依然可以有此bug
mos 文檔如下：

Top Issues That Cause Troubles with SCAN VIP and Listeners (文檔 ID 1373350.1)
Issue #5: Service not getting registered with SCAN listener after failover of the SCAN listener
After SCAN VIP and SCAN listener failover, instance does not register with the SCAN listener. 
It might happen for only 1 of the scan listener. Client connection gets intermittent ORA-12514 TNS:listener does not currently know of service requested in connect descriptor.
Causes:
1. Unpublished Bug 12659561  after scan listener failover, database instance might not register to the scan listener (refer  Note 12659561.8 ), fixed in 11.2.0.3.2, merge patch 13354057 for 11.2.0.2 available for certain platform. 
2. Unpublished Bug 13066936  Instance does not register services when scan fails over (refer  Note 13066936.8 ) 
Solutions: 
1) For both above bugs, the workaround is to unregister and register remote listener on the database instance which does not register to a SCAN listener with following steps. 
show parameter remote_listener 
alter system set remote_listener=''; 
alter system register; 
alter system set remote_listener='<scan>:<port>'; 
alter system register; 
2) Other points to check if service is not registered with SCAN listener: 
a. remote_listener and local_listener is defined correctly 
b. EZCONNECT is defined in sqlnet.ora, eg: NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) 
c. SCAN name with 3 IPs should NOT be defined in /etc/hosts, it should be defined in DNS 
d. running nslookup <scan> multiple times should display SCAN VIP in round-robin fashion 
e. do not set SECURE_REGISTER_<listener> in listener.ora if the class of secure transports (COST) is not configured.

感謝各位的閱讀，以上就是“怎么解決RAC數據庫環境修改scanip后客戶端連接異常”的內容了，經過本文的學習后，相信大家對怎么解決RAC數據庫環境修改scanip后客戶端連接異常這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！