` refers to the System ID (SID) of the Db2 database (for example, `PR1`)._HADR_1 55001/tcp # DB2 HADR Port1
_HADR_2 55002/tcp # DB2 HADR Port2
Confirm that both ports allow inbound and outbound traffic between both the primary and the standby.
3. Check `/etc/hosts` in the production and DR hosts to confirm that hostnames for both production and standby hosts are pointing to the correct IP addresses. | AWS administrator, SAP Basis administrator |
| Set up replication from the production DB to the DR DB (using ASYNC mode). | 1. In the production database, run the following commands to update the parameters.db2 UPDATE DB CFG FOR USING HADR_LOCAL_HOST HOST1
db2 UPDATE DB CFG FOR USING HADR_LOCAL_SVC _HADR_1
db2 UPDATE DB CFG FOR USING HADR_REMOTE_HOST HOST2
db2 UPDATE DB CFG FOR USING HADR_REMOTE_SVC _HADR_2
db2 UPDATE DB CFG FOR USING HADR_REMOTE_INST db2
db2 UPDATE DB CFG FOR USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR USING indexrec RESTART logindexbuild ON
2. In the DR database, run the following commands to update the parameters.db2 UPDATE DB CFG FOR USING HADR_LOCAL_HOST HOST2
db2 UPDATE DB CFG FOR USING HADR_LOCAL_SVC _HADR_2
db2 UPDATE DB CFG FOR USING HADR_REMOTE_HOST HOST1
db2 UPDATE DB CFG FOR USING HADR_REMOTE_SVC _HADR_1
db2 UPDATE DB CFG FOR USING HADR_REMOTE_INST db2
db2 UPDATE DB CFG FOR USING HADR_TIMEOUT 120
db2 UPDATE DB CFG FOR USING HADR_SYNCMODE ASYNC
db2 UPDATE DB CFG FOR USING HADR_SPOOL_LIMIT 1000
db2 UPDATE DB CFG FOR USING HADR_PEER_WINDOW 240
db2 UPDATE DB CFG FOR USING indexrec RESTART logindexbuild ON
These parameters are required to provide HADR-related information to both databases. In the Db2 database, HADR gets activated based on the values for each of the previously set parameters. For more information about these parameters, see the [IBM documentation](https://ibm.github.io/db2-hadr-wiki/hadrConfig.html#HADR_Database_Configuration_Parameters).
3. Start HADR first on the newly created standby database by using the following command.db2 deactivate db
db2 start hadr on db as standby
4. Start HADR on the production database by using the following command.db2 deactivate db
db2 start hadr on db as primary
5. Check whether the production and standby Db2 databases are in sync and log shipping is ongoing.
To monitor HADR replication status, use the following `db2pd` command.db2pd -d -hadr
For more information about monitoring HADR, see the [IBM documentation](https://ibm.github.io/db2-hadr-wiki/hadrMonitoring.html#db2pd__hadr). | SAP Basis administrator |
### Test DR failover tasks
| Task | Description | Skills required |
| --- | --- | --- |
| Plan the production business downtime for the DR test. | Make sure that you plan the required business downtime on production environment for testing the DR failover scenario. | SAP Basis administrator |
| Create a test user. | Create a test user (or any test changes) that can be validated in the DR host to confirm log replication after DR failover. | SAP Basis administrator |
| On the console, stop the production EC2 instances. | Ungraceful shutdown is initiated in this step to mimic a disaster scenario. | AWS systems administrator |
| Scale up the DR EC2 instance to match the requirements. | On the EC2 console, change the instance type in the DR Region.1. Stop the instance: If the instance is running, you must stop it before you can change its instance type. On the EC2 console, select the instance, and choose **Stop**.
2. Modify the instance type: On the EC2 console, select the instance, and choose **Actions**, **Instance Settings**, **Change Instance Type**. Select the instance type that matches the primary instance, and choose **Apply**.
3. Start the instance: After the instance type change is complete, start the instance from the EC2 console by selecting the instance and choosing **Start**.
4. To start the Db2 database, use the following command.db2start
db2 start HADR on db as standby
| SAP Basis Admin |
| Initiate takeover. | From the DR system (`host2`), initiate the take-over process and bring up the DR database as the primary.db2 takeover hadr on database by force
Optionally, you can set the following parameters to adjust database memory allocation automatically based on the instance type. The `INSTANCE_MEMORY` value can be decided based on the dedicated portion of memory to be allocated to the Db2 database.db2 update db cfg for using INSTANCE_MEMORY IMMEDIATE;
db2 get db cfg for | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE;
db2 update db cfg for using self_tuning_mem ON IMMEDIATE;
Verify the change by using the following commands.db2 get db cfg for | grep -i MEMORY
db2 get db cfg for | grep -i self_tuning_mem
| SAP Basis administrator |
| Launch the application server for SAP in the DR Region. | Using the AMI that you made of the production system, [launch a new additional application server](https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/) in the DR Region. | SAP Basis administrator |
| Perform validation before starting the SAP application. | 1. Validate the `/etc/hosts` and `/etc/fstab` entries.
2. Mount `/sapmnt//` on the DR system.
3. Validate that the DR file system `/sapmnt//` is synced with the production `/sapmnt//`.
4. Log in to `adm` user, run `R3trans -d`, and verify the output in the `trans.log` file. The `trans.log` file is generated in the same location where you ran the `R3trans -d` command. | AWS administrator, SAP Basis administrator |
| Start the SAP application on the DR system. | Start the SAP application on the DR system by using `adm` user. Use the following code, in which `XX` represents the instance number of your SAP ABAP SAP Central Services (ASCS) server, and `YY` represents the instance number of your SAP application server.sapconrol -nr XX -function StartService
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService
sapconrol -nr YY -function StartSystem
| SAP Basis administrator |
| Perform SAP validation. | This is performed as a DR test to provide evidence or to check the data replication success to the DR Region. | Test engineer |
### Perform DR failback tasks
| Task | Description | Skills required |
| --- | --- | --- |
| Start the production SAP and database servers. | On the console, start the EC2 instances that host SAP and the database in the production system. | SAP Basis administrator |
| Start the production database and set up HADR. | Log in to production system (`host1`) and verify that the DB is in recovery mode by using the following command.db2start
db2 start HADR on db P3V as standby
db2 connect to
Verify that the HADR status is `connected`. Replication status should be `peer`.db2pd -d -hadr
If the database is not inconsistent and is not at `connected` and `peer` status, a backup and restore might be required to bring the database (on `host1`) in sync with the currently active database (`host2` in the DR Region). In that case, restore the DB backup from the database in the `host2` DR Region to the database in the `host1` production Region. | SAP Basis administrator |
| Fail back the database to the production Region. | In a normal business-as-usual scenario, this step is performed in a scheduled downtime. Applications running on the DR system are stopped, and the database is failed back to the production Region (Region 1) to resume operations from the production Region.1. Log in to the SAP application server in the DR Region, and stop the SAP application.
2. Unmount `/sapmnt/` from the DR system, making sure that the changes are reverse-replicated to `/sapmnt/` of the production system.
3. Log in to the database server (`host1`) in the production Region, and perform the takeover.db2 takeover hadr on database
4. Check the HADR status: `HADR_ROLE` should be `PRIMARY` on `host1` and `StandBy` on `host2`.db2pd -d -hadr
| SAP Basis administrator |
| Perform validation before starting the SAP application. | 1. Validate the `/etc/hosts` and `/etc/fstab` entries.
2. Mount `/sapmnt//` on the production system.
3. Make sure it is in sync with the DR system `/sapmnt//`.
4. Log in to `adm` user, run `R3trans -d`, and verify the output in the `trans.log` file. The `trans.log` file is generated in the same location where you ran the `R3trans -d` command. | AWS administrator, SAP Basis administrator |
| Start the SAP application. | 1. Start the SAP application on the production system using `adm` user. Use the following code, in which `XX` represents the instance number of your SAP ASCS server, and `YY` represents the instance number of your SAP application server.sapconrol -nr XX -function StartService
sapconrol -nr XX -function StartSystem
sapconrol -nr YY -function StartService
sapconrol -nr YY -function StartSystem
2. To confirm that application servers are available, log in to SAP and perform checks by using the SICK and SM51 transactions. | SAP Basis administrator |
## Troubleshooting
| Issue | Solution |
| --- | --- |
| Key log files and commands to troubleshoot HADR-related issues | + `db2 get db cfg \| grep -i hadr`
+ `db2pd -d sid -hadr`
+ `Db2diag.log` (This file is generally located inside the `db2dump` directory, and the `db2dump` path is defined by the parameter `DIAGPATH`.) |
| SAP note for troubleshooting HADR issues on Db2 UDB | Refer to SAP [Note 1154013 - DB6: DB problems in HADR environment](https://service.sap.com/sap/support/notes/1154013). (You need SAP portal credentials to access this note.) |
## Related resources
+ [Disaster recovery approaches for Db2 databases on AWS](https://aws.amazon.com/blogs/architecture/disaster-recovery-approaches-for-db2-databases-on-aws/) (blog post)
+ [SAP on AWS – IBM Db2 HADR with Pacemaker](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)
+ [Step by Step Procedure to set up HADR replication between DB2 databases](https://www.ibm.com/support/pages/step-step-procedure-set-hadr-replication-between-db2-databases)
+ [Db2 HADR Wiki](https://ibm.github.io/db2-hadr-wiki/index.html)
## Additional information
Using this pattern, you can set up a disaster recovery system for an SAP system running on the Db2 database. In a disaster situation, business should be able to continue within your defined recovery time objective (RTO) and recovery point objective (RPO) requirements:
+ **RTO** is the maximum acceptable delay between the interruption of service and restoration of service. This determines what is considered an acceptable time window when service is unavailable.
+ **RPO** is the maximum acceptable amount of time since the last data recovery point. This determines what is considered an acceptable loss of data between the last recovery point and the interruption of service.
For FAQs related to HADR, see [SAP note \#1612105 - DB6: FAQ on Db2 High Availability Disaster Recovery (HADR)](https://launchpad.support.sap.com/#/notes/1612105). (You need SAP portal credentials to access this note.)