• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer navigation

The Geek Diary

  • OS
    • Linux
    • CentOS/RHEL
    • Solaris
    • Oracle Linux
    • VCS
  • Interview Questions
  • Database
    • oracle
    • oracle 12c
    • ASM
    • mysql
    • MariaDB
  • DevOps
    • Docker
    • Shell Scripting
  • Big Data
    • Hadoop
    • Cloudera
    • Hortonworks HDP

RMAN Restore/Duplicate Performs Implicit Crosschecking and Cataloging

by admin

The Problem

After restoring a controlfile, the restore database can take a long time to restore due to implicit croscchecking and cataloging.

RMAN> restore database;

RMAN-03090: Starting implicit crosscheck backup at 2012/10/05 01:56:55
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=63 device type=DISK
RMAN-06206: Crosschecked XXXX  objects                               ------> Time taken <------
RMAN-03091: Finished implicit crosscheck backup at 2012/10/05 02:57:02

RMAN-03090: Starting implicit crosscheck copy at 2012/10/05 02:57:02
RMAN-12016: using channel ORA_DISK_1                                 ------> Time taken <-------
RMAN-03091: Finished implicit crosscheck copy at 2012/10/05 03:57:02

RMAN-07501: searching for all files in the recovery area
RMAN-07507: cataloging files...
RMAN-07508: cataloging done                                          ------> Time taken <-------

Sometimes this may also inadvertently introduce orphaned incarnations and lead to issues such as these:

a) duplicate failed during the recovery phase:

RMAN-03002: failure of Duplicate Db command at 08/22/2014 11:43:47
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-10032: unhandled exception during execution of job step 1:
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed
start until change 3996570506 using backup controlfile
RMAN-11001: Oracle Error:
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '+UAT3_DATA/tlxqa7/datafile/system.309.856254365'

b) Cannot restore from a known backup:

RMAN> list incarnation of database;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       LAWPROD  543219554        PARENT  1          12-MAR-2008 00:38:41
2       2       LAWPROD  543219554        PARENT  602821     25-MAY-2014 01:24:52
4       4       LAWPROD  543219554        ORPHAN  8618277    02-JUL-2014 15:11:35
7       7       LAWPROD  543219554        ORPHAN  8999502    22-JUN-2014 17:04:48
3       3       LAWPROD  543219554        ORPHAN  12377463   10-JUL-2014 02:45:40
9       9       LAWPROD  543219554        ORPHAN  13414195   15-JUL-2014 15:57:28
8       8       LAWPROD  543219554        ORPHAN  13906671   28-JUL-2014 11:25:03
5       5       LAWPROD  543219554        ORPHAN  22434478   28-AUG-2014 19:14:15
6       6       LAWPROD  543219554        CURRENT 23304847   02-SEP-2014 19:33:04
RMAN> run {
set until TIME "TO_DATE('2014-09-08:20:41:00','yyyy-dd-mm:hh24:mi:ss')";
RESTORE DATABASE;
}
2> 3> 4>
executing command: SET until clause
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 09/09/2014 00:45:39
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

The Solution

The implicit crosscheck and cataloging are only seen when using the fast recovery area. When using a restored controlfile to restore the database, we need to ensure that the controlfile metadata is still correct. So RMAN automatically crosschecks all backups and catalogs the flash recovery area. This is a one-time operation. So the first time a restore of any datafile is initiated, we will crosscheck and catalog the backup pieces. Subsequent restores from the same controlfile will not kick off the crosscheck and catalog operation.

It is not uncommon to have 1000's of records stored within the controlfile that will require crosschecking. Once the crosschecking is complete RMAN continues with cataloging the fast recovery area. This task can potentially take hours to complete. Further, if a new incarnation is introduced you may have issues with recovery due to the orphaned incarnation.

The workarounds:

1. disable the fast recovery area (FRA).

SQL> alter system set db_recovery_file_dest='' scope=both;

Remember to re-enable the FRA at a later point once the restore (or recovery) is completed.

OR

2. Remove the old files/unnecessary files from the FRA. Please note in 11gr2 you have the option to specify incarnation.

How to duplicate a Oracle Database to a previous Incarnation

Filed Under: oracle, RMAN

Some more articles you might also be interested in …

  1. How Do You Read the JMS File Store .DAT file
  2. How to Audit Alter Tablespace in Oracle 12c database
  3. How to Define PDB Listeners With Different Ports In a Oracle database Multitenant Setup
  4. Oracle DGMGRL (Data Guard Manager) Command Line Reference (Cheat Sheet)
  5. Using Rule Sets in Oracle Database Vault
  6. Oracle GoldenGate: GLOBALS Sample Parameter File
  7. Oracle RMAN Pluggable Database Point in Time Recovery
  8. Oracle Database Server Architecture: Overview
  9. How to limit access to oracle database so that only 1 user per schema is connected ( 1 Concurrent user per schema)
  10. How to use dbms_metadata.get_ddl to get Complete DDL for database objects

You May Also Like

Primary Sidebar

Recent Posts

  • qm Command Examples in Linux
  • qm wait Command Examples in Linux
  • qm start Command Examples in Linux
  • qm snapshot Command Examples in Linux

© 2023 · The Geek Diary

  • Archives
  • Contact Us
  • Copyright