RE: RE: MC/Serviceguard vs Sun Clusters

Sounds like a poor HA cluster implementation. In our environment, all the disks are in disk groups (which are known to all the hosts in the cluster). Only one host can have the diskgroup imported at one time. That's just basic hardware clustering 101.

We also have EMC disk behind it all. It's the BCV splits for backup and report databases where the fun comes in.

> -----Original Message-----
> From: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com]
> Sent: Friday, February 08, 2002 10:58 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re:RE: MC/Serviceguard vs Sun Clusters
>
>
> Glenn,
>
> The database corruption we had occurred under a very
> specific circumstance.
> It occurred only when the prime server was alive & well and
> the backup server
> thought the prime had died. Now, after some correction by my
> SA, we were using
> a much older version of ServiceGuard at the time & things
> have somewhat changed
> in the interim although not enough to make him comfortable.
> In this scenario,
> the backup system rebooted. During that reboot it forcibly
> wrenched the disk
> drives away from the prime system, forcing a complete failure
> of the prime
> server, then mounted and tried to run the database. When
> this occurred file
> lengths would change all over the place, control files would
> be 0 bytes, a 100
> MB datafile might tell you it was 150MB or 50MB. Mount
> points that had been 40%
> used were now either 100% or 0% used. In short all kinds of
> strange things
> would happen, to Oracle and HP files. HP admitted that this
> would happen, since
> the files were 'still opened for write by the prime system'
> and had been
> improperly switched. Regrettably at the time they did not
> have a way to prevent
> it.
>
> Dick Goulet
>
> ____________________Reply Separator____________________
> Author: Glenn Travis <Glenn.Travis_at_sas.com>
> Date: 2/7/2002 1:07 PM
>
> Could you explain the file corruption in a little more
> detail? I cannot imagine
> how failover would cause file corruption, much less how a
> properly configured
> running Oracle instance can get 'absolutely destroyed'.
> Isn't that the purpose
> of having Oracle over say a nonlogged, singlethreaded, cheapo
> db engine...?
>
> > -----Original Message-----
> > From: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com]
> > Sent: Thursday, February 07, 2002 9:00 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: Re:MC/Serviceguard vs Sun Clusters
> >
> >
> > Rama,
> >
> > We did the MC/ServiceGuard thing some years ago. Worked
> > well, after our SA
> > rebuilt the servers from ground 0. Adding it on to an
> > existing server is ok,
> > but somewhat unstable. One item to be VERY careful of. The
> > heartbeat cable, in
> > our case a ethernet thin line, needs to be on a dedicated
> > link, preferably a
> > purchased vs. custom made cable, and protected from
> > accidental disconnect. Ours
> > got disconnected by a contractor working in the computer room
> > because "it was in
> > his way". The resulting reboot of the backup server and
> > forcible takeover of
> > the disk farm absolutely destroyed the database. We had more
> > file corruption
> > than I ever could have imagined. Consequently we abandoned
> > ServiceGuard & are
> > going to standby databases instead.
> >
> > Dick Goulet
> >
> > ____________________Reply Separator____________________
> > Author: "Rama Malladi" <rama_at_toyota.com>
> > Date: 2/6/2002 5:23 PM
> >
> > Hi...
> > I am looking for inputs from anybody who has experience in both
> > MC/Serviceguard (MC/S) as well as Sun cluster implementation.
> > If a DBA/SA
> > team has lots of experience in implementing MC/Serviceguard
> > clusters on HP
> > and trying to move to SunClusters for HA solution ...
> >
> > a) What are the common things between MC/S and and Sun
> > clusters (ex: about 5
> > minute fail-over time, fixed IP address, 2 or more nodes in a
> > cluster, disk
> > sharing etc..)
> >
> > b) Any differences between these... What are the things to
> > watch out for
> > (assuming the team already knows in and out of MC/Serviceguard)
> >
> > Thank you in advance...
> > Rama
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Rama Malladi
> > INET: rama_at_toyota.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access /
> Mailing Lists
> > --------------------------------------------------------------------
> > 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).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author:
> > INET: dgoulet_at_vicr.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access /
> Mailing Lists
> > --------------------------------------------------------------------
> > 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).
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Glenn Travis
> INET: Glenn.Travis_at_sas.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: dgoulet_at_vicr.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Glenn Travis
  INET: Glenn.Travis_at_sas.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).