RE: Unkillable Background process "SHUTDOWN ABORT LEAVES UNKILLAB

I once used a product like this called First Watch, but I called it automatic failover rather than clustering. The product provided a redundant "heart beat" monitoring; but the user had to set up the configuration files and write and maintain any scripts that controlled the failover. What we discovered was that the Sun OS and hardware were so reliable that the most likely point of failure was in the human management of the configuration files and scripts. That is, the hardware was more reliable than people. So we decided to disable the automatic failover and use manual failover, where we would manually unplug the cables to the storage arrays from one box, plug them into the failover box, then boot the failover box by hand.

We never had to use it. What continues to amaze me is how often people implement these complex and difficult to manage redundancy setups (sometimes referred to NOT as a cluster, but a cluster f**k) when, if they would just choose a reliable platform, they would be better off.

> -----Original Message-----
> if anything wrong than this so call fault monitoring will do
> shutdown abort and release the mount points for
> second node to do startup pfile=....
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephen Lee
  INET: slee_at_dollar.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).