I have seen number of TAF papers on metalink and google. But wanted to get
some user experience.
This input is great.
Thanks
Murali
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2001 01:19:36 -0800
Yes. Search on MetaLink. Look in the Net8 docs. There are a lot of
options and some significant constraints. It might take a while for you to
do the research and analysis and to figure out what works best for your
system(s), running your application(s).
Attached is one paper, but don't stop with it alone. It was simply "handy",
so I attached it. I don't remember where I got it - probably off MetaLink,
but it could be an extract from the Oracle docs. The "formatting" is
butt-ugly, so it was probably a cut-and-paste deal. I chose it to include
because it doesn't gloss over the "transparent application failover" bit as
much as most. It isn't entirely "transparent" in all (many?) cases! See
the section "6. Coding for Failover" in the attached file. There is some
much more detailed information on this somewhere - I just don't have it at
hand. When I was initially researching this, I found a long "daisy chain"
of references on MetaLink.
You didn't mention what version of Oracle you are using - on the server or
on the client(s)! It is important. For example, I believe that dynamic
instance registration is only available in 8i. Instance roles in an 8i OPS
environment may make a difference also. The construction of the clients'
tnsnames.ora entries will likely depend on the client version as well - and
you may have several different client versions to contend with.
TAF against an OPS cluster works very well if the application is amenable
and everything is configured properly. I have set it up so that most
connections/sessions/queries into an extremely hot OLTP system could
"automagically" fail over to an alternate node within <20 seconds in most
outage scenarios. (Your mileage may vary - considerably.)
Be aware of the TCP timeout issue - as mentioned in this paper. Tuning TCP
timeout is not an Oracle issue, it is a system issue, but if a node goes
entirely belly up, your client connections will be waiting on a TCP timeout.
Don't forget to tune and test it.
Tuning instance recovery is important to minimize the "brownout" period -
the time required for a surviving instance to perform instance recovery on
behalf of a failed instance and for reconfiguration of the lock table,...
This can be somewhat "bounded" in 8i. There is some material on this in the
OPS manuals and in the Oracle8i Tuning manual.
Most importantly, test everything rigorously - instance failure, listener
failure, node crash, all types of clients, etc. You don't want your
application to hang when something goes wrong on that brand new "highly
available" OPS system for which you just spent the big bucks!
Also, have a plan for switch-back and/or fail-back - perhaps different
mechanisms for different clients and different server-side processes.
Considering the entire processing cycle of the application is sometimes not
considered early enough in the planning. How are cron jobs and other
batch-lookin' thingies going to behave? How will they "fail over" in the
event of a prolonged node outage? When can they switch-back to their
primary home without clobbering performance by inducing mass quantities of
OPS overhead? How do you choreograph the entire inter-node process shifting
ballet for both fail-over and switch|fail-back? Is there a "central
autority" or does each client do its own thing? (TAF implies the latter).
What happens if there is some kind of "false alarm"? (e.g. What if only
half the clients fail over - due to a localized transient network glitch
perhaps? Does that induce extreme OPS-specific performance problems?)
I can't speak to Java. (Heck, I can't even speak Java!) However, there
seem to be significant differences between the TAF capabilities of thick and
thin Java since thick is (?) built on an OCI layer, but thin isn't. (And
there can be significant differences in thick & thin compatibility/issues
with CURSOR_SHARING=FORCE! Or so I hear.)
Thankfully, your request was quite reasonable - guidelines, concerns, tips,
etc. I hope this helps, but it is definitely going to take some work on
your part!
I'm not trying to scare you, or anyone else, off of OPS. I just have
visions/nightmares about what will happen when 9i ("You won't need a DBA
anymore!" ) and Real Application Clusters ("Easy, trouble-free parallel
server for the masses!" ) hit the street! OPS may not be rocket science,
but it isn't exacty "paint by the numbers" either. And I'll wager that even
a much more "user-friendly" RAC still won't be, in spite any propaganda to
the contrary!
-Don Granaman
[Certifiable OraSaurus]
"OPS - Not just for breakfast anymore!"
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 11:22 AM
>
> We are looking at using TAF (never used before) for application fail
over.
> First, any guidelines we should be aware of in general.
> Second any specific concerns using TAF with applications using JAVA.
> Any stuff on how does TAF and OPS work in harmony?
>
> Regards
>
> Murali Vallath
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Murali Vallath
> INET: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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).
<< taf-1.rtf >>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Murali Vallath
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
