怎么解決RAC數(shù)據(jù)庫環(huán)境修改scanip后客戶端連接異常

這篇文章主要講解了“怎么解決RAC數(shù)據(jù)庫環(huán)境修改scanip后客戶端連接異常”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么解決RAC數(shù)據(jù)庫環(huán)境修改scanip后客戶端連接異?！卑?！

摘要：在某個項目上需要將1套rac數(shù)據(jù)庫遷移到另外1套rac，這2套rac的網(wǎng)段一致、數(shù)據(jù)庫名一致。在遷移之后發(fā)現(xiàn)新的數(shù)據(jù)還是會往老的數(shù)據(jù)庫插入，然而新數(shù)據(jù)庫并沒有新增數(shù)據(jù)

一、場景簡介

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

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

二、場景復(fù)現(xiàn)

本地部署了2套rac環(huán)境，網(wǎng)段一致，唯一不同的是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）

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

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

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

結(jié)果：無法連接rac b

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

結(jié)果：查看dbid后，客戶端實際連接的數(shù)據(jù)庫是rac a，并非是rac b

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

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

三、驗證總結(jié)

經(jīng)過上述實驗可知，修改rac scan ip之后需要重啟要數(shù)據(jù)庫，另外在MOS 1373350.1上發(fā)現(xiàn)此為11g rac的bug，如果不重啟數(shù)據(jù)庫，也可以通過重置remote_listener參數(shù)解決。mos上雖然說在11.2.0.3已經(jīng)修復(fù)，但是在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數(shù)據(jù)庫環(huán)境修改scanip后客戶端連接異?！钡膬?nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么解決RAC數(shù)據(jù)庫環(huán)境修改scanip后客戶端連接異常這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！