Re: 2-Phase commit or replication?

From: Kevin Jernigan <kjerniga_at_emergent.com>
Date: 1995/06/01
Message-ID: <kjerniga-0106951113480001_at_slipkevinj.emergent.com>#1/1


In article <3qij5s$mcm_at_popeye.jsc.nasa.gov>, hilfinge_at_rose.rsoc.rockwell.com wrote:

> In article 6e8_at_pheidippides.axion.bt.co.uk, Karl Zdero
 <karlz_at_pst.bt.co.uk> writes:
> > What about using the Parallel Server?
> >
>
>
> My understanding of Parallel Server is that the datafiles are located in
 one location,
> but referenced from different locations with their own set of redo

 logs. My problem
> with Parallel Server is 'what if the machine with the data files goes
 down?'. Or is
> my understanding of Parallel Server wrong.
>
> Donita

Most Unix implementations of the Oracle Parallel Server (OPS) locate the datafiles on raw devices, and at least dual-port the SCSI devices, so that if a node goes down, the disks are still accessible to the other node(s). If OPS had a single point of failure on disk access, then one of its major benefits would be lost.

As for the original question that started this thread, what are the pros and cons of using 2PC vs replication to keep a master database and a copy of that database in sync, OPS doesn't directly help with this problem. However, if the real issue is availability of the database across single system failures, then OPS does a very good job of providing this. Just yesterday, the site I am working at had a CPU fault on one of the two clustered nodes that we are running OPS on. The node crashed because of the CPU fault, and Oracle on the other node shortly thereafter automatically did recovery for the failed instance, keeping the database accessible to the end-users throughout the process.

  • Kevin J
-- 
~~~~~~~~~~~~~ emergent: the parallel systems experts ~~~~~~~~~~~~~~~
kevin jernigan                                      415-567-8915 (p)
emergent corporation                                415-265-0785 (c)
kjerniga_at_emergent.com   http://www.emergent.com     415-367-6414 (f)
Received on Thu Jun 01 1995 - 00:00:00 CEST

Original text of this message