Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: What happens during open resetlogs?

Re: What happens during open resetlogs?

From: Ram Raman <>
Date: Thu, 24 Aug 2006 11:24:20 -0500
Message-ID: <>

I have wondered what happens during the transportable tablespaces but I got the answer today. Thanks for the explanation.

And I am guessing if we plug in a TTS with a lower SCN it will bump the SCNs in the new incoming files.

On 8/23/06, Tanel Poder <> wrote:
> That's normal, SCN for a database is ever-increasing, you can not roll it
> back even with RESETLOGS open. The RESETLOGS_CHANGE# will be set to current
> SCN during a RESETLOGS operation.
> Only the log sequence numbers are reset to zero due RESETLOGS, not SCN.
> And the log sequence number is something which resides in controlfile, not
> datafile headers. Internally only the SCN's matter for deciding whether a
> log is needed for recovery or not, log sequence numbers are here just for
> our convenience again.
> If Oracle did reset the database SCN back to zero during RESETLOGS then we
> would have to go through every block in datafiles and reset the last update
> SCN in their headers back to zero as well, lot's of functionality is
> dependent on that info. Also, all undo segments would need to be reset, etc.
> Even when you plug a transportable tablespace with much higher SCNs in
> to your database, then Oracle has to bump up SCN to match the highest SCN in
> the datafile headers.
> Oracle doesn't ever reset SCN back for a database, it's only the changed
> RESETLOGS_CHANGE# which determines a new incarnation of the database, all
> other things going on are done just for our convenience...
> Tanel.
> ------------------------------
> *From:* [mailto:
>] *On Behalf Of *Ram Raman
> *Sent:* Thursday, August 24, 2006 04:37
> *To:*
> *Cc:*; oracle; oracle-l
> *Subject:* Re: What happens during open resetlogs?
> I recently cloned and opened a database with resetlogs option. I thought
> I would find the RESETLOGS_CHANGE# to be something like 1 or 10, instead I
> found it to be some 17 digit number carried over from production. Any
> thoughts on that.

Received on Thu Aug 24 2006 - 11:24:20 CDT

Original text of this message