Errors on RMAN blockrecover attempt RMAN-06026, RMAN-06023

APPLIES TO

Oracle Database - Enterprise Edition - Version 10.2.0.3 and later

Information in this document applies to any platform.

***Checked for relevance on 09-Feb-2011***

RMAN-06026: some targets not found - aborting restore Cause: Some of the files specified for restore could not be found. Message 6023, 6024, or 6025 is also issued to indicate which files could not be found. Some common reasons why a file can not be restored are that there is no backup or copy of the file that is known to recovery manager, or there are no backups or copies that fall within the criteria specified on the RESTORE command, or some datafile copies have been made but not cataloged. Action: The Recovery Manager LIST command can be used to display the backups and copies that Recovery Manager knows about. Select the files to be restored from that list.

SYMPTOMS

========

Disclaimer

NOTE: In the images and/or the document content below, the user information and environment data used represents

Fictitious data from the Oracle sample schema(s), Public Documentation delivered with an Oracle database product or

Other training material. Any similarity to actual environments, actual persons, living or dead, is purely coincidental and

Not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Target: DB Name: O1RMTNYP

========

Oracle 10.2.0.3

Sun Sparc Solaris

Errors when trying to do blockrecover

RMAN> BLOCKRECOVER CORRUPTION LIST;

RMAN-03002: failure of blockrecover command at 08/17/2009 08:10:24
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 37 found to restore

CAUSE

There is corruption in the backup of the datafile

RMAN> list backup of datafile 37;

List of Backup Sets

===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ --------------------

47555 Incr 0 797.68M DISK 00:12:41 08-AUG-2009 17:19:53

BP Key: 47554 Status: AVAILABLE Compressed: YES Tag: TAG20090808T170710

Piece Name: /< backup directory >/O1RMTNYP_LEVEL_0_DB_BKUP_17:05:46-08-08-2009_1_47626.rman

List of Datafiles in backup set 47555

File LV Type Ckp SCN Ckp Time Name

---- -- ---- ---------- -------------------- ----

37 0 Incr 1386008078 08-AUG-2009 17:07:14 < directory >/O1RMTNYP/dbf02/rmtd18.dbf

SQL> select set_stamp from v$backup_piece where handle like '/< backup directory >/O1RMTNYP_LEVEL_0_DB_BKUP_17:05:46-08-08-2009_1_47626%';

SET_STAMP

----------

694372032

SQL> select * from v$backup_corruption where file# = 37 and set_stamp ='694372032';

RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK#

---------- ---------- ---------- ---------- ---------- ---------- ----------

BLOCKS CORRUPTION_CHANGE# MAR CORRUPTIO

---------- ------------------ --- ---------

164 694372793 694372032 47626 1 37 178472

90 0 YES ALL ZERO

165 694372793 694372032 47626 1 37 215037

5 0 YES ALL ZERO

SOLUTION

You cannot recover blocks 178472 and 215037 using that piece as that backup-set doesn't contain a good block image of the block that you want to repair. You can repair other blocks in file# 37 other than above using the piece listed.

CORRUPTION LIST means all the blocks listed in v$database_block_corruption. If there are more than those two blocks, then you have to specify them individually in the block recover command (enhanced in 11gR1 so that one can specify a range of blocks in the syntax). If there are only those two blocks, then user has to give us a backup (and catalog those in RMAN) that was not taken using 'set maxcorrupt'.

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.