Forum Stats

  • 3,825,014 Users
  • 2,260,455 Discussions
  • 7,896,382 Comments

Discussions

Odd behaviour from "report obsolete" statement.

rtiran
rtiran Member Posts: 74 Bronze Badge
edited Mar 5, 2020 3:00PM in Recovery Manager (RMAN)

Hello,

I face a strange issue regarding the way RMAN retrieves obsolete backups.

It's not a common situation - usually it works fine.

Database is 12.2 EE with April 2018 RU.

If I issue a "report obsolete" *while being connected to my recovery catalog* - RMAN gives me :

SRV01234 oracle :/ofa/app/oracle >rman target / catalog usercat/*******@RCVCAT

Recovery Manager: Release 12.2.0.1.0 - Production on Mer. Mars 4 15:49:15 2020

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DB01234 (DBID=1299026413)

connected to recovery catalog database

RMAN> report obsolete recovery window of 15 days;

no obsolete backups found

RMAN>

If I issue the same statement while being in NOCATALOG mode, RMAN retrieves an obsolete level 0 backup (which seems correct for me as I've got a more recent level 0).

SRV01234 oracle :/ofa/app/oracle >rman target /

Recovery Manager: Release 12.2.0.1.0 - Production on Mer. Mars 4 15:49:37 2020

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DB01234 (DBID=1299026413)

RMAN> report obsolete recovery window of 15 days;

using target database control file instead of recovery catalog

Report of obsolete backups and copies

Type                 Key    Completion Time    Filename/Handle

-------------------- ------ ------------------ --------------------

Backup Set           6094   04/02/2020

  Backup Piece       6094   04/02/2020         /RMAN/SRV01234/DB01234/daily/bs_VTLincr_DB01234_LUNDI_ulunl315_1_1

Backup Set           6093   04/02/2020

  Backup Piece       6093   04/02/2020         /RMAN/SRV01234/DB01234/daily/bs_VTLincr_DB01234_LUNDI_umunl315_1_1

Backup Set           6095   04/02/2020

  Backup Piece       6095   04/02/2020         /RMAN/SRV01234/DB01234/daily/bs_VTLincr_DB01234_LUNDI_ununla8l_1_1

Backup Set           6096   04/02/2020

  Backup Piece       6096   04/02/2020         /RMAN/SRV01234/DB01234/daily/bs_VTLincr_DB01234_LUNDI_uounlaha_1_1

< ... >

< ... Lines removed for brevity ...>

< ... >

RMAN>

By the way, none of my backup use a KEEP UNTIL condition.

How come, I do not get the same output when connected to the recovery catalog?

I could have understood the opposite - that is to say : some backups missing from the controlfile (due to CONTROLFILE_RECORD_KEEP_TIME constraint) thus leading RMAN to miss some obsolete backups while in NOCATALOG mode.

But that way, it remains a mistery for me. The catalog (for which I've issued a "resync catalog" just in case), should contain at least the same records than the controlfile or more.

In which scenario could the information in the controlfile lead RMAN to think that a backup is obsolete while it's not true when connected to the recovery catalog?

Thanks for your hints.

Regards,

Raphaël

Answers

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Mar 4, 2020 6:43PM
    I could have understood the opposite - that is to say : some backups missing from the controlfile (due to CONTROLFILE_RECORD_KEEP_TIME constraint) thus leading RMAN to miss some obsolete backups while in NOCATALOG mode. 

    The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum number of days that records are retained in the control file before they are candidates for being overwritten. Hence, you must ensure that you resynchronize the recovery catalog with the control file records before these records are erased. The parameter is 7 days by default and needs to be configured to fit well within your retention policy, otherwise as you noted, the evaluation of obsolete records will not work correctly.

    When Oracle needs to add new RMAN repository records to the control file, but no record is older than the threshold, Oracle attempts to expand the size of the control file. As I recall, Oracle does not shrink the controlfile once less space is required, but uses the additional space to store more records. So even if the init parameter is 7 days, it may store 10 days if space permits.

    I was wondering: What was the control_file_record... parameter when you resynced with the catalog database, and what is the current value? Could this affect how much data is subject to be resynced from the target controlfile to the recovery catalog?

  • rtiran
    rtiran Member Posts: 74 Bronze Badge
    edited Mar 5, 2020 3:43AM

    Hi Dude!

    Thanks for your answer.

    On that database, controlfile_record_keep_time is left to its default value (i.e. 7 days). However, daily backups (archivelogs & incremental) are done with RMAN being connected to the recovery catalog - therefore the implicit resync that goes along should take care of regularly propagating the information from the controlfile to the catalog.

    Additionaly (and that was not mentioned in my previous message), I compared the output of a "list backup summary;" while being connected to the catalog an in nocatalog mode. Result was the same - the "obsolete" backup was present in both output. Thus, it's not like if that backup had been unknown to the catalog.

    Regards,

    Raphaël

  • CristianR-Oracle
    CristianR-Oracle Member Posts: 497 Employee
    edited Mar 5, 2020 11:14AM

    To understand why RMAN behaves like this you will need to run the command with debug and see which SCN is used in both cases to determine if a backup is obsolete or not.

    Running the same command with and without a catalog connection will trigger different approaches in the background.

    Regards,

    Cristian

  • Dude!
    Dude! Member Posts: 22,829 Black Diamond
    edited Mar 5, 2020 11:51AM

    If you have an incremental level backup within your retention period depending on a level 0 backup that is already outside your retention period, than the level 0 backup will not be considered obsolete. Perhaps you have some different backup history in your catalog and controlfile and hence one is not considering the level 0 backup obsolete. Have you tried a crosscheck following a delete expired to remove records of data that no longer physically exist?

  • rtiran
    rtiran Member Posts: 74 Bronze Badge
    edited Mar 5, 2020 2:56PM

    Hi Christian,

    Actually, I already tried the debug approach but the generated trace was so verbose that I gave up trying to make sense of it.

    In fact my question is more about if you guys can come up with a *logical* scenario that would explain how what I describe could possibly happen.

    I agree with you when you say that "Running the same command with and without a catalog connection will trigger different approaches in the background.", as otherwise I would not get different result. That said, whatever the approach - I expect the command to behave the same except if there is a valid point not to.

    Honnestly, I tend to think that it's a bug but I'm just wondering if someone is aware of an edge-case/uncommon situation that could explain what I see.

    Thanks,

    Raphaël

  • rtiran
    rtiran Member Posts: 74 Bronze Badge
    edited Mar 5, 2020 3:00PM

    >> Have you tried a crosscheck following a delete expired to remove records of data that no longer physically exist?

    No - I've not done a crosscheck but I don't think that I've got any expired backups (all maintenances are done through RMAN so there is no reason for files to go missing).

    >> Perhaps you have some different backup history in your catalog and controlfile and hence one is not considering the level 0 backup obsolete.

    Yes - that could be a possibility but that should not happen as it's resync job to keep both in line.

    As I mentioned earlier, before closing the case as an unfortunate bug, I'm just wondering if there is some legit situation taht could explain what I see.

    Thanks,

    Raphaël