Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: shutdown immediate hangs
>
> 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.
Now - nor you, nor I know much about what Oracle actually does on shutdown
abort, we
are only guessing. 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, 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 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).
>
> 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.
Use the method that pleases your heart the most.
None of them is supported by Oracle and you will have to be responsible for either. Received on Sat Sep 21 2002 - 15:25:56 CDT