Re: shutdown immeditae waiting, grep ora, got process

From: Howard J. Rogers <hjr_at_dizwell.com>
Date: Sun, 19 Oct 2003 21:48:58 +1000
Message-Id: <3f927ab3$0$3699$afc38c87@news.optusnet.com.au>

yls177 wrote:

> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:<3f90f533$0$24515$afc38c87_at_news.optusnet.com.au>...

>> yls177 wrote:
>>
>> > hi, below are my steps
>> >
>> > 1) shutdown immediate;
>> > 2) but oracle still hanging, as in can do a ps -ef | grep ora and
>> > still the set of family oracle processes are alive
>> > 3) so i do a select * from v$instance;
>> > 4) and when it says that " oracle not available"
>> > 5) then i safely do a shutdown abort
>> > 6) finally, the family set of oracle processes are gone.
>> >
>> > but is it absolutely safe to do this?
>> >
>> > please confirm
>>
>> It's never *absolutely* safe to do a shutdown abort. There is a
>> miniscule, but real, risk that you lose your current redo log seconds
>> after doing the shutdown abort. *All* shutdown aborts require instance
>> recovery on subsequent startup. All instance recoveries require the
>> contents of the current redo log to be available. Therefore, after a
>> shutdown abort, if you lost your current redo log, you would not be able
>> to do instance recovery and you would be faced at best with the prospect
>> of performing an incomplete media recovery... meaning transactions would
>> be lost.
>>
>> A lot of people do shutdown abort - startup -shutdown immediate to get
>> around this problem.
>>
>> Me? I would shutdown the intelligent agent, and then do a shutdown
>> immediate. The agent has a session on the database, and it's one that
>> seems not to respond very well to the shutdown immediate command. So kill
>> the agent first, and you tend to find immediate shutdowns become a lot
>> faster.
>>
>> Regards
>> HJR

> 
> 
> hi, thanks for your sharing... from what i could understand from your
> post, basically 2 areas
> 
> 1) if there is ever a need to do a shutdown abort. we need to follow
> up by a startup and then shutdown immediate. this is because we want
> to avoid lost transactions?

I've always been an advocate of shutdown aborts not being very dangerous, actually. There is a *miniscule* risk of losing transactions... but miniscule is not 'none'. The risk arises from the possibility of losing your current redo log group immediately after the shutdown abort. How likely is it that you would actually lose an entire redo log group that has been properly mirrored onto two or three separate hard disks/RAID arrays?

I would say 'not very likely at all'. But the risk is still there, despite that optimisim.

Therefore, yes... a lot of people do shutdown abort-startup restrict-shutdown normal.

> 
> 2) when we stop this intelligent agent by "Before 9i, it was lsnrctl
> dbsnmp_stop. In 9i,it's agentctl stop." this will bring shutdown
> immediate a lot faster?
> 
> please kindly confirm.

Shutdown immediate is supposed to boot users off the system and rollback whatever they were in the middle of doing at the time. Until all users have been killed off by the shutdown immediate command, the shutdown process can't actually begin, and you just sit there waiting for it.

The agent is another connection that is *supposed* to be booted off... but it quite frequently seems not to. And that means you just sit there waiting for *it*, too. By terminating the agent yourself, you eliminate one source of potential delay. Shutdown immediate should indeed therefore be rather faster than before.

As an indication: when I was trying to work out an automated shutdown sequence for 9iR2 on Red Hat 9, I had the database shutdown, then the agent, listener and Management Server process. A bad move on my part:: the reboot of my Linux box took an interminable amount of time. Reverse the order of events, so that the agent, listener and management server were ended first, and the shutdown immediate was pretty well immediate.

Your mileage might, however, vary.  

> thanks

No problems,
HJR

-- 
--------------------------------------------
See my brand new website, soon to be full of 
new articles: www.dizwell.com.
Nothing much there yet, but give it time!!
--------------------------------------------

Received on Sun Oct 19 2003 - 06:48:58 CDT