RDBMS / RAC / EXADATA-- switching Scan names -- removing the need for modifying the connection strings after a migration

Recently started a big " ECM ( Exadata Cloud Machine Migration) - OCM (Oracle Cloud Machine)" migration project..

In this exciting project, I will play the lead consultant role for both database and application migrations..

Databases in the scope are Oracle 11gR2 databases, and they all will be migrated to ECMs.

Applications, on the other hands, are running on WebSphere and they all will be migrated to the WebLogic instances running on OCMs.

My team is responsible the project as an whole. From analysis, to Planning & From planning to Execution..

As you may guess, the downtime is very important..

In other words, the methods that we should use for the migration of these databases, should require a minimum downtime..

The platforms of the databases, which are in the scope of this project, varies..

That is, some of these Oracle databases are running on AIX-IBM Power platforms and some of them on LINUX-INTEL Platforms.

As a result of these varying platforms & the need for having the minimum downtime; we are working on several migration plans.

For Linux-Intel Platform, we are mainly focused on the Dataguard based migration strategies, and this blog post will be based on a little method that we used while doing one of our migration POCs for proving Oracle's Dataguard technology.

Most of you may already know that, in order to migrate a database using Dataguard switchover or failover methods, we first create a standby database in the target site.

Then we use Oracle's managed recovery (Dataguard) to make it be sync with the primary.

Once the standby database becomes sync with the primary, we schedule a small downtime and do the switchover operation in this planned maintanence window.

After a successful switchover operation, our new primary starts running in the target site. (read-write)

This new primary will be running on a different platform, with different "management ip addresses, hostnames, virtual hostnames, virtual ip addresses, scan ip addresses and scan names".

As a result, we normally tell our clients & application owners to change their connections strings (java jdbc urls, tnsnames.ora and etc..) accordingly.

However, what we have done in one of our POCs, was a little different..

I mean, we did a switchover and make the primary database be activated on the target site.. But after that, we didn't tell our clients and application owners to change their connection strings..

There was no need for that..

Why? Because, we switched the scan names between the target and the source platform.

Here is the time flow of this operation:

t0: exax6 's scan name: exaxxx & exax7's scan name: exax7
t1: exax6 's scan name : exax6old & exax7's scan name: exax7
t2: exax6 's scan name : exax6old & exax7's scan name: exaxxx

So the new primary (its scan listeners actually) started listening on the same scan name, as the old primary. ( Although the scan IP addresses of the new primary is different than the old primary)

By doing this, we gained time & we didn't spend any extra efforts for changing the application connection strings..

Well... Let's look at the technical side of this operation;

Our source platform was an Exadata X6-2, and our target platform was an Exadata X7-2.

So, after the Dataguard-based switchover operation, we did the following ;

***We first changed the scan name of the source platform (Exa X6-2) and make it exax6old.. (it was exaxxx before this change)..

In order to do this, we took the following actions;

--Stopped the scan listeners and scan itself using Grid user (in our case it was oracle)

$GRID_HOME/bin/srvctl stop scan_listener
$GRID_HOME/bin/srvctl stop scan

--We said the DNS team to update scan-related DNS definitions of Exa X6-2 and made them exax6old.

--Then, we checked our server (Exadata X6's db nodes) and confirmed that these new hostnames could be resolved .

-- modified the scan name as root user

$GRID_HOME/bin/srvctl modify scan -n exax6old

--made the modification for the scan resources & confirmed the change, -- as the grid user.

$GRID_HOME/bin/srvctl modify scan_listener -u
$GRID_HOME/bin/srvctl start scan_listener
$GRID_HOME/bin/srvctl config scan
$GRID_HOME/bin/srvctl config scan_listener

*** After changing the scan name of our source platform, the old scan name of the source platform became available to be used for our target platform.

--So, this time in target (Exa X7-2), we stopped scan listener and scan itself using Grid user (in our case it was oracle)

$GRID_HOME/bin/srvctl stop scan_listener
$GRID_HOME/bin/srvctl stop scan

--We said the DNS team to add the former scan-related DNS definitions of the source platform and made them to be resolved using the target platform's scan IP addresses.

--Then, we checked our server (Exadata X7's db nodes) and confirmed that these new hostnames (scan names) could be resolved properly. We needed the clear the OS DNS cache (even reboot may be required) to make the target platform to resolve its scan ip address using newly mapped scan names.

-- modified the scan name as root user

$GRID_HOME/bin/srvctl modify scan -n exaxxx

--Lastly, made the modification for the scan resources & confirmed the change, -- as the grid user.

$GRID_HOME/bin/srvctl modify scan_listener -u
$GRID_HOME/bin/srvctl start scan_listener
$GRID_HOME/bin/srvctl config scan
$GRID_HOME/bin/srvctl config scan_listener

Reference for this operation: How to Modify SCAN Setting or SCAN Listener Port after Installation (Doc ID 972500.1)

Note that, this approach is applicable in environments where all the clients and applications are using scan names (scan listeners) to connect to the databases.