RE: Microsoft VS Oracle (again)

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).