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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
