Skip to Content
Technical Articles
Author's profile photo Juan Reyes

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

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      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?

      Author's profile photo Juan Reyes
      Juan Reyes
      Blog Post Author

      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