RE: Shutdown Abort

....   Come to think of it... I don't remember shutting down the
database after the duplicate command completed.

 

I did remember some issues with the tempfiles with duplicating for
standby databases, but they were apparent before shutdown.

 

 

Now, I either remove the tempfiles first, or duplicate the same way and
see for sure what happens with shutdown/startup (immediate)  :-)

 

I choose immediate because it shouldn't matter in this case, and abort
can't be blamed if it is not in the equation.

 

 

Good eyes   (I mean guess :-))

 

Alex, you can look back.

 

Joel Patterson 
Database Administrator 
joel.patterson@xxxxxxxxxxx 
x72546 
904  727-2546 

________________________________

From: Niall Litchfield [mailto:niall.litchfield@xxxxxxxxx] 
Sent: Thursday, July 05, 2007 8:31 AM
To: Patterson, Joel
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Shutdown Abort

 

This is from memory, Alex look away now I'm guessing what Joel is doing
:). We had a process where we duplicated regularly. We didn't remove the
tempfiles before the clone, because why would you.  When the clone got
created it specified a tempfile with the same name as the one that was
on disk. Oracle was quite happy to do this without overwriting the
tempfile that was on disk (which is how I would design it to be fair).
We got the 'failed verification tests' message when the tempfile was
used for the first time and Oracle noticed from the file header that it
didn't really belong to the database after all. Now we make sure that
target tempfiles are removed beforehand. 

and you know what I can't resist ensuring that my memory is correct.
Note 374934.1 refers. 

Niall

On 7/5/07, Joel.Patterson@xxxxxxxxxxx <Joel.Patterson@xxxxxxxxxxx>
wrote:

 

 

Yes it was... created with the rman duplicate command.  You may be on to
something.   Should be able to check that... the next time it is
duplicated.. I will shutdown abort after duplicating.

 

The source has two tempfiles, but the duplicated database has one now
because the tablespace was dropped and recreated with one.  However, the
trace controlfile for the duplicated database had one tempfile now
because that is how I recreated it.   (I created a trace controlfile
before re-creating the temp tablespace).

 

The followup message, also in alert.log.  ORA-01203: wrong incarnation
of this file - wrong creation SCN

 

If what you say is true, should not the source be in the same state?
How to check?  That database shuts down once each month immediate
without issue.  

 

 

Joel Patterson 
Database Administrator 
joel.patterson@xxxxxxxxxxx 
x72546 
904  727-2546 

________________________________

From: Niall Litchfield [mailto:niall.litchfield@xxxxxxxxx] 
Sent: Tuesday, July 03, 2007 4:21 PM
To: Patterson, Joel
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Shutdown Abort

 

Was that database cloned from somewhere using RMAN? If so it's likely an
old tempfile that didn't really belong to the db. 

cheers

Niall

On 7/2/07, Joel.Patterson@xxxxxxxxxxx <Joel.Patterson@xxxxxxxxxxx>
wrote:

Update  FYI:

I just did a shutdown abort on 10.2.0.1 and got:  

ORA-01187: cannot read from file 201 because it failed verification
tests .

Had to drop and re-create the TEMP tablespace... .   

 

Joel Patterson

Database Administrator

joel.patterson@xxxxxxxxxxx 

x72546

904  727-2546




-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info 




-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info 

Other related posts: