Re: RMAN Catalog Implicit Resync

Hello,

That makes perfect sense, if I say LIST BACKUP you'd expect the controlfile and catalog to be brought into line before any results are returned.

I also found the rman options "DEBUG TRACE=/tmp/1.txt" handy when trying to understand whats going on but are very verbose, have plenty of disk space.

Hopefully you just need to change the query to pick the "last" SCN from your existing backup but I remember having to go up and down from that SCN to get the restore to work.

Regards,
Frank

On Fri, Aug 7, 2020 at 4:25 PM Charlotte Hammond < charlottejanehammond_at_yahoo.com> wrote:

> 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_at_gmail.com> 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_at_freelists.org> 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
>

-- 
+353-86-0695383

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