Re: tough choices

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Fri, 18 Jun 2004 18:48:44 GMT
Message-ID: <gOGAc.6827$1u1.2440@newssvr24.news.prodigy.com>

Howard J. Rogers wrote:

> "Michael Austin" <maustin_at_firstdbasource.com> wrote in message
> news:tHoAc.6647$A84.4853_at_newssvr24.news.prodigy.com...
>

>>Niall Litchfield wrote:
>>
>>
>>>"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
>>>news:1087421232.498660_at_yasure...
>>>
>>>
>>>>The main consideration I would think would be the overhead of federating
>>>>data for DB2. The more data the more difficult and time consuming and
>>>>the fact that losing nodes with RAC is an inconvience ... with DB2 you
>>>>have a lot more to worry about ... and mean time between failures goes
>>>>down, not up, as you add nodes.
>>>
>>>
>>>I'd be impressed with a RAC 'scalability' solution that didn't have

>
> higher
>

>>>downtime than an appropriately sized single node equivalent. More

>
> complexity
>

>>>= less screwups is an equation with which I am unfamiliar :) The same of
>>>course applies to IBM clustered solutions.
>>>
>>
>>Daniel,
>>
>>If I understand the correct programming of a RAC application is to have
>>a connection to multiple nodes in the cluster simultaneously and if
>>there is a failure, the transaction continues unscathed on another node
>>in the cluster. I have seen this demonstrated to be true.

>
>
> PMFJI, but no you haven't. You've seen selects resume on another node. You
> won't have seen a *transaction* resume on a surviving node, because that is
> not possible. What you're talking about is something called Transparent
> Application Failover or TAF. It works for selects only, and only for
> applications that use OCI somewhere in their connectivity (ie, it doesn't
> work for a thin Java app, for example). Incidentally, TAF does not require
> you to connect to multiple nodes simultaneously. You can do so if you wish,
> using the PRECONNECT connection method. But the default is not to, meaning
> that if the node you are connected to dies, you have to inititate a fresh
> connection to the RAC (that's the BASIC connection method).
>
> Also incidentally, TAF goes a long way further back than RAC, and works for
> example in a standby database, or Data Guard, configuration. It is not a
> RAC-specific technology.
>
>

>>So, what this
>>should mean is that even though you may have a node crash, your
>>application AND database AND transactions will survive with no
>>"downtime" experienced by the end user.  The application and database is
>>available 100% or as near 100% as you can get...

>
>
> Well, see, that's just not true. A select statement, maybe, yes, sort of
> (depends on how you define 100%, I think: there is a delay in resuming the
> select statement, because it can't resume until LMON on surviving nodes has
> performed instance recovery. The user would certainly 'experience' such a
> delay). But for DML, nowhere close: the statement fails, is rolled back by
> PMON, and has to be re-performed from scratch. That is definitely an
> 'experience' of downtime by a User.
>
>

>>According to Oracle marketing and technical folks (2 years ago), this
>>really only worked as advertised on 2 platforms.  Can you guess which
>>ones they were??

>
>
> You'll have to refresh my memory, but from my own personal experience, two
> years ago, TAF was working as advertised on Windows and Solaris and Linux.
> And Tru64, too.

Tru64 and OpenVMS... the others had to do some gyrations with the filesystems on Windows and Solaris after the original node crashed... IIRC -- didn't take long, just longer than the reuqired instance recovery on a surviving node. As I said this was 2 years ago and the grey-matter gets clouded sometimes... :)

Michael.

>
> Regards
> HJR
>
>
>

>>You mentioned that you have a multi-node Linux cluster using a NAS-head
>>for disk access... Can you provide me a pointer to the details of the
>>complete configuration?  I am not opposed to learning new configurations
>>and platforms.  What do you see as it's weaknesses and strong-points.
>>
>>Michael Austin.

>
>
>
Received on Fri Jun 18 2004 - 13:48:44 CDT