Tag Archives: duplicate

Reinstate an Oracle Database after failover without Flashback logging enabled

Posted on by
Reply

The key difference between a switchover and a failover in Data Guard is the synchronization between primary and standby to avoid data loss.

Switchover
A switchover is a planned event. The primary and standby databases synchronize to allow a smooth, lossless role reversal:

  • The primary database stops the activity.
  • It writes a “redo marker” to the redo stream.
  • It flushes all the remaining redo to the standby.
  • The standby applies all the redo and, upon reaching the marker, knows it’s up to date and can open as the new primary.
  • Finally, the old primary becomes a standby and starts recovering changes from the new primary.

Failover
A failover usually happens after the primary becomes unavailable. Unlike a switchover, the new primary may not have all the latest redo from the old primary, even in synchronous mode because in-progress changes can exist past the last transmitted redo. As a result, their timelines diverge. The former primary (and possibly other standbys) must be reinstated to rejoin the configuration.

Flashback and Reinstate
Oracle’s Flashback Database feature allows you to rewind a database to a specific point in time. This makes recovering a failed primary much faster and easier because it does not require a full restore.
With Flashback enabled, the Data Guard Broker can quickly reinstate the former primary after a failover with a single command:

A customer recently asked how to reinstate a former primary when Flashback Logging is disabled.
Although we strongly recommend enabling Flashback Logging, some environments cannot support it due to storage constraints.
In such cases, you can still reinstate the database manually. Here’s how.

Step-by-step: reinstate a database from a backup and re-enable it in the broker

We are in a Maximum Performance configuration:

Let’s fail over:

Then restart the former primary in MOUNT mode:

The broker now says the former primary requires a reinstate:

As I said, we can’t proceed with a normal reinstate if there’s no flashback:

Let’s restore! This is the only way to bring a database to a past point in time if there is no flashback logging.

First, we put the DB in nomount mode to restore the standby controlfile:

Then we wipe out the directory that contains the DB (careful with this command!)

We restore the standby controlfile and the database:

Now let’s enable the freshly reinstated standby database:

Oups, I made a mistake. The Real-Time Apply isn’t working. Of course! I also deleted the standby logs, so I need to clear them.

Everything looks good now.

HTH
Ludovico

Block Change Tracking and Duplicate: avoid ORA-19755

Posted on by
11

If you use Block Change Tracking on your production database and try to duplicate it, you there are good possibilities that you will encounter this error:

The problem is caused by the block change tracking file entry that exists in the target controlfile, but Oracle can’t find the file because the directory structure on the auxiliary server changes.

After the restore and recovery of the auxiliary database, the duplicate process tries to open the DB but the bct file doesn’t exist and the error is thrown.

If you do a quick google search you will find several workarounds:

  • disable the block change tracking after you get the error and manually open the auxiliary instance (this prevent the possibility to get the duplicate outcome from the rman return code)
  • disable the BCT on the target before running the duplicate (this forces your incremental backups to read all your target database!)
  • Richard Harrison proposed another workaround, you can read more about it here.

There is another workaround that I like more (and that you can also find as comment in Richard’s post):

  • Disable the Block Change Tracking on the auxiliary while it’s doing the restore/recovery (in mounted status)

(This solutions isn’t coming from me, but as far as I know, the father of this solution is a colleague working at Trivadis.)

You can easily fork a process before running the duplicate command that:

  • loops and checks the auxiliary instance status
  • run the disable as soon as the auxiliary is mounted

I’ve worked out this script that does the job:

Run it  just before the duplicate! e.g.

HTH

—

Ludovico

Script that duplicates a database using a physical standby RAC as source

Posted on by
12

 It’s possibile to duplicate a database for testing purposes (it’s an example) using a standby database as source. This allows you to off-load the production environment.

This is a simple script that makes use of ASM and classic duplicate, although I guess it’s possible to use the standby DB for a duplicate from active database.
You can launch it everyday to align your test env at a point in time.