This content has been marked as final. Show 9 replies
I don't understand your comment.
control file AUTOBACKUP ON is recommended but it's an option.
I choose to set it OFF and manually backup control file with "Backup current controlfile". The backup control files was generated and deleted later on in "Delete obsolete" command. I can see it in the log.
And what's wrong with the format? I can see them generated fine..
Edited by: user8638320 on Jun 5, 2012 3:47 PM
Edited by: user8638320 on Jun 5, 2012 3:49 PM
You have redundancy 1. Any 1 controlfile backup that captures information about the whole week's backups is adequate for recovery. The controlfile does capture information about backups. So, the latest controlfile on day 7 does have information about previous L1 backups. The earlier controlfile backups are obsolete.
Hemant K Chitale
The only problem with that as I can see is if the following happens (please correct me if I'm wrong Hemant):
You alter the structure of the database (e.g. drop a tablespace) and then later that week you realize that you need to perform incomplete recovery to undo the drop tablespace command. You cannot do that with the current controlfile or with the backup controlfile if that controlfile backup is later than the alteration. You would need a controlfile backup from before the drop tablespace command.
Since CONTROLFILE AUTOBACKUP is OFF, the Full Backup also implicitly includes a control file backup in one of the backuppieces -- the one with the system datafile.
The "additional" controlfile backup created by a BACKUP CONTROLFILE is the one that is obsolete.
The OP could do a LIST BACKUP OF CONTROLFILE to identify the controlfile backups.
Hemant K Chitale
Hemant K Chitale,
Thanks for the reply.
So my question now is.
With CONTROLFILE AUTOBACKUP is OFF
On Day 0 (Sunday), I have level 0 backup, which is equivalent to full backup, along with manual backcup of current controlfile.
On follwoing Day 1-6, I have level 1 backup also manual backup of current controlfile.
But I saw the manual backup of controlfiles on Day 1-6 all got deleted because of obsolete. Is that because the database did not any structure change?
If there is any structure change, like dropping a tablespace, on Day 3 for example, manual control file backup on Day 3 would be kept (not obsolete) until next level 0 backup or newer database structure change ?
I am going to respectfully disagree.
Not with what Hemant has written because it is all correct but rather with the entire direction of what the OP is doing and the responses to it.
Let's say you take a backup at 2:00am.
Then at 8:00am you add a new tablepace
Then at 14:00 you have finished migrated tables into that new tablespace.
Then at 14:01 the database crashes.
Of what value is last night's control file backup?
Turn on autobackup and let Oracle manage things as it wishes ... just as with the change from rollback segments to undo ... rollback segments were the default too until 11gR2 ... Oracle will do a better job at protecting you than you will in almost every instance.
There is a lot more stored in a control file than just a history of backups.
Damorgan: well, last nights controlfile backup would be OK. The added tablespace after the backup would be added to the restored controlfile during the recovery phase.
But I totally agree with you, and I don't understand why Oracle haven't enabled controlfile autobackup on as default..
I cannot see any reason why anyone would not enable autobackup. Especially with versions prior to 10.2, not enabling it could really cause problems in a recovery scenario.
Example: you backup your database in nocatalog with
Ok, the controlfile backup is included in the backupset since datafile 1 is also backed up. The database server crash. Setup new server, install software and get all the backupsets of the database files onto the new server along with the backupset of the archived redo logs.
backup database plus archivelog delete input
But since your controlfile autobackup was OFF, and therefore only included in the main datafiles backupset, you cannot (not easily) access the backupset containing the necessary archived redo logs needed to recover that backup.
Luckily this changed in the newer releases of Oracle with the CATALOG command enabling you to update the controlfile with "unknown" backupsets.