11g brought the hability of moving all backup activity to a physical standby database without restrictions, including controlfile copies that are interchangeable between primary and standby databases. This let us backup a standby database covering any primary failure wituout the need of rebuild our controlfile as Oracle will be able to transform it and maintain the original or specified roel we are interested on. As a requisite, we need to configure a RMAN catalog and correctly register our Data Guard configuration on it. This is very important for succesfull backups and specially sucesfull restores. We can find information regarding this role independency for controlfile copies since version 11.1 documentation. Here we can find that metadata information stored inside the catalog is what enables the database to be able to be conscious of datafiles names and configuration all along the Data Guard, being able to cross restore or backup datafiles and controlfiles.

Days ago, performing in a test environment restoration from a standby database, I found this was not the real behaviour, because the database I restored still was seing its controlfile as standby. After additional tests and search for mor information in My Oracle Support, we found we could be hitting bug 18455956, that arises in a restore environment when no RMAN catalog is used. We were trying to perform our test restoration explicitly without using catalog just to avoid aplying changes in database incarnation configuration when opening the restored database with resetlogs option. These tests where performed to validate a backup strategy based completely in backups being taken from the standby database.

So finally, I performed additional tests in a new single instance test environment in Data Guard configuration, using two servers in cluster configuration with Grid Infrastructure, using shared ACFS storage for both database to be able to access the databases taken at the standby location. Primary database was named alberto and standby database was named bertodg (names given by Sergio, to whom I want to thank for providing me in a very fast way this environment using his magic with gdbClone tool!). First step was the execution of a backup database RMAN command connected to bertosg (standby) generating a backup inside the FRA, created in the same filesystem. By doing so, we primary and standby database share the access to backups and there’s no need to perform additional copy or recatalog of backup pieces.

Primary restore from standby copy with RMAN catalog connection

We connect to the alberto database and we also use a catalog connection. In this test our RMAN script is explicitly restoring the controlfile from the backuppiece in standby’s FRA. We took a backup of a standby controlfile, but it is restored at the primary location as a current controlfile, fine for a primary database.There’s no need to tell RMAN anything about this, all is performed automatically.

Primary restore from standby copy without RMAN catalog connection

Let’s repeat same test, but this time without connecting to the RMAN catalog. Restore and recover database works fine, but it’s not possible to open the database because controlfile was not converted during the process and is still a standby controlfie.

We can check that we have restores a STANDBY CONTROLFILE, this is not what we are looking for as we are not trying to change the role of our primary database.

Bug 18455956

It could be OK that Oracle do not convert the standby controlfile when we are not connected to the catalog, just because it has no way to tell the role of the database as this information is inside the catalog. In fact, RESTORE CONTROLFILE command can be manually performed, since 11gR1, in 3 different ways:

  • RESTORE CONTROLFILE. Controlfile is restored into the database, and the role is determined by means of gathering this information form the recovery catalog. The role will remain the same the database had before starting restoration.
  • RESTORE PRIMARY CONTROLFILE. We force the controlfile to be transformed into a primary controlfile without caring if it was originally a primary or standby one.
  • RESTORE STANDBY CONTROLFILE. Controlfile will be converted into a standby controlfile.

So we have the choice of automatically restore a controlfile depending on the role of the database we are connected to if we use a recovery catalog, and alsa can specify the role we want this restored controlfile to be converted to if we just want to use a backup to create a new primary or standby database independently of what kind of controlfile we have. Taking a look at MOS note Step by Step method to create Primary/Standby Database from Standby Backup (Doc ID 1604251.1), we see that as consequence of bug 7553431, a new bug arises after applying the patch, 18455956. Without path 18455956 applied, RESTORE PRIMARY CONTROLFILE command won’t convert a standby controlfile if we are not using recovery catalog when restoring from a standby controlfile. Using a recovery catalog is just the workaround for avoinding this issue.

In our test case, we verify patch 18455956 is not applied in our April’s 2017 PSU level.

We check we are hitting this bug by performing another test using RESTORE PRIMARY CONTROLFILE:

Alternatives when we are not using recovery catalog

Now we know the problem, we can use different aproaches as a workaround if we want to perfom a recovery without connecting to RMAN catalog.

It can be interesting taking in care we can just open the database in this state in read only mode. This enables checking the data if that is just what we need.

We can recreate the controlfile from the satdnby (backup controlfile to trace) and adapt it to recreate the primary version. Another solution is to open the restored standby database as a primary database, by forcing a failover. This is what we test in the next test. Before that, we clear the standby logs and disable flashback database to avoid errors when trying to open the database:


We must use a recovery catlaog when performing backups in a Data Guard configuration. Anyway, there are specific scenarios where a connection to the catalog is not desirable, just to avoid any disturb in the real state of production backups. If this is our case, we must be conscius, if we are using (this issue does not affect or earlier versions) of the existence of bug 18455856 that will make us choose between applying the software patch, or planning the restore operations with this handicup in mind.


Ilustración: Alicia Constela

%d bloggers like this: