Re: shutdown immediate hangs

"Karen Abgarian" <abvk_at_ureach.com> wrote in message news:3D8CD542.C3FFA7A0_at_ureach.com...
> >
> > Come off it. There is nothing abnormal about an instance recovery, nor
> > anything particularly nasty, provided your online redo logs are safe.
And
> > they ought to be safe whatever sort of shutdown you elect to do.
> >
> > This nonsense about the eerie shortcomings of shutdown abort really
ticks me
> > off. You (and everyone else) should know better.
> >
> > Unless you can come up with something better than "there might be other
> > interesting things", your "argument" holds no water. As it is, it's
little
> > better than voodoo and being scared at shadows.
> >
>
> Hm, I thought I made the argument clear. Let me try once again. We have
> several
> ways of shutting the software down. There is the documentation that comes
with
> the
> software. It says this:
>
> You can shut down a database instantaneously by aborting the databaseôs
> instance.
> If possible, perform this type of shutdown only in the following
situations:
> n The database or one of its applications is functioning irregularly and
neither
> of
> the other types of shutdown works.
> n You need to shut down the database instantaneously (for example, if you
know
> a power shutdown is going to occur in one minute).
> n You experience problems when starting a database instance.
> ...
> If both the normal and immediate shutdown options do not work, abort the
current
>
> database instance immediately by issuing the SHUTDOWN command with the
> ABORT option:
> SHUTDOWN ABORT;.
>
> If you open the documentation, you will see the corresponding section on
> shutdown NORMAL.
>
> Basically, Oracle is trying to tell us to shutdown normal and only resort
to
> abort if something is wrong.
>

Correct. Shutdown abort is definitely "rude", and because of the (hopefully small, if you've configured things correctly) chance of the loss of online redo between the shutdown and the subsequent startup, it's better to avoid it if at all possible.

> Now - nor you, nor I know much about what Oracle actually does on shutdown
> abort, we
> are only guessing.

Incorrect. What it does is extremely well documented, and can be seen clearly enough with various trace files, the alert log, and much else besides.

>I am not scared at shadows, but it is clear enough for me
> that if something ever
> goes wrong with starting an instance after an abort, it will be my
> responsibility.
>
>
> >
> > >
> > > If you come up with an script that kills sessions, you are also not
doing
> > a nice
> > > thing,
> >
> > It wouldn't matter a damn whether you killed off your sessions with a
smile
> > or a sinister snigger: "niceness" has nothing to do with it. You're
killing
> > sessions. I don't know how your script did it, but if it was by doing
lots
> > of "alter system kill session 'x,y'" commands, then you're doing nothing
> > which a shutdown abort doesn't do a whole lot faster (the rollback of
what
> > those sessions were in the middle of still has to take place sometime).
And
> > if it was by using things like 'kill -9' at the operating system, you're
> > doing totally reprehensible and unsupported things to Oracle.
>
> Again, we can only be guessing what Oracle does,

Why do you make that sort of statement? It might be true for you, but it isn't true for me, nor for many of the regular posters here.

>but it would be logical for
> shutdown abort to just go in and kill all server connections by killing
> processes.
> It cannot be doing what KILL SESSION command does.
>

I didn't say it did it in the same way, but that the net, observable effect on your database is the same: committed transactions are safe, uncommitteds are lost. And rollback of the uncommitteds is required at some point.

> I neer said I was happy about killing processes at the os level. But
> technically
> you are doing less harm for your database instance. (We are talking about
shadow
>
> processes).
>

Tell that to Oracle, who say not to kill O/S processes.

> >
> > We wouldn't be having this discussion if 'shutdown normal' was a viable
> > proposition for our original poster.
>
> Which reminds me of that nobody of us ever asked him.
>
> >
> >
> > So the fact remains that you don't "like" shutdown aborts for no good
> > reason. Like others, you are peddling the myth that there's something
> > "dodgy" about them when there isn't. And, which is worse, you propose
> > instead to use some other tool which either does the same thing as an
abort
> > in a less efficient manner, or does something which is totally
unsupported,
> > such as killing off O/S processes.
> >
> > The real difference between the two approaches is that the shutdown
abort
> > uses code which Oracle has written, and your method (whatever it is)
uses a
> > script that you've knocked up.
>
> > I know which I'd prefer to place trust in.
> >
>
> I think I explained my position well enough.
>

You did. You manage your database with methods that are flimsy and ill-thought out. You don't seem to have any understanding of the technical architecture underpinning the Oracle instance and database, and your position is thus based on nothing very substantial.

> Use the method that pleases your heart the most.
>

No. Stick to the facts, understand how Oracle works and what it does, and the method to use will be obvious.

> None of them is supported by Oracle and you will have to be responsible
for
> either.
>

Er, you posted documentation earlier. Oracle's documentation. Explaining how and when to use shutdown abort. So to say 'none of them is supported by Oracle' is flying in the face of your own evidence.

This appears to be a perennial problem with your recent posts here: they are internally self-contradictory, and full of "I thinks" rather than "I know" or "I tested...".

HJR
>
>
Received on Sat Sep 21 2002 - 16:34:11 CDT