Re: RMAN leaving orphaned backup files in FRA

Hi Rich,

Sorry about the db restart - I forgot that the parameter was dynamic!

I guess when development was writing the code they may have had a small db and only backed up once a day. But if you have a very large db and plenty of archive logs and backup them up often throughout the day then you will soon run out of control file sections.

Look at v$controlfile_record_section. This gives you an idea of how many records are in use. I have changed mine from 7 to 8 but it made no difference but then again my db is very small so the default is ok.

If at all possible use a recovery catalog and then you won’t get caught out with such issues.

Cheers,

Leng.

> On 27 Mar 2020, at 1:21 am, Rich J <rich242j_at_gmail.com> wrote:
>
> Hey Leng,
>
> I think you may be onto something here, but I need to do some testing. It could definitely explain what I'm seeing with the two databases that have orphaned backup files, but I can't wrap my head around why the other database has none. The unaffected database is smaller than the affected ones -- 8GB of data files versus 75GB and 865GB. I feel like I should already know the answer to this question, but what would the size of the database have to do with exceeding control_file_record_keep_time?
>
> I feel the documents on MOS about control_file_record_keep_time are misleading. They state that the value should be greater than the RMAN retention policy recovery window. In my case it definitely is, but the recovery window of 1 day is a misleading metric as the level-0 backups are weekly.
>
> Also, the parameter is dynamic, so why is it necessary to restart?
>
> I hadn't tried to catalog the files, since their ages are weeks or months old and somewhat random, although always on a Sunday -- the same as the level-0 incrementals.
>
> Thanks much!
> Rich
>
> On Wed, Mar 25, 2020 at 7:30 PM Leng Burgess <lkaing_at_gmail.com <mailto:lkaing_at_gmail.com>> wrote:
> Hi Rich,
>
> If you’re not using a recovery catalog, you should ensure the control_file_record_keep_time is large enough to contain all your backup records. I notice that retention policy is set to 1 day but if you have a large database this may still exceed the control_file_record_keep_time.
>
> Unfortunately this requires a db restart.
>
> As a test, try cataloging these backups - do they get cataloged or are you getting an error?
>
> Cheers,
>
> Leng.
>
>
> > On 26 Mar 2020, at 8:50 am, Rich J <rich242j_at_gmail.com <mailto:rich242j_at_gmail.com>> wrote:
> >
> > Hey all,
> >
> > In 19.6 on OL7.7, I have RMAN's retention policy set to 1 day. I run weekly incremental level-0 backups, a daily incremental level-1, and archived logs every 15 minutes. I'm not using a catalog (just controlfile). No data guard or other replication (yet). Single destination for archive logs.
> >
> > Upon noticing that the FRA is getting more full without a lot of data being added, I see that multiple databases with same setup as above appear to have orphaned files. These are backup files that RMAN no longer has cataloged, but has not deleted them from the OS. I also have one database whose obsolete backups appear to be deleted correctly. The one that's deleted correctly only has archive log backups every hour (not sure why that would matter). FRA size is set to 10x the amount of space currently in use (these are future production instances).
> >
> > I've seen this happen occasionally in the past, which makes me think I have something setup incorrectly. But I'm having difficulty determining what that might be since at least one of the database is deleting correctly.
> >
> > Thoughts on how to troubleshoot this?
> >
> > Thanks,
> > Rich
>

--
http://www.freelists.org/webpage/oracle-l