Re: Db2, Oracle, SQL Server

hpuxrac apparently said,on my timestamp of 16/02/2005 12:25 PM:

> Sure the RAC database continues to operate while thread recovery is
> done

according to the IBM Oracle experts, it doesn't.

> but it can certainly impact users and applications that have
> uncommitted changes from the failing node.

Of course. If you take away the computer, the program can't continue. Ergo, its pending units of work (transactions) must be rolled back.

> What's the impact on other
> users and applications while recovery is occurring.

The fundamental difference with RAC is that the OTHER nodes CAN recover the interrupted transactions WITHOUT having to bring the crashed node's database back up. Pretty much linear. And that's what no one else can do. Not without some external intervention. Possible exception for Teradata: don't know enough about it to comment.

Although of course all dbs - RAC or non-RAC - can restart the lost node database with a batch scheduler. Don't need to pay extra for something like HACMP for that either: any pea-brained *nix admin can do the same.

> It depends is the honest answer ... it depends on how much uncommitted
> work was being performed, what the other sessions are trying to access
> ... etc.

Well, with RAC it doesn't depend. It's just linear: any node can recover any other node's crashed transactions. Automatically and WITHOUT external intervention or initiation.

> Sorry I don't understand what you mean by "0 - yes, ZERO - seconds to
> continue to operate". And I guess I thought that was Dan saying that.

The recovery of the failed node's transactions is automatic and handled by the remaining nodes. With negligeable impact in any other node.

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.

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
wizofoz2k_at_yahoo.com.au.nospam