摘要：在某个项目上需要将1套rac数据库迁移到另外1套rac，这2套rac的网段一致、数据库名一致。在迁移之后发现新的数据还是会往老的数据库插入，然而新数据库并没有新增数据。
2套RAC环境修改scanip后客户端连接异常
一、场景简介
在某个项目上需要将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之后并没有重启数据库或者集群，另外应用端程序的数据库连接字符串也没有问题，为什么数据还是会插入到老数据库，经过如下一番场景模拟之后，可以得到答案。
原文链接（戳原文提升阅读体验）： https://www.modb.pro/db/22963?cyn
二、场景复现
本地部署了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.