Re: Can XA (failover/recovery) work with DataGuard?

From: Robert Klemme <shortcutter_at_googlemail.com>
Date: Fri, 18 Apr 2008 20:44:29 +0200
Message-ID: <66s8gfF2jf4b6U1@mid.individual.net>


On 16.04.2008 19:11, joeNOSPAM_at_BEA.com wrote:
> Hi all.

Hi Joe,

nice reading from you again. You always come up with interesting issues - XA knowledge seems to be not very widespread. :-)

> About JDBC+XA transactions and failover with DataGuard vs. RAC:
>
> I understand how XA and recovery works with RAC, and how RAC
> guarantees that all a global transaction's info is available to all
> nodes
> at the time the tx is prepared. What about DataGuard, with maximum
> Availability protection mode (synchronous redo transport to standby
> logfiles) and real time apply of redo on the standby, and Fast-start
> failover?
> I assume performance would suffer, because the primary DBMS would
> have to essentially synchronize it's tx prepare calls, so it verifies
> that
> the standby gets and acknowledges the prepare info before returning to
> the client.

I don't think it will. Reading [1] "Maximum Availability" allows for primary and standbys to get out of sync temporarily, so requirements are a bit relaxed vs. "Maximum Protection". IMHO there is no need to wait for an acknowledged prepare from all standbys, because

  • the prepare does not do persistent changes,
  • if the master can prepare then all standbys can prepare as well, any check beyond successful shipping of logs seems superfluous

> But will Oracle guarantee that XA recovery will succeed at
> the standby node if there's a fail-over to it?

Is there a need to XA recovery if the master fails over? I think there can be two situations

  1. normal mode, logs are shipped synchronously and nothing is missing on the standby => TX can proceed normally on the standby
  2. standby lags behind because of temporary outage, if there is a way to detect whether all changes for this TX have been shipped and processed to the standby, that could decide whether commit can succeed or a rollback has to occur. If not the TX can be rolled back only.

> I may be asking what is the finest granularity of synchronous redo
> transport and application.
> Thanks,
> Joe Weinstein at BEA Systems

Kind regards

        robert

[1]
http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOverview.html Received on Fri Apr 18 2008 - 13:44:29 CDT

Original text of this message