Re: DB2 HADB

From: Mark Townsend <markbtownsend_at_comcast.net>
Date: Thu, 24 Nov 2005 19:17:54 -0800
Message-ID: <43868262.3090901@comcast.net>

Rodrick Brown wrote:
> Has anyone worked with DB2 HADB? from what I gather it sounds exactly
> like dataguard? can anyone run through the differences if any thanks.

DB2 HADR. IBM has published a WP that compares HADR to Data Guard

ftp://ftp.software.ibm.com/software/data/pubs/papers/hadr-comp.pdf

I can't download the paper, so not sure what is in it.

Oracle's paper comparing IBMs HA capabilities with Oracle's can be found here -
http://www.oracle.com/technology/deploy/availability/pdf/CWP_HA_Oracle10gR2_DB28.2.pdf

HADR for DB2 is based on the earlier HDR capabilities provided in Informix

A quick analysis of HADR from IBM's own doc shows that 1) True no loss log shipping requires a remote mirrored disk sub system. If you have a remote mirrored disk sub system then you really don't need HADR anyhow
2) Index rebuilds on the primary are not done on the standby at the point they occur. The are done when first accessed after the standby becomes a primary. So presumably you cannot failover quickly, as immediately after failover, index rebuilds may be required. Not sure if the index rebuild in DB2 is an online or offline op. 3) Any non-logged operation on the primary is not replayed on the standby. IBM recommends that the standby be rebuilt after all non-logged ops
4) Resync/Rebuild requires either a new backup from the primary, or a copy of the primary, typically using split mirrors. 5) If the two databases aren't in communication during a fialover - (i.e perhaps the network has gone down), then you have to rebuild the primary as a secondary in order to bring it back 5) It doesn't look like you can take backups of the standby and recover them to the primary

6) It doesn't work if the DB2 database is partitioned
7) There is no equivalent to Data Guard logical standby in HADR
8) You need to tell DB2 to log index build operations on the primary in 

order for them to be replayed on the secondary. This "means that index builds might take longer on the primary sytem and that more log space is required"
9) New (or changed) Stored procedures and UDFs are not replayed to the secondary
10) Online re-orgs on the primary generate lots of log files, which slow down the primary. Offline re-orgs on the primary generate less log files (and in some cases only one), with the result that the standby may fall behind the primary - while the re-org is happening on the primary, nothing is happening on the standby, once the re-org finishes on the primary, and transaction work starts again, the secondary needs to start and finish the reorg befor eit can continue normal ops. If the re-org takes a long time, then the standby is this amount of time behind the primary
11) Received on Thu Nov 24 2005 - 21:17:54 CST