Re: TAF

Exactly that is what my benchmarks have also noticed.

Couple of other points...

1. Since the PRECONNECT always maintains a connection with the secondary instance, there is a 2% overhead compared to the BASIC option.
2. I don't and did not see the need for a PRECONNECT option. Off course like Tim indicates there is potential traffic jam situation in the case of the BASIC option and there could be small delay. Unless your application is being developed for the Stock Exchange or for the space station (where such an application may not be useful anyways) I mean machine critical nature you should not have to worry.
3. You could use the RETRY/DELAY option combined with the BASIC option to cover for any failures/timeouts when the jam occurs.

I had a paper presented on this very subject at the 2001 Open world. You should find it on the Oracle website.

Regards

Murali Vallath

Reply-To: ORACLE-L_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: Fri, 07 Jun 2002 05:18:27 -0800

Fawzia,

PRECONNECT establishes the second/failover database connection along with the first/primary, so your client-server database connection is really client-server1/server2. Should the first/primary connection fail, then you failover to the second.

BASIC establishes only the first/primary database connection but has the information available to establish the second/failover connection should the first/primary fail.

PRECONNECT will failover faster, as the second/failover connection has already been established. In a large environment (i.e. hundreds of database connections) full of BASIC connections, you can expect the mass exodus from one database instance to the failover to cause BASIC connections to wait a noticeable amount of time.

One problem with PRECONNECT that I've noticed is the scenario where the second/failover instance is terminated for some reason first. Let's say a bunch of PRECONNECT TAF connections are working away happily via their first/primary connection to the primary database instance, and there is some reason to terminate the second database instance or some/all of the second/failover database connections to the second database instance. In this case, PRECONNECT will not notice the loss of the second/failover database connection, allowing the first/primary connection to continue working happily away. But after bringing the second database instance back online, if the first database instance should now fail, then all those PRECONNECT sessions will simply fail.

Upshot: BASIC is more "robust", because it fails over only when it needs to, but you can get caught in a "traffic jam" in the event of failover. PRECONNECT can fail over faster because of previously established failover connections, but if anything happens to that second connection after the time it is established, then you'll be out of luck.

Hope this helps...

-Tim

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, June 07, 2002 5:43 AM

>
> Hi ,
>
> I am configuring TAF on oracle 8.1.7 (solaris). I was just wondering if
> anyone on the list has had experience on this and can give me any advice-
> more specifically on the the method- preconnect and basic. Are there any
> significant benefits of having the preconnect setting set?
>
> Any input would be really appreciated..
>
> Rgds
>
> Fawzia
>
>
> **********************************************************************
> Information in this email is confidential and may be privileged.
> It is intended for the addressee only. If you have received it in error,
> please notify the sender immediately and delete it from your system.
> You should not otherwise copy it, retransmit it or use or disclose its
> contents to anyone.
> Thank you for your co-operation.
> **********************************************************************
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Malik, Fawzia
> INET: Fawzia.Malik_at_bskyb.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
   INET: Tim_at_SageLogix.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).





Murali Vallath
Oracle Certified DBA
http://www8.ewebcity.com/muralivallath/
http://www.summerksyus.com/


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Murali Vallath
  INET: murali_vallath_at_hotmail.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).