Forum Stats

  • 3,824,997 Users
  • 2,260,452 Discussions
  • 7,896,379 Comments

Discussions

Delete archivelogs never been backed up?

orray
orray Member Posts: 2
edited May 1, 2020 11:31AM in Recovery Manager (RMAN)

Dear RMAN connoisseurs,

how do I get RMAN to automatically delete archivelogs never backed up?

Let's say I have configured a retention window of 14 days, rendering backups older than >14 days obsolete (and being deleted).

Let's also assume our  LOG_ARCHIVE_DEST points already to the backup storage system, so there's no need to explicitly back them up (since the originals are already in the backup location and backing them up would create rather pointless copies).

Now, how do I delete those archivelogs >14 days (more exact: from before my oldest, but not-yet-obsoleted backup set), even though these have never been backed up...?

The 11g RMAN docs say for archivelogs to become eligible to be deleted, they must A) been backed up at least once to disk and  B) must be older than my retention policy.

I have tried to CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 0 TIMES TO DISK; but this is refused by RMAN, of course.

Since my retention window covers 14 days, I will never have backups older than ~14 days, rendering useless all archive logs from before my oldest still-existing backup set. Yet it seems as if I cannot delete them unless they have been backed up...

May be I didn't understand some conceptual thing here, may be our idea of setting LOG_ARCHIVE_DEST to point straight into the backup storage is not so good...

Can you sched some light to this problem...?

Best Answer

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Apr 30, 2020 4:07PM Answer ✓

    RMAN retention doesn't do any housekeeping, nor does it delete any data unless you instruct RMAN to do so, or use FRA and run into disk space pressure.

    Are you using FRA?

    Since my retention window covers 14 days, I will never have backups older than ~14 days, rendering useless all archive logs from before my oldest still-existing backup set. Yet it seems as if I cannot delete them unless they have been backed up...

    Wrong.

    The retention policy defines what recovery window or redundancy must be guaranteed, which does not mean anything outside the retention period will be deleted. No backup or recovery data will be considered obsolete as long as it is required to accomplish your retention policy. For example, if your retention recovery window is 2 weeks, but your last level 0 backup was 1 month ago, then the level 0 backup will not be considered obsolete because it is required to meet your 2 weeks recovery window.

    You can always delete archivelogs, unless you have defined an archivelog deletion policy. By default, the archivelog deletion policy is set to none. Use "show all" in RMAN to display your settings. You can try the following:

    RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO CLEAR;

    RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

    You also need to keep in mind that the default control_file_record_keep_time parameter is 7 days by default, after which time re-usable metadata can be overwritten if necessary. Please check the documentation about this parameter and make sure it is set long enough to cover your retention period. You also need to do any RMAN housekeeping with that period, otherwise, data may be forgotten.

    Archivelogs are just as important as your backups - without them you cannot do an incomplete recovery or recover any inconsistent backup, meaning any backup that was done while the database was running.

    Keep it simple. For example:

    backup incremental level 0 database plus achivelog all delete input;

    backup incremental level 1 database plus achivelog all delete input;

    Then run RMAN delete obsolete periodically or use FRA.

Answers

  • EdStevens
    EdStevens Member Posts: 28,778 Gold Crown
    edited Apr 30, 2020 2:35PM
    orray wrote:Dear RMAN connoisseurs,

    Where to begin?

    how do I get RMAN to automatically delete archivelogs never backed up?Let's say I have configured a retention window of 14 days, rendering backups older than >14 days obsolete (and being deleted). 

    The setting of your recovery window is not the whole story on how long you have to keep backups and archivelogs (or backups of archivelogs).  You also have to factor in how often you take level 0 or full backups.  All recovery begins with restoring from the latest full backup prior to the point in time to which you wish to recover.  If you only take a full backup on 1 Jan of each year, come December you will still have to have retained the last eleven months of backup to protect your 14 day window.

    Let's also assume our LOG_ARCHIVE_DEST points already to the backup storage system, so there's no need to explicitly back them up (since the originals are already in the backup location and backing them up would create rather pointless copies).

    Backup is all about redundancy.  So what do you do if you lose your backup location?

    Now, how do I delete those archivelogs >14 days (more exact: from before my oldest, but not-yet-obsoleted backup set), even though these have never been backed up...?

    To have rman do it - back them up, then DELETE OBSOLETE.

    The 11g RMAN docs say for archivelogs to become eligible to be deleted, they must A) been backed up at least once to disk and B) must be older than my retention policy.I have tried to CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 0 TIMES TO DISK; but this is refused by RMAN, of course.Since my retention window covers 14 days, I will never have backups older than ~14 days, rendering useless all archive logs from before my oldest still-existing backup set. Yet it seems as if I cannot delete them unless they have been backed up...May be I didn't understand some conceptual thing here, may be our idea of setting LOG_ARCHIVE_DEST to point straight into the backup storage is not so good...

    Exactly - your idea of writing the original archvielogs directly to the backup location - with no intention of actually backing them up to rman - is "not so good".  And that is being generous.

    Can you sched some light to this problem...?

    Included backups of your archivelogs as part of your regular backup jobs.  Preferably, with the database's archivelog destination on different storage than your 'backup location'.  When you backup the archivelogs, include some approprieate variation of DELETE INPUT'.

    Have your backup jobs include DELETE OBSOLETE.

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Apr 30, 2020 4:07PM Answer ✓

    RMAN retention doesn't do any housekeeping, nor does it delete any data unless you instruct RMAN to do so, or use FRA and run into disk space pressure.

    Are you using FRA?

    Since my retention window covers 14 days, I will never have backups older than ~14 days, rendering useless all archive logs from before my oldest still-existing backup set. Yet it seems as if I cannot delete them unless they have been backed up...

    Wrong.

    The retention policy defines what recovery window or redundancy must be guaranteed, which does not mean anything outside the retention period will be deleted. No backup or recovery data will be considered obsolete as long as it is required to accomplish your retention policy. For example, if your retention recovery window is 2 weeks, but your last level 0 backup was 1 month ago, then the level 0 backup will not be considered obsolete because it is required to meet your 2 weeks recovery window.

    You can always delete archivelogs, unless you have defined an archivelog deletion policy. By default, the archivelog deletion policy is set to none. Use "show all" in RMAN to display your settings. You can try the following:

    RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO CLEAR;

    RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

    You also need to keep in mind that the default control_file_record_keep_time parameter is 7 days by default, after which time re-usable metadata can be overwritten if necessary. Please check the documentation about this parameter and make sure it is set long enough to cover your retention period. You also need to do any RMAN housekeeping with that period, otherwise, data may be forgotten.

    Archivelogs are just as important as your backups - without them you cannot do an incomplete recovery or recover any inconsistent backup, meaning any backup that was done while the database was running.

    Keep it simple. For example:

    backup incremental level 0 database plus achivelog all delete input;

    backup incremental level 1 database plus achivelog all delete input;

    Then run RMAN delete obsolete periodically or use FRA.

  • orray
    orray Member Posts: 2
    edited Apr 30, 2020 4:35PM

    Thanks a lot Ed & Dude!

    That in fact helps me understand the features better, and I admit I should have said that yes, we use FRA, and that we take level0 weekly and level1 daily (in some DBs, even more frequent). So in this scenario, I assume to be safe in saying that archivelogs >"retention policy" should be of no value any longer.

    And yes, we have set control_file_record_keep_time to 14 as well.

    So what do you do if you lose your backup location?

    Then (I thought) we will still have the running database... (Of course, that whole thing not being a desaster-proof concept.)

    Keep it simple. For example:
    backup incremental level 0 database plus achivelog all delete input;
    backup incremental level 1 database plus achivelog all delete input;

    Then run RMAN delete obsolete periodically or use FRA.

    Well, that is what we will do, then--and forget about the archivelogs being twice on the (backup) disks.

    Again, your very well explained information is greatly appreciated - thanks!

  • EdStevens
    EdStevens Member Posts: 28,778 Gold Crown
    edited May 1, 2020 10:03AM
    orray wrote:Thanks a lot Ed & Dude!That in fact helps me understand the features better, and I admit I should have said that yes, we use FRA, and that we take level0 weekly and level1 daily (in some DBs, even more frequent). So in this scenario, I assume to be safe in saying that archivelogs >"retention policy" should be of no value any longer.

    Not necessarily.  But if you are having rman back up your archivelogs with the DELETE INPUT option, and regularly DELETE OBSOLETE, then you don't have to worry about it.  All of your troubles are coming from trying to manually manage your archivelogs instead of taking proper archivelog backups and letting rman manage it all for you.

    So what do you do if you lose your backup location?Then (I thought) we will still have the running database... (Of course, that whole thing not being a desaster-proof concept.)

    You are correct, it is not disaster-proof. Not even close. You have to actually consider various kinds of disasters and what their impact would be. Then figure out how to mitigate. 

    Disasters to consider?  How about the following:

    - Hurricane floods the data center

    - Tornado wrecks the data center

    - common-carrier network link between data centers is cut

    - Fire in the data center

    - Truck bomb  two blocks away doesn't physically destroy the data center, but the shock causes multiple head crashes in your SAN. (Yes, I spoke the guy that dealt with this).

    What do YOU consider a disaster that needs to be

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited May 1, 2020 11:31AM
    So in this scenario, I assume to be safe in saying that archivelogs >"retention policy" should be of no value any longer.

    It's more complex. You will need archivelogs that are generated during backup, and you also need to archive the online redo log prior and after backup. If you use the RMAN backup plus archivelog syntax, then RMAN will automate the process for you. Otherwise if you do separate database and archivelog backups, you have to do it manually. The only time you don't need archivelogs is when you perform a consistent backup, meaning the database is properly shut down during backup.

    Again, make sure you understand that the RMAN retention policy specifies what restore and recovery must be accomplished, and not what is obsolete. Backup and recovery data that is required to accomplish your retention policy will not be considered obsolete.