DomainKey-Signature: a=rsa-sha1; c=nofws;        d=gmail.com; s=gamma;        h=mime-version:in-reply-to:references:date:message-id:subject:from:to         :cc:content-type;        b=ZGMct7khswiL7Ipu+eFcq199kkfS+d1Nuvo63me1X6m2gLlNq/3oTRR7EMQ1an6zzT         cW3wqedRcQ7/nwvUGeQj0OxMmHYT0W0V4KI/E/oU/2n+DYhBtZWLatdOTESyTYBjJFp/         VcyiWQ3rscRQ+E5eHDDkzFtddcOtxaVs9iAZE=
MIME-Version: 1.0
In-Reply-To: <AANLkTik6R=uLf4JvQ3NjnrU8+H+w5MTi3d6Ryx=NX9Ms@mail.gmail.com>
References: <AANLkTinKAWEyTtYHM6Mw4aGi3r_zdoCDBs_4sONupdZH@mail.gmail.com>	<AANLkTik6R=uLf4JvQ3NjnrU8+H+w5MTi3d6Ryx=NX9Ms@mail.gmail.com>
Date: Thu, 21 Oct 2010 14:09:00 +0100
Message-ID: <AANLkTinST+xX42EwLpC7N9kxnYb1bxXJxQnqrSH0nkdx@mail.gmail.com>
Subject: Re: Upgrade session interrupted - nohup catupgrd.sql?
From: cam <kadmon@gmail.com>
To: Stefan Knecht <knecht.stefan@gmail.com>
Cc: oracle-l@freelists.org
Content-Type: text/plain; charset=ISO-8859-1
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: kadmon@gmail.com

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@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@10046.ch
>
> 10046 Consulting GmbH
> Schwarzackerstrasse 29
> CH-8304 Wallisellen
> Switzerland
>
> Phone +41-(0)8400-10046
> Cell +41 (0) 79 571 36 27
> info@10046.ch
> http://www.10046.ch
>
> =========================
>
>
> On Thu, Oct 21, 2010 at 2:28 PM, cam <kadmon@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
>> - @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