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@xxxxxxxxx> 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@xxxxxxxxx
<mailto:lkaing@xxxxxxxxx>> 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@xxxxxxxxx
<mailto:rich242j@xxxxxxxxx>> 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
