Re: DB2 HADB

"Mark Townsend" <markbtownsend_at_comcast.net> wrote in message news:43868262.3090901_at_comcast.net...
> 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

That is not accurate. With synch mode in HADR, the commit on the primary will not complete until the logs are written to disk on the standby, but this is not shared or mirrored disk. With near synch mode, the commit will guarantee that the replay is written to the log buffer on the standby.

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

Not true. If you set LOGINDEXBUILD to ON, then index builds (such as from a reorg) are replayed on the standby. You have choice if you want this.

> 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

All SQL (DDL and DML) can be logged except for LOB's that are over 1 GB in size.

> 4) Resync/Rebuild requires either a new backup from the primary, or a copy
> of the primary, typically using split mirrors.

Or a snaphot can be used if one has that technology (such is available from NetApps and others).

> 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

That depends on the timeout setting you configure. You can configure a very long timeout period if you want to.

> 5) It doesn't look like you can take backups of the standby and recover
> them to the primary

Once the standby becomes the primary (when takeover occurs) then you can make a backup. You can acutally make a backup of the standby if you take it out of HADR mode, but synchronization with the primary will cease during that time.

> 6) It doesn't work if the DB2 database is partitioned

It will work with range partitioning (in DB2 V9, which is not available yet) but as you state it is not available for partitions that are on mutliple nodes.

> 7) There is no equivalent to Data Guard logical standby in HADR

If you mean read access on the standby, then you are correct, but IBM has said that it will probably be available next year (no guarantees of course).

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

In number 2 above you said it was not even possible, now you say it takes longer. Obviously it takes longer, even on Oracle it takes longer to replay index build operations as they occur. Disk space is ridiculously cheap these days.

> 9) New (or changed) Stored procedures and UDFs are not replayed to the
> secondary

You can't change a SP or UDF in DB2 (drop and recreate). I was not aware that a new SP would not replay, but I will check this out. I don't recall reading that in the doc.

> 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

This is a repeat of number 8. You make it sound like Dataguard can do these things with no performance lag, which is ridiculous. Received on Thu Nov 24 2005 - 21:43:32 CST