RE: Upgrade session interrupted - nohup catupgrd.sql?

From: Bobak, Mark <Mark.Bobak_at_proquest.com>
Date: Thu, 21 Oct 2010 12:58:06 -0400
Message-ID: <6AFC12B9BFCDEA45B7274C534738067F5DD34434_at_AAPQMAILBX02V.proque.st>



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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Dinh Sent: Thursday, October 21, 2010 9:11 AM To: kadmon_at_gmail.com; Stefan Knecht
Cc: oracle-l_at_freelists.org
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_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of cam [kadmon_at_gmail.com] Sent: Thursday, October 21, 2010 6:09 AM To: Stefan Knecht
Cc: oracle-l_at_freelists.org
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> _at_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_at_gmail.com> 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_at_10046.ch
>
> 10046 Consulting GmbH
> Schwarzackerstrasse 29
> CH-8304 Wallisellen
> Switzerland
>
> Phone +41-(0)8400-10046
> Cell +41 (0) 79 571 36 27
> info_at_10046.ch
> http://www.10046.ch
>
> =========================
>
>
> On Thu, Oct 21, 2010 at 2:28 PM, cam <kadmon_at_gmail.com> 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
>> - _at_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
Received on Thu Oct 21 2010 - 11:58:06 CDT

Original text of this message