Like this:

Related

I didn’t exactly understand at which point you actually used the flashback? During reinstate operation? And why did the first reinstate fail and you had to “startup mount” the database for it to succeed?

Other than that, it was a good post. Especially since we are planning to start using dataguard soon.

The first reinstate command failed because the database needs to be mounted and not opened.

The following error from $BDUMP/drcO10GR2.log tells me this.

Physical RSM: Reinstatement failed. Old primary database is OPEN, must be MOUNT before database reinstatement can be issued. Re-start database and startup to MOUNT, then re-issue the REINSTATE command.

Hence, I issued “startup force mount” against the former standby database and reissue “reinstate command”

Do we have to enable flashback on both primary and standby for reinstate to work? If I only need to enable flashback on primary, does it matter if i decided to keep flashback logs for 24 hrs or for just 1 hr for reinstate to work fine?

You just showed me that my documentation is lacking the information. I no longer have access to the system because I have since moved on. However, I believe you would have to enable flashback on both primary and standby. My documentation only shows standby though, which does not really makes sense.

If you reinstate the database within the time frame of the flashback log keep duration, then it should be fine.