Oracle FAQ Your Portal to the Oracle Knowledge Grid

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: LOMAX Peter Ext ROSI/SIFAC <>
Date: Mon, 6 Dec 2004 14:43:40 +0100
Message-Id: <>

Granted that its logical for the client side to take care of this.
>From the horses mouth:

Program Global Area (PGA) is a private memory region containing data and = control information for a server process.

Is there a detailed structure of the PGA mapped out? (links or references if you have any)
PGA's hold pointers to the SGA as well as my cursor data info. Where is the SQL retrieved from?
I understand that the PGA has now a pointer to a non existant SGA?


-----Message d'origine-----
De :
[]De la part de Martic Zoran Envoy=E9 : lundi 6 d=E9cembre 2004 12:22 =C0 :
Objet : Re: Detail of the TAF mecanism used with Rac Guard or even just RAC Hi Peter,

The most of the TAF functionality is done on the client side as you probably know.

That means your client side is full of the hidden OCI variables (some accesible through regular OCI calls) that are used to retry the cursor in the TAF environment and even continue from the place where it stopped (RETRY).

Just imagine your code that can do the similar thing. Many apps are doing that already manually without using OCI functionality. Not a big deal. Just Oracle will do this much better because of knowing a lots of internals (sometimes not true :)

In this case Oracle client side just do it for you.=20


> Good morning,
> =20
> I have scurged the documents on this to no avail.=20
> I wish to fully understand how a cursor is replayed
> at the point where it left off whilst using a TAF
> connection.
> =20
> I have defined a TAF connection with a PRECONNECT
> using both Primary and Secondary=20
> connections each including a backup to each other.
> =20
> So I already have a connection to the second
> instance open as well as the first instance, of
> course.
> =20
> 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.=20
> =20
> When the second instance takes over as now the
> PRIMARY instance my select resumes at exactly the
> same place it left off.=20
> =20
> For clarity, my libcache update job has not updated
> the executed SQL from the first instance onto the
> second instance.=20
> =20
> So the cursor must be copied, re -executed and a
> reference to the current rownum must be passed.=20
> =20
> Question:=20
> Can someone explain from where the SQL and rownum is
> obtained?=20
> Regards,
> Peter
> --
> Peter Lomax
> tel: 0155881546
> fax: 0155881594
> 65-67, avenue Vladimir Illich L=E9nine
> 94110 Arcueil
> email:
> =20
> --



Do you Yahoo!?=20
Yahoo! Mail - Find what you need with new enhanced search.
Received on Mon Dec 06 2004 - 07:42:44 CST

Original text of this message