RMAN DELETE

Examples on this page assume that all pre-requiste and configuration steps are complete.

DELETE OBSOLETE

To remove backups that are no longer required...

DELETE OBSOLETE;

To avoid having to interactively confirm the deletion...

DELETE NOPROMPT OBSOLETE;

In scripts the NOPROMPT is implicit

To remove backups from TSM, plus any obsolete files on disk...

RUN{

ALLOCATE CHANNEL t1 TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

ALLOCATE CHANNEL d1 TYPE disk;

DELETE OBSOLETE DEVICE TYPE DISK;

DELETE OBSOLETE DEVICE TYPE 'SBT_TAPE';

RELEASE CHANNEL d1;

RELEASE CHANNEL t1;

}

RMAN-06091

Recent versions of Oracle (patch levels after July 2019) are more prone to failing with this error.

(Due to bug 28391990 and the limitations of its fix: 28432129)

RMAN-06091: no channel allocated for maintenance (of an appropriate type)

In most cases, updating your backup to match the command block above (i.e. with the explicit channel allocations and device types) will avoid this error.

DELETE EXPIRED

CROSSCHECK BACKUP;

DELETE EXPIRED BACKUP;

CROSSCHECK ARCHIVELOG ALL;

DELETE EXPIRED ARCHIVELOG ALL;

DELETE ARCHIVELOG

To delete all archivelogs that are already backed up to 'SBT_TPAE' (TSM or similar)...

DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE 'SBT_TAPE';

To delete all archivelogs older than 1 day...

DELETE ARCHIVELOG ALL COMPLETED BEFORE 'sysdate-1';

Recommended post-delete steps...

CROSSCHECK ARCHIVELOG ALL;

DELETE EXPIRED ARCHIVELOG ALL;

Automatic Deletion

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO 'SBT_TAPE';

DELETE BACKUP

To delete all backups (using default channel)...

DELETE BACKUP;

To delete a specific backupset...

LIST BACKUP;

LIST BACKUPSET DEVICE TYPE DISK;

DELETE BACKUPSET 1234;

Where 1234 is the "BS Key"

DELETE from "lost" Media Manager

In this case I duplicated a database (via RMAN) to create a new Data Guard Physical Standby instance on a new server without any RMAN/TSM integration configured. Unless we do some sort of backup, or scheduled archivelog deletion (see earlier on this page) on the Standby, the FRA will eventually fill with archived redo logs. In this case I chose to backup the Physical Standby with a Retention Policy of "Redundancy 2" i.e. if we lose the Primary, we still have a way of going back to an earlier backup and doing a point in time recovery on the Standby. However, the Primary is configured to use RMAN/TSM. The backup history for the Standby continues to list a lot of historical SBT_TAPE controlfile backups from the Primary (why the Primary is retaining them when it also has "Redundancy 2" and performs a "DELETE OBSOLETE" before every backup is another story). RMAN on the Physical Standby can't DELETE those backups (and if these are backups owned by the PRIMARY that's probably a good thing) and neither can it CROSSCHECK those backups and mark them EXPIRED, but they do clutter the LIST BACKUP output... so, let's get rid of them...

LIST BACKUPSET DEVICE TYPE 'SBT_TAPE';

BS Key  Type LV Size       Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ --------------------18977   Full    16.00M     SBT_TAPE    00:00:03     2022-OCT-06 21:25:29        BP Key: 18977   Status: AVAILABLE  Compressed: NO  Tag: TAG20221006T212526        Handle: c-1180906920-20221006-00   Media: 0  SPFILE Included: Modification time: 2022-OCT-06 21:04:59  SPFILE db_unique_name: MYORCL1  Control File Included: Ckp SCN: 11077253683740   Ckp time: 2022-OCT-06 21:25:26
This shows that we have a backupset that has been created with a device type of 'SBT_TAPE'.

 DELETE BACKUPSET 18977;

allocated channel: ORA_DISK_1channel ORA_DISK_1: SID=420 device type=DISKRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of delete command at 02/13/2023 15:11:03RMAN-06160: no backup pieces found for backup set key: 18977
When we try to delete it, the device type defaults to a device type of 'DISK' and the deletion fails.
Let's try explicitly setting the device type to 'SBT_TAPE'...

run

{

  ALLOCATE CHANNEL d1 TYPE DISK;  

  ALLOCATE CHANNEL t1 TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

  DELETE BACKUPSET 18977 DEVICE TYPE 'SBT_TAPE';

}

using target database control file instead of recovery catalogallocated channel: t1channel t1: SID=127 device type=SBT_TAPEchannel t1: Data Protection for Oracle: version 8.1.0.0
released channel: t1RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of delete command at 02/13/2023 15:17:58RMAN-06091: no channel allocated for maintenance (of an appropriate type)

run

{

  ALLOCATE CHANNEL t1 DEVICE TYPE SBT PARMS 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';

  DELETE OBSOLETE;

  CROSSCHECK BACKUP;

  DELETE EXPIRED BACKUP;

}

LIST BACKUPSET DEVICE TYPE 'SBT_TAPE';

specification does not match any backup in the repository

LIST BACKUP SUMMARY;

List of Backups===============Key     TY LV S Device Type Completion Time      #Pieces #Copies Compressed Tag------- -- -- - ----------- -------------------- ------- ------- ---------- ---19097   B  A  A DISK        2023-FEB-13 09:01:11 1       1       YES        TAG20230213T08594519098   B  0  A DISK        2023-FEB-13 10:10:03 1       1       YES        TAG20230213T09011219099   B  F  A DISK        2023-FEB-13 10:10:09 1       1       NO         TAG20230213T101009

Bibliography


http://www.juliandyke.com/Research/RMAN/DeleteCommand.phpRMAN Backup Returns RMAN-06091: No Channel Allocated For Maintenance (of An Appropriate Type) After Applying July (DBPSU/BP/RU) (Doc ID 2428682.1)http://www.oracledocs.com/delete-rman-archivelogs-older-than-1-days/https://blog.zeddba.com/2017/08/10/delete-old-sbt_tape-backups-that-are-no-longer-available-in-rman/