Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to solve the abnormal client connection after the modification of scanip in the RAC database environment". The explanation in the article is simple and clear, easy to learn and understand, and now please follow the editor's train of thought to slowly deepen, to study and learn "how to solve the abnormal client connection after the RAC database environment modifies scanip".

Summary: one set of rac database needs to be migrated to another set of rac on a certain project. The network segment and database name of the two sets of rac are the same. After the migration, it is found that the new data will still be inserted into the old database, but there is no new data in the new database.

1. Introduction to the scene

On a certain project, you need to migrate one set of rac database to another set of rac. The network segment and database name of these two sets of rac are the same. Here, the old rac environment is called rac a, and the new rac environment is called rac b. When we formally migrate the database, we find a problem. Even though the scan ip of rac b is the same as the rac scan ip of rac a, it is found that the program is still connected to the old database rac an after the migration. All the data is stored in the old database, and there is no new data into the new rac b.

After investigation, it is found that rac aPowerRAC b does not restart the database or cluster after modifying the scan ip. In addition, there is no problem with the database connection string of the application program. Why the data is still inserted into the old database? after the following scenario simulation, you can get the answer.

Second, scene reproduction

Two sets of rac environments are deployed locally, and the network segments are the same, except that the db_name is different.

Rac a

Db_name:orcldb

Post-deployment scan ip:172.16.4.125

Proposed to modify the new scan ip:172.16.4.140

Rac b

Db_name:orcl

Post-deployment scan ip:172.16.4.135

Proposed to modify the new scan ip:172.16.4.125 (rac b uses scan ip for rac a)

The above is to simulate whether the client program can connect to the correct database without changing the database connection string after the database migration.

Use the client to connect 2 sets of rac scan ip

Check the dbid of rac a _ r _ RAC b before connecting to facilitate verification later.

Scenario 1:sqlplus uses 172.16.4.125 to connect to rac b

Result: unable to connect to rac b

The scenario 2:sqlplus uses the same scan ip 172.16.4.125, but the service name uses the db_name of rac a

Result: after viewing dbid, the database that the client actually connects to is rac a, not rac b

Scenario 3: restart the database on rac b and the customer connects again

Result: after rac b restarts, it is the real database that checks the dbid,sqlplus connection

The reason why there is no problem in migrating data from one rac to another rac in the project environment is that the migrated scan ip and db_name are exactly the same, but the database is not restarted, so it is difficult to expose the problem on the project site.

III. Verification summary

According to the above experiments, you need to restart the database after modifying the rac scan ip. In addition, it is found that this is the bug of 11g rac on MOS 1373350.1. If you do not restart the database, you can also reset the remote_listener parameter. Although it is said on mos that it has been fixed at 11.2.0.3, this bug can still be available on 11.2.0.4.

The mos documentation is as follows:

Top Issues That Cause Troubles with SCAN VIP and Listeners (document ID 1373350.1) Issue # 5: Service not getting registered with SCAN listener after failover of the SCAN listenerAfter 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=':'; 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 multiple times should display SCAN VIP in round-robin fashion E. do not set SECURE_REGISTER_ in listener.ora if the class of secure transports (COST) is not configured. Thank you for your reading, the above is the content of "how to solve the abnormal client connection after modifying scanip in RAC database environment". After the study of this article, I believe you have a deeper understanding of how to solve the problem of abnormal client connection after the modification of scanip in RAC database environment, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.