Some notes from the recent IoD 2010 DB2 HA Session:
> 2 modes when installing – DB2 Cluster Manager:
1.) Shared storage – install db2 on one node
2.) Database Partitioning Feature, DPF – Single partition between 2 partition x db2 resource groups
Future is ‘Roving HA’ for Warehouse - Elimnates the need to failback – failed server new standby
> HADR – log writer/reader to standby : (Log replay) 3 modes:
- Synch – written record to both
- Near Synch - receiver on standby has it in memory
- Asynch – primary sends it – most risky
DB2 HADR in archival mode using TSM, calls log back then ships them
When using WAS – enabled failover between database servers using ‘seamlessfailover’ customer property in Resources
For Fix Pack upgrades this approach is only recommended:
- Deactivate hadr on standby
- Run upgrade on standby
- Start HADR on standby – let it catchup
- Then issue takeover cmd
- Repeat above on Primary
Find “hdrsethdrstate” in db2diag to determine state of HADR on service.
> Performance tips in HADR environment:
- Recommend leaving STM – Self Tuning Manager running in HADR environment
- Look at Logindexbuild db cfg parameter - all index pages available improving reads
- DB2_HADR_ROS – read on standby – performance gain – takeover – primary automagically goes into read/write
> DR Considerations:
- RTO – recovery time objective
- RPO – recovery point objective
- In future more transactions will be replicated in HADR via Q-Replication. A DR site will use a mix of HADR and Q Replication for optimum results.
