Technical Articles
How to disassemble a DB2 HADR/Cluster into a Standard DB2 database
There is tons of information about setting up High availability for IBM DB2 database but not a lot about taking it apart. Probably is not something you need to do everyday but I had to change the landscape of one of my environments and this is how I achieved it.
- First thing you need to do is to make sure the database you want to keep is set as primary
- You can check this via lssam or by checking the database config parameter “HADR database role”
db2 get db cfg for <instance> | grep “HADR database role”
HADR database role = PRIMARY
- Stop SAP
- Ermm, stopsap
- Stop HADR and deactivate both databases (do not stop the database manager on primary)
- On Standby
- Deactivate -> db2 deactivate db <instance>
- Stop HADR -> db2 stop hadr on db <instance>
- db2stop
- On Primary
- Stop HADR -> db2 stop hadr on db <instance>
- Deactivate -> db2 deactivate db <instance>
- On Standby
- list your HADR parameters
- db2 get db cfg for <instance> | grep HADR
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) = <primary_host>
HADR local service name (HADR_LOCAL_SVC) = <SID>_HADR_1
HADR remote host name (HADR_REMOTE_HOST) = <standby_host>
HADR remote service name (HADR_REMOTE_SVC) = <SID>_HADR_2
HADR instance name of remote server (HADR_REMOTE_INST) = db2<sid>
HADR timeout value (HADR_TIMEOUT) = 120
HADR target list (HADR_TARGET_LIST) =
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
HADR spool log data limit (4KB) (HADR_SPOOL_LIMIT) = AUTOMATIC(982800)
HADR log replay delay (seconds) (HADR_REPLAY_DELAY) = 0
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 300
- On the primary database disable the HADR parameters using…
db2 update db cfg for <instance> using HADR_LOCAL_HOST NULL
db2 update db cfg for <instance> using HADR_LOCAL_SVC NULL
db2 update db cfg for <instance> using HADR_REMOTE_HOST NULL
db2 update db cfg for <instance> using HADR_REMOTE_SVC NULL
db2 update db cfg for <instance> using HADR_REMOTE_INST NULL
stop the database manager and start it again. (db2stop/db2start)
- delete the high availability configuration (very important!!)
- db2haicu -delete
- uninstall the SAMP cluster in both database hosts (from root)
./opt/IBM/tsamp/sam/uninst/uninstallSAM
- update your SAP profile parameters to point to the single host instead of the virtual host
- parameters SAPDBHOST and j2ee/dbhost
- update your db2cli.ini to point to the single hosts instead of the virtual host
- parameter Hostname
- start your DB2 instance normally
- db2start
- db2 activate db <instance>
- start your SAP system
- startsap
Now you have a standalone database and you can decommission your standby database host!!
Love to hear your comments.
This is good but have you tried to convert your Standby database to Standard so that you can use it as per usual?
Why would you want to do this? One scenario is during a db2 upgrade. It saves us taking a full db backup (pre-upgrade) and if the primary hadr upgrade fails, then I can just bring up the Standby->Std database online very quickly.
I'm wondering if anyone has done this - if so, any catch-yas?
You can now upgrade HADR systems without having to break HADR or reinitialize your standby database,
Read,
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.qb.upgrade.doc/doc/t0070029.html
Regards, JP