How to relocate RAC VIPs and SCAN IPs between nodes in 12C

-
Below are the steps that is required to move Oracle RAC VIPs and SCAN IPs between RAC nodes.
IP Setup of the RAC as follows,
 ##Oracle RAC VIP##  
 10.10.38.70 racbprdb1-vip racbprdb1-vip.domain.int  
 10.10.38.71 racbprdb2-vip racbprdb2-vip.domain.int  
 ##Oracle SCAN IP##  
 10.10.38.72 scan-test    scan-test.domain.int  
 10.10.38.73 scan-test    scan-test.domain.int  
 10.10.38.74 scan-test    scan-test.domain.int

1. Check the current network config

 grid12c@racbprdb1:~$ srvctl config network  
 Network 1 exists  
 Subnet IPv4: 10.10.38.0/255.255.254.0/ipmp0, static  
 Subnet IPv6:  
 Ping Targets:  
 Network is enabled  
 Network is individually enabled on nodes:  
 Network is individually disabled on nodes:  
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ srvctl config scan  
 SCAN name: scan-test, Network: 1  
 Subnet IPv4: 10.10.38.0/255.255.254.0/ipmp0, static  
 Subnet IPv6:  
 SCAN 1 IPv4 VIP: 10.10.38.72  
 SCAN VIP is enabled.  
 SCAN VIP is individually enabled on nodes:  
 SCAN VIP is individually disabled on nodes:  
 SCAN 2 IPv4 VIP: 10.10.38.73  
 SCAN VIP is enabled.  
 SCAN VIP is individually enabled on nodes:  
 SCAN VIP is individually disabled on nodes:  
 SCAN 3 IPv4 VIP: 10.10.38.74  
 SCAN VIP is enabled.  
 SCAN VIP is individually enabled on nodes:  
 SCAN VIP is individually disabled on nodes:  
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ srvctl config vip -node racbprdb1  
 VIP exists: network number 1, hosting node racbprdb1  
 VIP Name: racbprdb1-vip  
 VIP IPv4 Address: 10.10.38.70  
 VIP IPv6 Address:  
 VIP is enabled.  
 VIP is individually enabled on nodes:  
 VIP is individually disabled on nodes:  
 grid12c@racbprdb1:~$ srvctl config vip -node racbprdb2  
 VIP exists: network number 1, hosting node racbprdb2  
 VIP Name: racbprdb2-vip  
 VIP IPv4 Address: 10.10.38.71  
 VIP IPv6 Address:  
 VIP is enabled.  
 VIP is individually enabled on nodes:  
 VIP is individually disabled on nodes:  
 grid12c@racbprdb1:~$

2. Moving SCAN IPs

In the initial state SCAN1 (10.10.38.72) is in node 1 while SCAN 2 and 3 (10.10.38.73/74) are in node2. Below commande will move scan 3 (10.10.38.74) to node1. (srvctl relocate scan_listener and srvctl relocate scan both has the same effect as SCAN ips are bind to the listener) 
 
grid12c@racbprdb1:~$ ps -ef | grep SCAN | grep -v grep  
  grid12c 3992   1  0 00:13:24 ?      0:02 /u01/app/12.2.0.1/grid/bin/tnslsnr LISTENER_SCAN1 -no_crs_notify -inherit  << Only SCAN 1 is Node 1
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ srvctl relocate scan_listener -scannumber 3 -node racbprdb1   
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ ps -ef | grep SCAN | grep -v grep   << Both SCAN 1 and SCAN 3 now in node 1
  grid12c 3992   1  0 00:13:24 ?      0:02 /u01/app/12.2.0.1/grid/bin/tnslsnr LISTENER_SCAN1 -no_crs_notify -inherit  
  grid12c 17313   1  0 15:21:51 ?      0:00 /u01/app/12.2.0.1/grid/bin/tnslsnr LISTENER_SCAN3 -no_crs_notify -inherit  
 grid12c@racbprdb1:~$

3. Moving RAC VIPs

RAC VIPs can be moved using below command. VIP change will not cause the corrosponging listner process to relocate. But in the SCAN move both the IP and the listener are moved. 
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ ifconfig -a | grep -i 38.70  
     inet 10.10.38.70 netmask fffffe00 broadcast 10.10.39.255 << VIP 1 (10.10.38.70) in node 1  
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ srvctl relocate vip -vip racbprdb1-vip -node racbprdb2  
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ ifconfig -a | grep -i 38.70 << VIP 1 Moved to node 2  
 grid12c@racbprdb1:~$  
 grid12c@racbprdb1:~$ ps -ef | grep -i tns | grep -v grep << Local Listener based on VIP 1 still in node 1  
  grid12c 3965   1  0 00:13:22 ?      0:02 /u01/app/12.2.0.1/grid/bin/tnslsnr LISTENER -no_crs_notify -inherit

Comments

Post a Comment

Popular posts from this blog

ORA-16433: The database or pluggable database must be opened in read/write

-
Image
ORA-16433 is an error returned when a database cannot be opened. This can be a result of multiple conditions including, The inconsistency of the database Physical corruption Loss of dependent files or access issues etc.. More often than not the solution is to recover from available backups, but there can be situations where backups are not available, specially on UAT or Test setups. Although not the ideal scenario, in this type of situation you might want to open the databases even with inconsistency.  In Comes --> _ALLOW_RESETLOGS_CORRUPTION First, if you are in a position to use _ALLOW_RESETLOGS_CORRUPTION=TRUE, that means it has to be a critical moment, and when you come across more ora- errors while you are trying to reopen the databsae, that can be annoying. Note - _ALLOW_RESETLOGS_CORRUPTION=TRUE must only be used after Oracle support confirmation as a last resort. Also make sure to take cold backup before proceeding. Basic steps to be followed to resolve ORA 16433 af...
Read more

Oracle Multitenant - Create new service for PDB using DBMS_SERVICE

-
Image
When an Oracle PDB is created it starts up a default service with the PDB name. For direct connections to    PDB this service can be used. But there are situations where new service name is required in PDB level, common example is after a PDB restoration/clone, in order to enable application connections without changes in connection string. Setting service_names parameter in PDB level is not possible hence it is not an option in multitenant setup. How to create a new PDB service on Oracle 12C Check the current services, here only the default service is running, SQL> show pdbs; CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 3 NFACTORPDB READ WRITE NO SQL> select service_id, name, pdb from dba_Services; SERVICE_ID NAME PDB ---------- ---------------------------------------- ---------- 7 nfactorpdb NFACTORPDB SQL> ...
Read more

Wait for unread message on broadcast channel - Blocking Sessions

-
Image
What is Wait for unread message on broadcast channel wait event? Wait for unread message on broadcast channel is a wait event where source destination communication is involved and the database is waiting for a reply from remote party. Mostly this wait is seen related to data pump export (expdp) or import (impdp) operations. Although categorized in idle wait class "Wait for unread message on broadcast channel" can become the blocking session for some other sessions. Common causes for stuck sessions waiting on this wait event includes, Broken databases links, where remote database is not responding. Abnormally killed remote processes causing the sessions to wait. When a session is waiting on "Wait for unread message on broadcast channel" it can become a blocking session for dependent sessions. Most probably these sessions will be waiting on "library cache pin" or related concurrency wait events. The blocking_session column of (g)v$session view...
Read more