0

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
3
  • why should it keep more than one control file backup if redundancy is 1?
    – miracle173
    Oct 29 '20 at 21:38
  • off topic: some expereince to "redundancy 1" retention policy
    – miracle173
    Oct 29 '20 at 21:47
  • TSPITR fails with latest copy of controlfile Oct 30 '20 at 11:34
1

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.

1
  • Thank you. That's what literally goes on and was discovered during the failed TSPITR attempt. And no, it was not 'fixed' even on 18c. Nov 2 '20 at 12:28
0

This is the expected behaviour. From the Database Backup and Recovery Reference, 12.1

RETENTION POLICY TO TO REDUNDANCY integer:

Retains integer full or level 0 backups of each data file and control file. The default retention policy setting is REDUNDANCY 1.

If more than integer full or level 0 backups of a data file or control file exist, then RMAN marks these extra files as obsolete. RMAN then determines the oldest of the retained backups and marks all archived redo log files and log backups older than this backup as obsolete. The DELETE OBSOLETE command removes obsolete data file backups (full or incremental), control file backups, and archived log backups or image copies.

You need only the latest control file backup to restore and recover your database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.