Thanks Frank.
Just connecting doesn't seem to be enough to cause a resync but most other
things do.
We have decided to bite the bullet and attempt to address this problem with our
duplicate utility - it's just too flakey to cross our fingers and hope nobody
accidentally does an unintentional resync just before our duplicate is due to
start.
Thank You!
Charlotte
On Thursday, August 6, 2020, 11:11:29 AM GMT+1, Frank Gordon
<frankagordon@xxxxxxxxx> wrote:
Hello,
can you equate anything like archivelog backup or your browsing sessions to the
timestamps for "periodically updated over the course of the day"
I'd also try running SQL*PLUS queries on the catalog rather than RMAN list
commands,that'd cut out one source of implicit resync.
Regards,Frank
On Mon, Aug 3, 2020 at 8:22 PM Charlotte Hammond <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
Hello!
What causes an implicit resync of the RMAN catalog? I had thought it was
significant events like running backups or deleting backup pieces. However
I've been using RMAN today, connected to the catalog, just browsing but I can
see that the catalog has periodically updated over the course of the day.
This shouldn't be a problem of course, but we have a legacy utility that runs a
duplicate from backups without specifying the SCN. In this case the SCN seems
to be plucked from the highest SCN in the AL table. This is fine if the AL
table isn't updated outside of backups but otherwise it ends up with SCNs from
more recent archive logs which aren't in the backup and so the duplicate
fails.Any workarounds without hacking at the fragile old duplicate utility to
force it to use a specific SCN or time?
Thank you in advance for any advice! (Oracle 11.2)
Charlotte
--
+353-86-0695383
