Daniel Morgan wrote:
> Niall Litchfield wrote:
>
>> "Rob Cowell" <rjc4687_at_hotmail.com> wrote in message
>> news:40211355.94A43A97_at_hotmail.com...
>>
>>>> And that I thought Oracle had some facility
>>>> such that we could cluster and load-balance two+ nodes running
>>>> something like Parallel Oracle so that should a node need booting
>>>> or modifying off-line the application is still running (at
>>>> reduced capacity) for the users.
>>>
>>> Oracle Real Application Clusters
>>
>> http://tahiti.oracle.com/pls/db92/db92.show_toc?partno=a96597&remark=drilldown&word=real+application+clusters
>>
>> Just to add to that, if you are writing the app from scratch RAC also
>> supports a technology (transparent application failover) where users
>> connected to a node that fails will failover to a running node without
>> dataloss and without being disconnected from the application. I am
>> unsure if
>> IBM have a similar technology
>
> Only on mainframes. With shared nothing if you lose a node ... the
> storage associated with that node is lost too.
Yep. Also, I really don't want to sound like I'm picking only on Oracle,
because I complain about other DBMSes too. Oracle's TAF fooled a number
of customers into believing it really was Transparent Application Failover,
but it seems to be so only for certain mostly-idle clients. The reason I
say this is because while there is no data loss during a failover, nor
even any transactional context (locks), what is lost is any *computational*
context that the client may be relying on if it was actually doing
something when the failover occurred. For instance, most cursor context
is lost. Java clients that may have created and are re-using Prepared
Statements will find that all those prepared statements are now defunct,
and must be recreated before the client can even retry what they were doing.
This generally means returning to the line of code right after obtaining the
original connection. Having the connection automatically failover to an
appropriate backup DBMS is certainly valuable, but calling it "TAF" was
'aiming high' in the marketing department, IMHO.
Joe
Received on Wed Feb 04 2004 - 11:04:44 CST
