Re: Db2, Oracle, SQL Server

hpuxrac wrote:

> Sorry but "... impact in any other node".
>
> No, the correct answer is it depends. How many nodes in the cluster,
> how much work needed to re-master resources, how much work needed to
> actually do recovery, etc.

Here we go again with the "remaster" nonsense... There is no "re-mastering" anything in RAC. Lose the term: it's incorrect for RAC. Clear? We're not talking SQL Server or other shared-nothing database architectures.

> There are multiple passes performed during instance recovery by the
> instance responsible for the recovery. In the worst case of course
the
> instance that is starting to do the recovery also fails.
> Unlikely? Very unlikely... but possible.

Of course. What's that got to do with the other nodes?

> > Unless of course you were running a HUGE batch job in the failed
> node.
> > In which case you'll impact the performance of whatever other node
> > initiates the auto recovery of such job. Enter the load balancer
>
> "unless" or "in which case" ... Ok are you agreeing that the zero
> seconds answer is not totally accurate?

Not at all. There is 0 second impact on any other node not involved in the recovery. And there is 0 second impact on any other node while the rollback doesn't start. And the rollback starts automatically, it doesn't need HACMP or similar to do it.

If you allocate specific portions of your data to given nodes and re-direct traffic to them, like IBM did in the benchmark mentioned here, then you have NO OPTION whatsoever to recover access to the data in any failed node other than re-start that failed node. Which is a finite time operation requiring external intervention (manual or automatic is immaterial) and completely non-transparent.

There is NO SUCH restriction in RAC: you can access data to ANY partitioned table from ANY other node, at ANY time, regardless of which node(s) crashed and whatever is being done to recover. 0 second impact to acess data, complete transparency. Something that DB2's sorry arse will never achieve, nor SQL Server, with the configuration used in these benchmarks.

> In the real world, lots of people do run HUGE batch jobs ... all the
> time. In the world I live in, lots of people have a smaller rather
> than larger number of nodes in their RAC clusters.

In the real world, no one in his right mind pays any attention to the crap put out by TPC, their "real life benchmarks" and/or their totally unrealistic configurations.

And that goes for ALL products tested in TPC, not just DB2 or SQL Server: there are some really "wild" Oracle configs in there as well... Received on Thu Feb 17 2005 - 19:40:46 CST