Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Detail of the TAF mecanism used with Rac Guard or even just RAC

Re: Detail of the TAF mecanism used with Rac Guard or even just RAC

From: Tim Gorman <tim_at_evdbt.com>
Date: Thu, 09 Dec 2004 19:03:42 -0700
Message-ID: <BDDE520E.20B26%tim@evdbt.com>


Peter,

Comments inline...

on 12/6/04 4:12 AM, LOMAX Peter Ext ROSI/SIFAC at plomax.ext_at_francetelecom.com wrote:

> Good morning,
>
> I have scurged the documents on this to no avail.
> I wish to fully understand how a cursor is replayed at the point where it left
> off whilst using a TAF connection.

The cursor is simply re-executed from the beginning. The FETCH operation does not actually return rows until the cursor gets past the point it was at when it failed. This is easy to prove, by the way...

>
> I have defined a TAF connection with a PRECONNECT using both Primary and
> Secondary
> connections each including a backup to each other.
>
> So I already have a connection to the second instance open as well as the
> first instance, of course.

Using BASIC is much more robust than PRECONNECT. The main advantage of PRECONNECT is that a second connection is already established that there a "storm" of connection requests is not slamming the second server when the first fails, but PRECONNECT is a one-trick pony. Try failing back; BASIC does it just fine, but PRECONNECT is incapable.

So, perhaps speed of failover is still important and your app has enough concurrently-connected sessions to anticipate a "storm", or perhaps not...

>
> Boom, my instance fails then my SELECT is FAILEDOVER to the surviving
> instance.
> With the First instance as Primary I had already displayed lines 1 to 100.
> The client connection uses my defined backup connection: DED_PRE or DED_BASIC.
>
> When the second instance takes over as now the PRIMARY instance my select
> resumes at exactly the same place it left off.
>
> For clarity, my libcache update job has not updated the executed SQL from the
> first instance onto the second instance.
>
> So the cursor must be copied, re -executed and a reference to the current
> rownum must be passed.

Bingo. Great deductive reasoning!

>
> Question:
> Can someone explain from where the SQL and rownum is obtained?

Stored in the client-side cursor cache. In OCI terms, I believe that it is the CDA structure. I've not programmed TAF in OCI, but that is where it was first exposed, back in the Oracle8 v8.0.x timeframe, I think. It wasn't implemented fully until Oracle8i v8.1.x...

Hope this helps...

-Tim

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 10 2004 - 01:24:04 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US