On May 2, 2:53=A0pm, "gba...@[EMAIL PROTECTED]
" <gba...@[EMAIL PROTECTED]
>
wrote:
> Hi =A0David,
> =A0I don't think I understand. I was using the value of CURRENT_SCN from
> V$DATABASE to identify the target SCN in the DBPITR process.
>
> If I query my database :
> SQL> SELECT CURRENT_SCN, CHECKPOINT_CHANGE# , RESETLOGS_CHANGE# =A0FROM
V
> $DATABASE;
>
> CURRENT_SCN CHECKPOINT_CHANGE# RESETLOGS_CHANGE#
> ----------- ------------------ -----------------
> =A08279191460 =A0 =A0 =A0 =A0 8279155540 =A0 =A0 =A0 =A08279155539
>
> So CHECKPOINT_CHANGE# and RESETLOGS_CHANGE# are almost the same and
> lower than CURRENT_SCN.
>
> If I force a checkpoint global and query again:
> SQL> alter system checkpoint global;
> System altered.
> SQL> SELECT CURRENT_SCN, CHECKPOINT_CHANGE# , RESETLOGS_CHANGE# =A0FROM
V
> $DATABASE;
>
> CURRENT_SCN CHECKPOINT_CHANGE# RESETLOGS_CHANGE#
> ----------- ------------------ -----------------
> =A08279192016 =A0 =A0 =A0 =A0 8279192003 =A0 =A0 =A0 =A08279155539
>
> Now, CHECKPOINT_CHANGE# and CURRENT_SCN are almost the same while
> RESETLOGS_CHANGE# remains constant to the SCN were the last RESETLOGS
> took place.
>
> I am afraid that using RESETLOGS_CHANGE# in a DBPITR where I want to
> take the database up to a recent SCN will not be very helpful. Maybe I
> miss something, could you please explain what you mean?
>
> Thanks,
>
> Gonzalo.
I will admit I am flying somewhat 'blind' with this,. as I have no
access to a database with which I can effect a PITR. Thus, I admit to
being wrong in my original suggestion.
I'll need to look further into this situation before I attempt to
provide any further comment.
David Fitzjarrell
|
