RE: Shutdown Abort
- From: <Joel.Patterson@xxxxxxxxxxx>
- To: <niall.litchfield@xxxxxxxxx>
- Date: Thu, 5 Jul 2007 10:08:25 -0400
.... 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:
