Re: Oracle and MC/Serviceguard

On Fri, 17 Aug 2001, Riley McLeod wrote:

> We are implementing MC/Serviceguard here for failover, and I have some
> questions about configuration/placement of Oracle files.
>
> Our Oracle environment:
>
> Oracle 8.1.6 (64-bit)
> HP-UX 11.0 (64-bit)
>
> We are not running OPS. The shared disks are on HP AutoRaid.
>
> Do all Oracle files need to be on the shared disks? I know that the
> datafiles for all data/index/rbs tablespaces need to be there, as well as
> the control files and online redo logs. How about datafiles for temp
> tablespaces

If you don't put temp tablespaces on shared disks, then the Oracle package will fail to come up on the other node, because the temp tablespace's datafiles will be missing. If you want to use tempfiles, I suppose you could write the recreation of the tempfiles into your service start script, but I don't see what the advantage of doing that would be. It seems like needless additional complexity.

> or archive logs?

If you don't fail over the volumes containing archived redologs, then after a failover you won't be able to take a valid backup containing all archived redologs since your last backup. Also, your ability to recover using a backup will be diminished, due to the missing logs. Again, what does avoiding shared storage buy you?

> One other thing: would it be possible to have
> the Oracle binaries *not* be on shared disks, so that for Oracle
> upgrades/patches we could failover, upgrade/patch Oracle on the primary
> host, then fail back to the primary and upgrade/patch Oracle on the backup
> host?

Just upgrading the binaries does not upgrade the database. So failing your database onto upgraded binaries would not constitute a complete upgrade. You would still have to run the upgrade SQL scripts against the database. It doesn't really buy you anything, since you could just stop Oracle, and start it on an upgraded ORACLE_HOME on the same node to accomplish the same thing. Failover seems irrelevant to an Oracle version upgrade.

A failover would work for one-off patches but is probably slower than just applying the patch on the same node where you are presently running. Remember, a slight modification to the oracle makefile will allow you to create a brand-new oracle binary that you can copy into place in a 30 second restart of the database. Again, the Serviceguard cluster doesn't provide any advantage over a single node in patching situations.

Furthermore, if you don't fail over the ORACLE_HOME, then you are likely to *inadvertantly* start running your database on a slightly different version of the binaries when you fail over. Unless you are meticulous about installing, patching and maintaining the two ORACLE_HOMEs identically, you will encounter unexpected results from failing onto a different ORACLE_HOME. Again, why would you want that kind of complication? Just fail ORACLE_HOME over with the service. Maintain one ORACLE_HOME per service. Disk is cheap. Downtime and cluster hardware isn't.

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: jwilton_at_speakeasy.net

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).