Re: tough choices

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

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 Thu Jun 17 2004 - 17:28:15 CDT