Adaptive compression and HADR

Question

I'm looking into adaptive compression. I can't seem to find any information on how HADR is affected when a table is compressed and then reorg:ed. Example

t=mytable
db2 "alter table $t compress yes adaptive";
for i in $(db2 -x "select rtrim(indschema) || '.' || rtrim(indname) from syscat.indexes where rtrim(tabschema) || '.' || rtrim(tabname) = '${t}' order by 1"); do
    db2 "alter index $i compress yes"
done

db2 "reorg table $t resetdictionary";
db2 "reorg indexes all for table $t"
db2 "runstats on table $t with distribution and sampled detailed indexes all";

Question is whether I need to bring down HADR during this process and restart it once finished, or is everything captured in the log, so that HADR can continue?

Answer 1

Both online and offline reorganization are logged and therefore replicated by HADR. By stopping HADR you will simply allow the standby to fall behind the primary, which will cause a large spike in traffic (and potential log space issues on the standby) when you restart HADR. If you don't suffer from network congestion during normal operation, there's no reason to stop HADR during reorganization. If you do, consider dropping the the standby and rebuilding it anew after the REORGs on the primary are complete.

Answer 2

You must be aware of the logindexbuild database parameter setting and its influence on the index maintenance on the standby after replay of an offline REORG operation (every table has an attribute with the same meaning as well).
If COALESCE(logindexbuild_table_attribute, logindexbuild_db_parameter) == OFF for a table, and you reorged this table offline, then all table indexes are marked invalid on the standby and must be rebuilt there, when the standby becomes primary. Such a rebuild is done automatically, but it may take some time and may be not desirable especially for large tables.

You shouldn’t REORG table indexes on primary after offline table REORG - it’s done at the last phase of the table reorg process automatically.

You may consider to deactivate HADR temporarily, but it’s not related to completeness of logging. Replay of a large offline reorg operation may lead to HADR congestion, which may block other transactions on primary. If you deactivate standby before such an operation on primary, you may avoid such a congestion but you may loose transactions in case of come disaster.