Dataguard: switchover-switchback

[Former Member]

Dears,

I'm going to setup a dataguard scenario (1 primary and 1 stanby database) with ora 10204.

I would like to setup up also the switchover-switchback feature, but I have a question on it.

The rebuild of the stanby after an activation require to restore the whole stanby database from the primary environment.

I would like to use the switchover to solve this problem.

Suppose the customer want to test the quality of data of the stanby periodically (ie every week)

Instead to activate every time the stanby , I suppose to do the switchover of the stanby to primary, and at the same time to do the switchover of the primary to standby.

At that point the customer can verify the quality of data, and at the end I should be able to do the switchback of the databases to their original status.

The questions are :

1) what happen if a leave the primary as primay when I do the switchover of the stanby to a primary ?

Pratically I will have two primary database. Right ?

2) suppose the primary goes down and is not reachable at all (so the disaster happen).

It will be possible to do the switchover to a primary for the stanby and then , when the primary is rebuilt (in this case as stanby) to exchange their role using the switchback statements ?

regards

[stefan_koehler · Accepted solution]

Hello Roberto,

> 1) what happen if a leave the primary as primay when I do the switchover of the stanby to a primary ? Pratically I will have two primary database. Right ?

Your question is answered in the oracle data guard (broker) documentation:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/dgmgrl.htm#DGBKR740

http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/sofo.htm#BCGIAFFJ

> It will be possible to do the switchover to a primary for the stanby and then , when the primary is rebuilt (in this case as stanby) to exchange their role using the switchback statements ?

Check the definition here:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/sofo.htm#BCGIAFFJ

This scenario is not a switchover, it is a failover and if you have to rebuild or not depends on some factors. These scenarios are also described very well in the documentation:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14230/sofo.htm#CHDEHEEF

Regards

Stefan

[Former Member · Accepted solution]

Thanks for the feedback.

Sorry I would like to ask some clarification about point 2)

"It will be possible to do the switchover to a primary for the stanby and then , when the primary is rebuilt (in this case as stanby) to exchange their role using the switchback statements ?"

We suppose to rebuil dthe primary after a disaster with a backup of the primary itself, not using the standby.

Which other factors can be involved to clarify this scenario ?

regards

[stefan_koehler · Accepted solution]

Hello Roberto,

> We suppose to rebuil dthe primary after a disaster with a backup of the primary itself, not using the standby.

In general this is possible. But you have to keep in mind of the standby controlfile and added datafiles after the backup.

I think you have some misconception about standby and primary. These are just some roles with some physical changes (standby controlfile for example). You can switch any time between these roles.

So if you have activated your standby as primary, then you can also take a backup of this database and rebuild the "new" standby from this one. The previously activated standby database will be your primary as long as you don't perform a switch or fail-over.

I also suggest to use RMAN for these scenarios.

Regards

Stefan

[Former Member · Accepted solution]

Thanks for the feedback, I read the oracle documentation you indicated.

Anyway my scenario is quite different, as it's a Sap database a lot of Oracle features mentionated is not in use (like the broker, fast-stanby and so on..)

I have still some dubts. I'm not able to find in the documentation if the transition from the stanby to the primary role is possible in case the of a failure of the primary.

The documentation says the switchover is usefull in planned situations , like to reduce the downtime when is necessary to do hardware or software maintenance on the primary , so in these case you have time to move the stanbdy to a primery role and the primary to a stanby and then to close it for maintenence.

But It's not clear if in case of a failure of the primary it is possible to promote the transition of the standby to the primary role or insteadt it is only possible to do the activation of the stanby in order to be able to open Sap and allow the users to work.

regards

[Former Member · Accepted solution]

up plz

In my opinion It's an argument very interesting and it can be very usefull

[stefan_koehler · Accepted solution]

Hello Roberto,

> Anyway my scenario is quite different, as it's a Sap database a lot of Oracle features mentionated is not in use (like the broker, fast-stanby and so on..)

Why is your scenario different? I guess you don't have any training in "Oracle Data Guard" and you don't want to use the Data Guard Broker ... hmm you are a really tough guy )

> But It's not clear if in case of a failure of the primary it is possible to promote the transition of the standby to the primary role or insteadt it is only possible to do the activation of the stanby in order to be able to open Sap and allow the users to work.

If the primary fails you have to perform a fail-over. Anything else would make no sense, because of you can't ship any redo log / meta / configuration data to the "new" standby site anymore. It also depends on your protection mode, if you can work with the primary database, if the standby crashed. Just think about it.

Regards

Stefan

[Former Member · Accepted solution]

Yes, on all the standby DB I did the failover is always manual and the protection mode is always the default, the maximum performance mode. All of them are working fine.

I always leaved off the the DGMGRL utility.

Yes, now it's clear the switchover cannot be used in case of a crash of the primary DB.