RE: Upgrade session interrupted - nohup catupgrd.sql?

Just a minor comment.

Note that "shutdown abort" and "startup restrict" can be replaced with "startup 
force restrict".

-Mark

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Michael Dinh
Sent: Thursday, October 21, 2010 9:11 AM
To: kadmon@xxxxxxxxx; Stefan Knecht
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Upgrade session interrupted - nohup catupgrd.sql?

If you do shutdown abort, then follow theses steps:

alter system checkpoint;
alter system archivelog current;
shutdown abort;
startup restrict;
shutdown immediate;

I actually have this in a shutdown.sql for shutting down production.
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf 
Of cam [kadmon@xxxxxxxxx]
Sent: Thursday, October 21, 2010 6:09 AM
To: Stefan Knecht
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Upgrade session interrupted - nohup catupgrd.sql?

Thanks Stefan - later on the same page the Upgrade guide supports you:

"Rerunning the Upgrade
Follow these steps to rerun the upgrade:
   1. Shut down the database:
      SQL> SHUTDOWN IMMEDIATE
   2. Restart the database in UPGRADE mode:
      SQL> STARTUP UPGRADE
   3. Rerun catupgrd.sql:
      SQL> @catupgrd.sql
..."

I thought my situation was more like a resource failure than a 'clean
rerun' so I went with abort...

It sounds like you have run upgrades plenty of times - any opinion on
using nohup? (this is an upgrade rehearsal - I'm expecting to repeat
this in production before too long and I'd like to know if I have some
insurance against another network failure...)

cam

On Thu, Oct 21, 2010 at 1:59 PM, Stefan Knecht <knecht.stefan@xxxxxxxxx> wrote:
> What others have already recommended, but on top of that I would be careful
> with a shutdown abort prior to startup upgrade.
> I've had cases at more than 1 customer where I could reproduce core dumps
> (ORA-7445) and ORA-600's doing that.
> And yes, some version of the upgrade guide recommends to do exactly this. I
> would however do a shutdown immediate if you're planning to run the upgrade
> afterwards. And this coming from a great fan of shutdown abort ;-)
> My CHF 0.02
> Stefan
>
>
>
>
> =========================
>
> Stefan P Knecht
> CEO & Founder
> s@xxxxxxxx
>
> 10046 Consulting GmbH
> Schwarzackerstrasse 29
> CH-8304 Wallisellen
> Switzerland
>
> Phone +41-(0)8400-10046
> Cell +41 (0) 79 571 36 27
> info@xxxxxxxx
> http://www.10046.ch
>
> =========================
>
>
> On Thu, Oct 21, 2010 at 2:28 PM, cam <kadmon@xxxxxxxxx> wrote:
>>
>> Hello all,
>>
>> This seems like an obvious and common one but I haven't managed to
>> find any relevant Q&As here or on the OTN discussion boards.
>>
>> While remotely running catupgrd.sql to take an instance from 9.2.0.8
>> to 11.1.0.7 my session was killed... When I got back on, I decided the
>> situation was closest to the situation described under Resource
>> exhaustion in the 11g Upgrade guide and went for:
>>
>> - shutdown abort
>> - startup upgrade
>> - @catupgrd.sql
>>
>> This seems to have just completed successfully but I'd be interested
>> in any responses to the following:
>>
>> - does this seem like the correct way to resume the upgrade - it isn't
>> explicitly documented anywhere.
>> - since its not interactive, I assume its OK to nohup catupgrd - but
>> people don't often seem to do it. Can anyone confirm that it works and
>> doesn't get confused for some reason?
>>
>> cam
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>
>
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l




--
http://www.freelists.org/webpage/oracle-l


Other related posts: