Interesting. For some reason, the term "transparent failover" sticks in my head. Then again, I was remembering incorrectly. The Oracle Workload Generator demo was for load-balanced queries between the two nodes of the RAC. The failover was a SQL statement run from SQL*Plus, which probably comes "TAF aware" or can be made to with a simple relinking.
Thanks for the clarification, Nick! Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA > -----Original Message----- > From: Nick Wagner [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 02, 2003 12:41 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Microsoft VS Oracle (again) > > > there are a couple of finer points that are left out... > > There are really two versions of TAF that they are talking > about here... > > 1) Session Failover -- it's easy to do, just rebuild the > TNSNAMES.ORA file on the client machine, and create a backup > connection. If the connection fails to connect to the > primary, it will retry it on the secondary, after XX number > of seconds (and a couple other options as well.) The client > has no idea that it even reconnected. This works with about > 99% of applications written with OCI8. However, since all it > does is reconnect the user, any in process transactions are > lost, and the user does not know it until they try and > commit, and then they select that data back, and only half of > it is there. It's a risky solution, but works GREAT for demos. > > 2) Session Failover and reprocessing of in process > transactions - This method actually replays any in process > activities on the secondary node, and then allows the user to > continue on as if nothing happened. This is one way not to > have perceived data corruption. But it does require > extensive modification to the OCI connection layer so that > the Client product is 'TAF aware' And it means the client > software must record all the uncommitted activity that a > session does, so that when oracle fails it to the other > machine, it knows to replay that activity before giving any > response back to the user. This works today in SQL*Plus > without any modification (try it it's pretty cool) but will > require HUGE amounts of code changes to any other app to get > it to work. (i.e. try it with Oracle forms, or People Soft > clients -- no chance it will work.) > > so, the Microsoft is right and wrong at the same time... odd > how they do that so well. > > Nick > > -----Original Message----- > Sent: Wednesday, July 02, 2003 10:04 AM > To: Multiple recipients of list ORACLE-L > > > Has anyone read the articles? One point states that failover for RAC > requires coding changes to take advantage of it. Not from > the demo I saw. > HPaq (or whoever they are these days) took a circa '99 Oracle test GUI > called Oracle Workload Generator and got failover to work > with only changes > to the sqlnet.ora. I've seen the demo twice, once with Unix > servers and > once with Windohs servers (since the app is Windohs, the > client had to be > Windohs), and while the Unix did the failover much faster > (1-2 secs vs. > 20-30 secs), both worked seamlessly. As an aside, the load balancing > queries worked flawlessly, too. > > So, what's the case for code changes? > > Makes me want to read the articles further... > > Rich -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
