Re: Oracle7: Real automatic 2phase commits? or else?

From: Larry Stein, Ingres Consulting - Dallas <lstein_at_Ingres.COM>
Date: 7 May 93 01:11:36 GMT
Message-ID: <1993May7.011136.28482_at_pony.Ingres.COM>


In article <idmrmb.736635433_at_gsusgi1.gsu.edu>, idmrmb_at_gsusgi1.gsu.edu

        (Pywacket) writes...
>I recently read an article critiquing several large database
>server vendors (Ingres, Informix, Oracle, Sybase, & Cincom).
>In regards to automatic 2PC, the article indicated that some
>(Oracle 7, Sybase S10, and Cincom Supraserver) of the server
>products didn't have 'real' 2PC. The explanation was that they
>each provided their functionality through some use of replication
>services. Now, the Oracle7 marketing whizzes all say that replication
>server products are bad; so the question is 'Do they or don't they?'.
>This was one of the main points that Oracle made during a recent
>'seminar'. They kept saying how bad Sybase System 10 was going
>to be because it didn't have 'real' 2PC because it uses
>a replication server.
>
>--
>Mark Buffington / idmrmb_at_gsusgi1.gsu.edu / Ga State Univ / DBA Group

2PC and replication are separate services. They can both be used to update data in multiple locations, but the goals are different, no matter what the Marketing folks would like customers to believe this week. Oracle has also told some customers that they have a partial implementation of replication for V7.

2PC simply says that an update will happen in all affected locations, or not at all. Failure of a single site causes all sites to abort/rollback their transaction. Use of 2PC may carry large implications for system and network performance and availability. It depends on how you want to use it. If you have an unreliable network between your sites, 2PC may not be for you as many of your transactions will fail. Then again, if you truly must have all or nothing transactions, 2PC is the most readily available solution. 3PC, optimistic vs pessimistic, etc. are beyond the scope of this email.

(Deferred) replication is actually a complex topic that addresses related but slightly different needs. Data/transactions are replicated at multiple sites (usually) asynchronously. Not all sites must be available for the initial transaction. Replication raises issues such as guaranteed delivery, queuing machanisms and conflict detection/resolution that are far beyond the scope of this email. Keeping replicated data synchronized is a separate issue from the mechanism used to do so.

What is right for you? As usual, it depends on your technical and business needs, not on what the Marketers want to say about their competition. Some vendors offer one or the other, some both (and some neither).

Feel free to email if you would like to discuss this further.

Larry Stein

<Disclaimer: I do not speak for my employer, nor  anyone else's for that matter. Flame me and nobody else.> Received on Fri May 07 1993 - 03:11:36 CEST

Original text of this message