咨询微信： dbservice1234 7 x 24 在线支持！

首页

下载 DBRECOVER

Common Causes for RMAN-06023 and RMAN-06026

Common Causes for RMAN-06023 and RMAN-06026

Posted by PDSERVICE on 3月 08, 2020 In
PURPOSE
This document describes known root-causes for the error :
 
RMAN-06023: no backup or copy of datafile %s found to restore
RMAN-6023: no backup or copy of datafile %s found to restore
 
 
In case you may want or need more about your current topic - please also access the Backup & Recover Community of Customers and Oracle Specialists directly via:
TROUBLESHOOTING STEPS
1) General description
 
RMAN-06023 "no backup or copy of datafile %d found to restore"
// *Cause: A datafile, tablespace, or database restore could not proceed
// because no backup or copy of the indicated file was found.
// It may be the case that a backup or copy of this file exists but
// does not satisfy the criteria specified in the user's restore
// operands.
 
The error RMAN-6023 means that RMAN cannot find a backup for that datafile in its repository. The RMAN-repository is ALWAYS in the controlfile, but might be in an RMAN-catalog database aswell. So a good starting point for diagnosing the issue is a LIST BACKUP output.
Example :
RMAN> list backup of datafile 1;
 
--OR--
 
RMAN> list backup of archivelog sequence;
 
The backup needs to be marked as AVAILABLE and there needs to be a channel allocated for the 'Device Type' reported in the 'LIST BACKUP'
Example :
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------------
4       Full    537.90M    DISK        00:00:25     17-JUN-2011 17:12:42
BP Key: 4 Status: AVAILABLE Compressed: NO Tag: <TAG_NAME>
Piece Name: /<DIR>/<DB_HOME>/dbs/<PIECE_NAME>
List of Datafiles in backup set 4
File LV Type Ckp SCN    Ckp Time             Name
---- -- ---- ---------- -------------------- ----
1       Full 975048     17-JUN-2011 17:11:39 /<DIR>/<DB_NAME>/datafile/<FILE_NAME>.dbf
 
However if they above is matching, than it might be one of the issues below which is causing the problems.
 
 
2) Backups available on disk / tape but not in the RMAN repository
It might be that RMAN can not find any backup to restore from and they are not shown in the 'LIST BACKUP'-output,
but the backups available on disk or tape.
So in your setup the backups are removed from the RMAN-repository (controlfile and/or catalog), but are still available on disk or tape.
There are configurations possible where this is intended behaviour.
 
Than the backups need to be cataloged again using the CATALOG command
Backups can only cataloged from 10g and later versions.
 
Example :
 
RMAN> catalog start with '<directory where the backups are>';
 
Afterwards the backups should be shown again in the 'LIST BACKUP' output
 
 
3) UNTIL TIME conversion
When an SET UNTIL TIME is being used, RMAN will convert it to an UNTIL SCN. This is an estimate as there is NO hard relation between a timestamp and an SCN. RMAN is making an estimate. Especially when a timestamp is used which is close to the end-time of the backup, than this might be an issue. If the conversion to an SCN is generating an SCN which is BEFORE the end fuzziness of the datafiles in the backup, than the backup can NOT be used.
 
Example :
Backup start on T1 (SCN=1000) and ends on T2 (SCN=1050), than the backup can ONLY be used if the UNTIL SCN is 1050 or higher.
So if the 'UNTIL TIME T2'  is converted to SCN 1045, than this backup will NOT be used.
 
V$BACKUP_DATAFILE / RC_BACKUP_DATAFILE is giving more info on this.
CHECKPOINT_CHANGE# corresponds with T1
ABSOLUTE_FUZZY_CHANGE# corresponds with T2.  When ABSOLUTE_FUZZY_CHANGE# is NULL, than it is the same as the CHECKPOINT_CHANGE#
 
There is a known RMAN issue with an incorrect UNTIL TIME conversion due to skipping the TIME-part.
Bug 9128954 RMAN IS SELECTING WRONG BACKUP WITH 'SET UNTIL'
 
 
4) Inactive thread
A RAC-database but also a Single instance database, can have multiple threads enabled. Each thread will have its own set of redologs files and will archive them.
In a thread (instance) is idle, or not started for some time, than an RMAN DUPLICATE could fail on it as it is looking for datafile or archived redologs from the inactive instance which will not be there anymore.
 
In addition, RAC becomes the different behavior from 11g. If a user execute 'ALTER SYSTEM ARCHIVE LOG CURRENT' on node#1 and,
even if node#2 stops, the archivelog of thread#2 is NOT archived.
it is archived on 10g even if node#2 stops.
 
There is an known issue related to inactive/disabled threads as handled in
    Bug 9044053 RMAN DUPLICATE CAUSES RMAN-06457 WHEN USING 'UNTIL SCN' UNTIL STARTUP NODE#2.
 
Best practice is to drop the threads which are not used at all anymore.
 
SQL> select thread#, status, enabled, instance
     from v$thread;
 
     select group#, thread# from v$log;
 
     alter database disable instance '<name>';
     alter database drop logfile group <group#>;
 
 
5) Incarnation issues
5a)  New incarnation added due to implicit resync
This is issue is only relevant if a Flash | Fast Recovery Area (FRA) is being used.
 
If 1 or more  restore and recovery attempts have been done for this database and the database has been opened with RESETLOGS,
than there might be archived redologs generated for this new incarnation of the database.
 
During the RMAN recovery-phase, RMAN will do an catalog of all the files in the FRA, and will catalog the new archived redologs aswell.
As they belong to another incarnation, the incarnation will be added (if not there) and will be marked as CURRENT.
The recovery will than look for archived redologs of a different incarnation than intended, as the CURRENT incarnation belongs to a prior RESETLOGS-operation
 
The best option is to remove all the old files from the FRA eg. flashbacklogs, archivelogs, backupsets, datafiles etc.
belonging to an incarnation of a prior attempt.
 
 
Note 965122.1 RMAN RESTORE FAILS WITH RMAN-06023 BUT THERE ARE BACKUPS AVAILABLE
5b) Incarnations have the same RESETLOG_CHANGE#
There is a RMAN issue, which is causing different incarnations having the same RESETLOGS_CHANGE#. So there are multiple records in V$DATABASE_INCARNATION / RC_DATABASE_INCARNATION,
having the same RESETLOGS_CHANGE#. RMAN will loose track of which incarnation to use and might use an incorrect incarnation resulting in unexpected errors
 
Bug 5844752 RESTORE FAILS - CURRENT INCARNATION RESETLOGS SCN SAME AS PARENT INCARNATION
Note 727655.1 Despite Available Backups, Restore Fails with RMAN-03002:ORA-01180:Can Not Create Datafile 1
5c) Restoring from an none-current incarnation
The symptoms of this issue are closely related to the above issue (5b), but this time it is because the backups really belong to a different incarantion, than the current one.
Possible errors are :
 
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 1 found to restore
 
OR
 
RMAN-06026: some targets not found - aborting restore
RMAN-06100: no channel to restore a backup or copy of datafile 1
 
OR
 
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '+DATA/<DB_NAME>/<PATH>/<FILE_NAME>'
 
Check for more details :
RMAN RESTORE fails with RMAN-06023 or ORA-19505 or RMAN-06100 inspite of proper backups
Note 112248.1 RMAN-6026 RMAN-6023 During RESTORE Operation
Document 2038119.1 Resolving RMAN-06023 or RMAN-06025
 
 
6) Archivelog backup is missing
This issue is likely to occure during an RMAN-duplicate.
An RMAN DUPLICATE will use an UNTIL SCN recovery on the Auxiliary instance, to recover the database.
The end point of the recovery is specified by the UNTIL SCN, which is derived from the last archived redolog on the TARGET.
If this archive is NOT backed up, than the recovery on the AUXILIARY, and therefor the DUPLICATE, will fail on it.
 
There are 2 solutions for this.
Make an explicit archivelog backup, before you start the RMAN DUPLICATE. NOTE : this will only help if there are no additional archives created after the BACKUP and before the DUPLICATE starts
Specify an explicit UNTIL-clause, like UNTIL SEQUENCE. The following query might be usefull in that case:
SQL> select thread#, max(sequence#) + 1 seq#, to_char(max(first_time), 'dd-mon-yyyy hh24:mi:ss') first_time
     from v$archived_log
     where backup_count >= 1
     group by thread#;
 
RMAN RESTORE fails with RMAN-06023 or ORA-19505 or RMAN-06100 inspite of proper backups
 
 
7) Corrupted or missing backups on disk
RMAN is automatically failing over to another backup, if there is an issue with the backuppiece during the restore.
Related errors might be :
 
ORA-19870: error reading backup piece
ORA-19587 error occurred reading %s bytes at block
ORA-19505: failed to identify file
 
If an older backup is found in the repository, than RMAN will continue the restore, but most likely will require more (older) archived redologs during the recovery.
Especially when the restore is done on another host and not ALL the backups are accessible on that host, than it may endup in a situation that RMAN will try to CREATE the datafile(s).
This is really an issue when this involves datafile 1, as that can NEVER be created, as it is done during a CREATE DATABASE
 
Example :
creating datafile fno=1 name=+DATA/<DB_NAME>/<DIR>/<FILE_NAME>
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 04/28/2010 20:12:34
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '+DATA/<DB_NAME>/<DIR>/<FILE_NAME>'
 
So double check why the initial restore failed and resolve that issue as the errors ORA-1180 or RMAN-6023 are just a result of the initial errors.
 
Note 429689.1 RMAN Restore Fails: ORA-19870 ORA-19587 ORA-27091 ORA-27067 RMAN-06026 RMAN-06023
Note 1271551.1 RMAN duplicate failing with ora-19870 ora-19612 then RMAN-06023
Note 1300586.1 RMAN-6026 RMAN-6023 when restoring to new host
 
 
8) Never backed up
8a) No backup
In 10g onwards, if RMAN is starting a restore and is using a backup from before the CREATION_SCN of a datafile, than RMAN will automaticly create the datafile.
This is the case when a datafile was added after the backup.
 
However through 11g Release 1, this is still an issue during an RMAN DUPLICATE, which than will fail.
 
Note 782317.1 Rman-06023 encountered during duplicate to point in time after datafile was added
Note 135630.1 RMAN-6026 RMAN-6023 Restoring Database
Note 779558.1 Cannot restore incremental backups using tag when datafile has been added
 
 The error can also occur if there is No valid backup available for the specific point in time
8b) Plugged in Tablespace
The datafile is a plugged in datafile, and there has been NO backups taken after the pluggin operation.
So you need to plugin the datafile again from its source.
 
Note 1453090.1 RMAN-06023 during restore of a plugged in datafile
 
 
 
 
 
9) Backup piece are readonly
       The backuppiece are readonly at the operating system level.
       Make the Rman backuppiece not only readable but also writable .See Bug 5412531 for other details
 
       Fixed Version : -11gR1
 
       Applicable only for Operating system IBM AIX on POWER Systems .
 
 
 
10) Known Defects
For known issues reference bugs in the next articles:
 
Doc ID 48182.1 OERR: RMAN-6023 "no backup or copy of datafile %d found to restore"
 
Doc ID 48185.1 OERR: RMAN-6026 "some targets not found - aborting restore"