"Sanjuro" <as******@gmail.comwrote in message
news:11**********************@g4g2000hsf.googlegro ups.com...
Well, in this particular case, I have convinced the client that the
manual takeover would be available and the impact on business would be
15 minutes (time it takes to wake up DBA/SA) or so in the worst case
and they are fine with that.
On a broader perspective, how would I fight Oracle DataGuard which
provides in-built functions for automatic failover (or so I have been
made to believe). Of course with v9 Express, DB2 beats Oracle by 25:1
on price.
Cheers,
Sanjuro
Although DB2 can do a takeover by force rather quickly (even faster than
Data Guard), there is no foolproof "instantaneous" method of getting the
application tier to try the alternate server with HADR (or Data Guard) until
the TCP/IP timeout limit on the client has been reached, which in many cases
can be up to 10-20 minutes. This is why you may want to consider a cluster
manager that can do a virtual IP address switching between servers in
addition to client reroute. TSA can do that, but there are also 3rd party
products such as Veritas with HADR Agent that works better IMO (better than
TSA). Not sure if Veritas HADR Agent works with Windows.
In my experience, TSA is over-engineered, and consequently is so complex
that no one even at IBM completely understands how it works with HADR. I am
basing this on talking to many people at IBM, including those from the IBM
Germany lab where TSA is developed. However, IBM has promised better
integration with HADR and TSA in the future, and I look forward to when it
becomes a reality.
OTOH, I think IBM has been distracted by Xkoto, which could provide
continuous availability for DB2, and I am not sure how committed IBM is to
HADR in terms of major improvements and integration with TSA. If Xkoto works
as designed, it would be the RAC killer, but like any new software, there
are some bugs to work out.