Duplicate test database from primary lead to error - ORA-38757: Database must be mounted and not open to FLASHBACK.
One of our customers asked for a database duplicate on a new instance/database in order to resolve an issue related to data loss.
Preliminary information:
The primary database is in archivelog mode, "flashback off" set to ON and there is a standby database.
Also, primary instance is Oracle RAC one Node
Main things to do:
- Clone primary database Oracle Home and attach it on the destination host
- Create new instance for temporary purpose on the new Cluster host (destination)
- Prepare all parameters in pfile or spfile
- Create script for duplicate from primary, with special logseq/SCN/date-time
image:60]
One of our customers asked for a database duplicate on a new instance/database in order to resolve an issue related to data loss.
Preliminary information:
The primary database is in archivelog mode, "flashback off" set to ON and there is a standby database.
Also, primary instance is Oracle RAC one Node
Main things to do:
- Clone primary database Oracle Home and attach it on the destination host
This is a very important step in order to avoid issues with database after the duplicate process and make sure that all patches and fixes are in place. Also, this approach is less time consuming compared to a new installation of Oracle Home Software and applying all the necessary patches, in order to build the same software version on the destination instance. |
- Create new instance for temporary purpose on the new Cluster host (destination)
You just need to add the database service in the Grid infrastructure and update all necessary configuration files like tnsnames.ora, listener.ora etc. |
- Prepare all parameters in pfile or spfile
Again, a very important step in order to make the primary and destination instances identical, from a non-default parameter point of view. |
- Create script for duplicate from primary, with special logseq/SCN/date-time
The duplicate will be performed by allocating channels only to the destination database, which is called “auxiliary”. The primary database is called “target” and we will connect to the target only to retrieve information from control file in regards to the backup set names, scn, etc.. The same process can be performed by using catalog database, instead of using target database (primary). |
In our case, we are using HP Data Protector due to the legacy infrastructure of the customer. The primary database has been backed up with 4 channels and the restore should be performed by allocating the same amount of channels. The reason for that is the following: even by adding more channels, you will not achieve faster speed because in the data protector session the number of used devices has already been recorded. That number of devices should be 1:1 to the number of channels allocated for the restore session.
--- script
run { allocate auxiliary channel 'dev_1' type 'sbt_tape' parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=TESTDB,OB2BARLIST=TEST_DB_BACKUP_ON_Daily)'; allocate auxiliary channel 'dev_2' type 'sbt_tape' parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=TESTDB,OB2BARLIST=TEST_DB_BACKUP_ON_Daily)'; allocate auxiliary channel 'dev_3' type 'sbt_tape' parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=TESTDB,OB2BARLIST=TEST_DB_BACKUP_ON_Daily)'; allocate auxiliary channel 'dev_4' type 'sbt_tape' parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=TESTDB,OB2BARLIST=TEST_DB_BACKUP_ON_Daily)'; send device type 'sbt_tape' 'OB2BARHOSTNAME=test-b.backupserver.com'; SET NEWNAME FOR DATABASE TO '+BACKUP_ASM'; DUPLICATE DATABASE TESTDB DBID 2424174119 TO TESTDBNEW UNTIL logseq=23092 thread=1; } |
-- Error during duplicate process
Starting restore at 01-JAN-17 flashing back control file to SCN 12351082268602 ORACLE error from target database: ORA-38757: Database must be mounted and not open to FLASHBACK |
As per Oracle Support, this issue has been identified as a BUG when diplicating from an active database, which is not our case. What we are doing is using DUPLICATE DATABASE not from an active, but from tape.
Issue identified as Bug 18043064 - RMAN DUPLICATE FROM ACTIVE ATTEMPTING FLASHBACK OF ACTIVE PRIMARY