Re: dataguard standby creation - duplicate target not using incrementals
Date: Wed, 4 May 2016 17:51:02 -0500
Message-ID: <CAJvnOJaK0AiUzqWzKY7UerkoJjpP6iybMef0_krjTxfWMPb6cg_at_mail.gmail.com>
The 'list backup of database' shows them as incremental level 1 backups each day after Saturday,and shows Saturday's backup as an incremental level 0, Which is what it should show I think.
On Wed, May 4, 2016 at 5:22 PM, Robert Freeman <rfreeman_at_businessolver.com> wrote:
> Your not doing a combination of incremental and merged incremental backups
> are you? There is a known bug if you are using both kinds of backup
> strategies.
>
> Did you run the *list backup of database* report from RMAN and make sure
> that RMAN reports level 1 incremental backups (LV=1). I’ve seen some cases
> in the past
>
> When people thought they were doing incremental backups and they were not.
>
> Are you using the keep syntax in your backup incremental commands?
>
>
>
> Just a few thoughts running through my head…
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Andrew Kerber
> *Sent:* Wednesday, May 04, 2016 4:01 PM
> *To:* ORACLE-L <oracle-l_at_freelists.org>
> *Subject:* dataguard standby creation - duplicate target not using
> incrementals
>
>
>
> I ran into something interesting today. We have a full backup of a
> database from Saturday night, and incrementals each night through last
> night.
>
> We ran a 'duplicate target database for standby;' command to use the
> existing backup. Oracle restored from the full backup, but did not use the
> incrementals. Instead, it asked for all of the archive logs since the full
> backup. Is this expected behavior, or just something overlooked in the
> design, or what?
>
> Oracle 11.2.0.4 on Redhat 6.7
>
>
> --
>
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Thu May 05 2016 - 00:51:02 CEST
