RMAN deletes all conrtolfile autobackups

oraclerman

We have Oracle 18c and RMAN with:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '+FRA';

We have incremental backups also. There was no 'backup current controlfile' in a backup script, but control file was backed up every time we did backup.
Could someone tell why "DELETE OBSOLETE" deletes all copy of autobackup controlfiles (except lastest one) when they still needed for database recovery? Like, WTF? If controlfile is redundant why RMAN does not delete related backup set, for example. Can't get it. And yes – we have tons of so called "backups" with no controlfile.

TSPITR fails with:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 10/29/2020 17:39:13
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06024: no backup or copy of the control file found to restore

Best Answer

Hopefully this has been fixed in more recent versions but I had a very nasty experience with this on an 11gR2 training course, many moons ago.

"... REDUNDANCY 1 ... "

... tells Oracle to keep a single backup copy of each file.

It does not tell Oracle to keep a single, consistent (i.e. recoverable) set of backup files!

An entire class of trainees happily built shiny, new databases and then took a backup of them.

So far, so good.

Much later in the day, then got to the exercise of taking another backup, trashing their database and restoring it.

Problem was, the backup ran out of disk space part way through, leaving an inconsistent and unrecoverable set of files - a mish mash of the earlier backup and the new one.

"REDUNDANCY 2" would have prevented this, retaining the previous, recoverable set of backup pieces.

As would more disk space, obviously.

I'd recommend using a RECOVERY WINDOW instead. It will fall more naturally in line with your [company's] Recovery Strategy.