| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: OPS, TAF and jAVA
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: ORACLE-L_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
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!"
>
> 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: 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).
<< taf-1.rtf >>
-- 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).Received on Wed Jun 06 2001 - 09:43:53 CDT
 |
 |