Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question.

Asked: April 21, 2017 - 11:23 am UTC

Last updated: April 26, 2017 - 4:18 am UTC

Version: 11.2.0.4 and 12.1.0,2

Viewed 1000+ times

You Asked

We currently have a production database 11.2.0.4 (A) and an active physical standby (PSA). we are in the process of developing migration code for this database because it is vendor supplied schemas. The target database is 12.1.0.2 (B). when we go to do this in prod, this is what we were planning to do
1. Stop all traffic to database A and point read only traffic to PSA.
2. Run the migration from A to B
3. After the migration is complete, stop traffic to PSA and reroute to database B
4. Create DR for database B

In the above scenario when we are in 1, we are operating without a DR. if the server for database PSA goes down we have full outage. In this scenario is there something else better that we can do ?

and Connor said...

There is no limit to the number of standby databases you can have, with the caveat that you need to have a licensed server. So you *could* do something like:

0. Create PSA#2, leave PSA#1 in place
1. Stop all traffic to database A and point read only traffic to PSA#2.
2. Run the migration from A to B, archivelogs etc still get sent to PSA#1
3. After the migration is complete, drop PSA#2 and reroute to database B
4. DR for database B is already done, because PSA#1 has been updated during the exercise

This of course depends on what you mean by "migration". I'm assuming a standard upgrade from 11 to 12 here.

If it was something more significant, then you could tackle things via a different route, that of minimising the outage window to almost zero using transportable database.

An *outline* of the process is here on my blog

https://connormcdonald.wordpress.com/2015/06/06/cross-platform-database-migration/

but there are more detailed instructions on MOS.

Rating

  (1 rating)

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

Comments

A reader, April 24, 2017 - 7:15 pm UTC

This is not a standard upgrade. We are going to run some home grown conversion process because the schemas between the old application version and the new have changed. So we kind of remap the existing data to new schema pattern. we will have the final remapped data in another set of schemas in 11g and we have to port the remapped data as is to 12c.

So lets say currently we have schemas 11a and 11b on tablespaces data11 and idx11. we are going to create schemas 11c and 11d on tablespaces newdata11 and newidx11 and newlob11 which is going to have the remapped data. we have to copy tablespaces newdata12, newidx12 and newlob12 to the 12c database in the same server. whats the best way to do this ? i will read the article in the link also.

Thanks again.
Connor McDonald
April 26, 2017 - 4:18 am UTC

In that case, I'd be inclined to go with the 2 x standby option I first suggested.