Skip to Main Content
  • Questions

  • Attempting primary / standby's using same scan listener name and configuration on both clusters.

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Jeffrey.

Asked: April 03, 2019 - 12:59 pm UTC

Last updated: April 10, 2019 - 1:53 am UTC

Version: 11.2.0.4

Viewed 1000+ times

You Asked

Hi Tom,
I've never gotten through to you in 20 years, so hopefully you'll be available as I could use some sound advice (you're so in demand, I gave up about 10 years ago :-)
Here are the particulars:
* We're planning a migration from data center A to B.
* 11204 RAC to RAC migration using data guard physical.
* All db-related names are duplicates from one to the other including scan listener names.
* Hosts and IP's are different and of course db_unique_names will be unique for standbys.
* We don't want to change any tnsnames definitions on clients or applications
* The rac clusters support multiple linux/oracle IDs that own one or more databases each.
* We want to use data guard physical standbys to migration databases, however all databases
on each source host in A will not be migrated at the same time. So, to avoid modifying listener configurations, we are planning on adding the standby host and database definitions to the same single scan listeners and dns supporting two different clusters A and B. Then as we fail over each database from A to B, the idea is that the incoming tns connection will do round robin and won't find a "C" database running on an "A" host and move on to the next entry until it finds that "C" database running on the "B" host and make the connection.

That's the plan thus far and we have not tested it yet but assume it will work. We are setting up the test env now. Questions are:
1. Can you think of a smoother way to do this? We realize there will be some connection delay parsing through the scan listener list.
2. Will we need to create separate listeners for the redo transfer? A co-worker suggested that with all our databases, it could be very many listeners not only in B, but also in A because we would want to switch A to standby's until the entire migration is completed. He noted that it would be a lot of extra ports that would have to be opened up, although we might be able to use a single listener to support all the standby functionality separate from the scan listeners supporting the applications.
3. Would a tns connection attempt still be made to standby databases in this scenario since they are technically up and open read-only and if so; how to avoid that.

Thanks very much for any advice.

and Connor said...

Thanks for the detailed explanation. I spoke to the DataGuard PM and the RAC PM for some additional info. In a nutshell.

Re:

we are planning on adding the standby host and database definitions to the same single scan listeners and dns supporting two different clusters A and B


This will be fine because its how we currently do a failover configuration in our MAA configuration (ie, when you have a permanent standby RAC cluster rather than a transient one that you are proposing).

however all databases on each source host in A will not be migrated at the same time


This can be achieved with services (which I'm hoping you're already using). For each database, its services can be modified so that for your main site, the services are defined as primary, and the same service names are then defined for the standby. Because the services will be defined as "role aware", when you switchover a database from the main to the new site, the standby node becomes primary and the services there will become active. Rather than give an overly short description here - check the whitepaper below, which describes the full setup

https://www.oracle.com/technetwork/database/availability/s316927-1-175930.pdf

However, that brings me to

We don't want to change any tnsnames definitions on clients or applications


For applications to know about the services on both sites, they will *need* to have that in their tnsnames. I don't think you can escape this, because a tns entry will need to look something like:

(ADDRESS=(PROTOCOL=TCP)(HOST=old_data_centre)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=my_service_name))
(ADDRESS=(PROTOCOL=TCP)(HOST=new_data_centre)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=my_service_name))



Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

re: migration question

Jeff, April 09, 2019 - 12:32 pm UTC

Thank you Tom for addressing the question.
The MAA white paper discussion is so broad and I'm sure we don't need a lot of that functionality, although parts of it may be useful. Our goal is very specific; to migrate and not necessarily to provide site failover for MAA. It's hard to know exactly what extra configuration would be required to use parts of that technology.
We don't use ONS for example nor Data Guard Broker and I don't think we're concerned with oci and jdbc application connections and all the configuration required to support that.
Mostly though; if tnsnames have to be modified on all applications and client systems, it would not be our first choice. I think we're just going to have to do some testing and see what works. It could be that we don't even set up redo transfer. Maybe we just create a duplicate standby database and apply incremental backups once a week and one for final switchover.
Thank you very much for addressing the question.


Jeff

Connor McDonald
April 10, 2019 - 1:53 am UTC

Sorry, it wasn't my intent that you configure MAA - its more than the whitepaper talks about the steps to get a MAA-style standby configuration for switchover, which (from what I read from your question) is what you will *temporarily* want for the duration of the data migration.

With regard to:

Maybe we just create a duplicate standby database and apply incremental backups once a week

is that is the case, then why bother with standby at all. You could use transport database with incremental backups to perform the task? The outage duration would be the time taken for the last incremental backup, which you could minimize with block change tracking.

Hope this help.
more

Connor and Chris don't just spend all day on AskTOM. You can also catch regular content via Connor's blog and Chris's blog. Or if video is more your thing, check out Connor's channel and Chris's channel from their Youtube channels. And of course, keep up to date with AskTOM via the official twitter account.