Migrating SAP ERP 6 on IBM Db2 to IBM Power Virtual Server

Preparing for migration

Use the following steps to prepare for the migration.

You need all the defined environment variables on both the source and target server. Save the commands to a temporary text file while you run them on the source SAP server. The exact same commands are required on the target server as shown in chapter Restoring the database on the target system.

Set the following environment variables according to your needs.

1. Start a C shell session as root user on the source system:

   csh
   

   The command syntax for defining environment variables depends on the shell type. Default shell type for Db2 and SAP administrator users db2<sid> and <sid>adm is the C shell. When using the same shell, you can copy the command examples and paste them into your session environment.

2. Define the hostname of the target migration system (example:cdb6ecc1) and replace it with your target hostname:

   set TARGETSERVER=cdb6ecc1
   

   Make sure that the same versions of SAP ERP Software and IBM Db2 database are running on the source and target SAP systems.

3. Define the SAP instance administrator (this example is for the SAP instance th1) and change it to match your system.

   set SIDADM=th1adm
   

4. Define the IBM Db2 database name - again th1 is the example, and change it to match your system:

   set DBNAME=th1
   

5. Define the IBM Db2 database administrator:

   set DB2ADM=db2th1
   

6. Define a directory to store the backup files:

   set BACKUPDIR=/db2/backup
   

7. Create the following directory if it does not exist:

   mkdir -p $BACKUPDIR
   

   and transfer the ownership of the backup directory to the Db2 administrator:

   chown $DB2ADM $BACKUPDIR
   

   This backup directory needs enough space to store the compressed backup files. Determine the current IBM Db2 database size by calling the GET_DBSIZE_INFO procedure. For more information, see the GET_DBSIZE_INFO procedure.

Shutting down the SAP application and deactivating the database on the source server

Use the following steps to shut down the SAP application and deactivate the database on the source server.

1. To start or stop the SAP system, use the SAP instance administrator account $SIDADM:

   su - $SIDADM
   

2. To stop the SAP system and keep the database running, use the following command:

   stopsap r3
   

   Optionally, you can check whether the SAP is in the required state by running the following command:

   stopsap check
   

   The expected output looks like the following example:

   Checking db6 Database
   Database is running
   -------------------------------------------
   Checking SAP TH1 Instance ASCS01
   -------------------------------------------
   Instance ASCS01 is not running
   Checking SAP TH1 Instance D00
   -------------------------------------------
   Instance D00 is not running
   

3. For the Db2 commands, end the $SIDADM user session:

   exit
   

4. Switch to the $DB2ADM user:

   su - $DB2ADM
   

   Optionally, you can check whether any applications are still connected to the database before you deactivate the database by running the following command:

   db2 list applications
   

   The following example is the expected output.

   SQL1611W  No data was returned by Database System Monitor.
   

   If applications are still listed, stop the applications and check again. Only if the external applications still don't stop, try disconnecting applications from the database server with db2 force applications all.

5. Define the environment variables for the DB2ADM user again:

   set DBNAME=th1
   

   set BACKUPDIR=/db2/backup
   

6. The IBM Db2 offline backup requires that the database is deactivated. Use the following command to deactivate the database:

   db2 deactivate database $DBNAME
   

   The following output is expected.

   DB20000I  The DEACTIVATE DATABASE command completed successfully.
   

Using the IBM Db2 offline backup on the source system

Use the following steps to use the Db2 offline backup on the source system.

A backup directory to store the compressed offline backup was created in the preparation step Preparation for Migration.

1. Verify that the backup directory offers sufficient available space to store backup files:

   df -m $BACKUPDIR
   

2. Start the IBM Db2 offline backup:

   db2 backup database $DBNAME to $BACKUPDIR compress
   

   This command runs for a long time, depending on the database size.

   Backup progress can be tracked with the command db2 list utilities show detail

   You can find a timestamp at the end of the backup command output. This timestamp is required to Restoring the database on the target system.

   Example output:

   Backup successful. The timestamp for this backup image is : 20240730170709
   

   Memorize this timestamp, you need to refer to it in the next two steps.

3. Use an environment variable to store the timestamp:

   set TIMESTAMP=<your timestamp>
   

   The IBM Db2 backup timestamp has the format YYYMMDDHHMMSS (Year-Month-Day-Hour-Minute-Second) and looks like 20240730170709. This timestamp is needed on the target SAP server again. Append this TIMESTAMP definition command to the list of saved commands that are from Preparation for Migration.

4. Change to the backup folder by using the following command:

   cd $BACKUPDIR
   

5. Check for files that contain your timestamp in their name:

   ls -l *$TIMESTAMP*
   

   Example output:

   TH1.0.db2th1.DBPART000.20240730170709.001
   

Files that are listed in the output are the backup files that are transferred to the target system in the next step.

Transferring the backup files

Use the following steps to transfer the backup files.

1. Copy the backup files from the source SAP system to the target:

   scp ${BACKUPDIR}/*${TIMESTAMP}* \
       ${TARGETSERVER}:${BACKUPDIR}
   

This example uses secure copy (SCP), a slower version of data transfer. You can transfer backup files either directly to an IBM AIX LPAR in PowerVS, or to IBM Cloud Object Storage. If you use SCP or SFTP with IBM Cloud Object Storage, it assumes that you are using an IBM FileManage Gateway service or installed and configured an SFTP server within or next to the target IBM PowerVS environment to receive the transfer.

The faster option is IBM’s high-performance Aspera product for data transfer. In many situations, IBM Aspera can transfer data several times faster than traditional TCP-based protocols. For more information, see IBM Aspera Technologies.

This reference also contains the Accelerated network transfer migration guide.

Restoring the database on the target system

Use the following steps to restore a database on the target system.

1. Log in to the target server to start the restore procedure:

   ssh $DB2ADM@$TARGETSERVER
   

   The target server can't know the environment variables that are defined on the source system. But variables $DBNAME, $TIMESTAMP and $SIDADM are needed on the target system. To define these variables, run the list of commands that you saved in step Preparing for migration and Using the IBM Db2 offline backup on the source system or define the environment variables again.

2. The full restore procedure requires a deactivated IBM Db2 database. Use the same steps as before on the preinstalled target SAP system:

   db2 list applications
   

   The following output is expected:

   SQL1611W  No data was returned by Database System Monitor.
   

3. Deactivate the IBM Db2 database:

   db2 deactivate database $DBNAME
   

4. Do a full database restore:

   db2 restore database $DBNAME \
       from $BACKUPDIR          \
       taken at $TIMESTAMP
   

   Appending replace existing to the restore command avoids the overwrite prompt.

5. Db2 command asks if you want to overwrite the existing database by restoring the backup:

   SQL2523W  Warning!  Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database is overwritten by the backup version. The Roll-forward recovery logs associated with the target database is deleted.
   
   Do you want to continue ? (y/n)
   

   Enter y and press Enter.

   The following output is expected:

   DB20000I  The RESTORE DATABASE command completed successfully.
   

   If the restore did not succeed, drop the database on the target system in advance with db2 drop database $DBNAME and redo the restore command.

6. To complete the restore, use the following command:

   db2 rollforward db $DBNAME to end of backup and stop
   

The target database now contains the source system data.

Starting SAP target system

Use the following steps to start the target system,

1. Switch to the SAP instance administrator:

   login $SIDADM
   

2. Start the SAP application:

   startsap
   

   The following example is the expected output:

   Checking db6 Database
   Database is running
   -------------------------------------------
   Starting Startup Agent sapstartsrv
   OK
   Instance Service on host <TARGET> started
   -------------------------------------------
   starting SAP Instance ASCS01
   Startup-Log is written to /home/th1adm/startsap_ASCS01.log
   -------------------------------------------
   /usr/sap/TH1/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start
   Instance on host <TARGET> started
   Starting Startup Agent sapstartsrv
   OK
   Instance Service on host <TARGET> started
   -------------------------------------------
   starting SAP Instance D00
   Startup-Log is written to /home/th1adm/startsap_D00.log
   -------------------------------------------
   /usr/sap/TH1/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start
   Instance on host <TARGET> started
   

Adjust the SAP system DNS record to point to the target SAP server to make sure that client systems (the running SAP Logon GUI) are connected to the target server.

The migration is complete.

• SAP system on the source server is down
• SAP system on the target server is up and running

Special case - Migrating a source IBM Db2 cluster

If the source SAP system is an IBM Db2 HADR cluster, the HADR configuration needs to extend to include the target server. The steps are easier in this case.

Most of the configuration steps that are described are already set up. The target system needs to be added as an auxiliary node to the existing IBM Db2 HADR configuration. For more information, see the Steps for adding a new Auxiliary Standby to an existing Db2 HADR Pair IBM Db2 Support Article.

Preparing for migration

Use the following steps to prepare the SAP system for migration.

Keep the following information in mind as you prepare for the migration.

• You need to define two TCP port numbers to use in your setup.

• Synchronizing with HADR requires two open network ports:

  • A local port for outgoing traffic
  • A remote port for incoming traffic

• Both port are configured on each of the two IBM Db2 systems, but with interchanged order. This example uses port number 5920/tcp and 5921/tcp, but you can adapt these ports to your needs.

• Firewalls must allow TCP traffic between the source and target system. Make sure that the required firewall rules are configured on all involved firewalls and on the source and target system.

Set the following environment variables according to your configuration.

All environment variables that are defined are needed on both the source and target server. Save the commands while you run them on the source SAP server to a temporary text file. The same commands are required on the target server as noted in Restoring the database on the target system.

1. Define the hostname for the target migration system. cdb6ecc1 is an example and replace it with your target hostname by using the following command:

   set TARGETSERVER=cdb6ecc1
   

   Make sure that your target server is running SAP ERP Software and IBM Db2 database with the same version as the source SAP system.

2. Define the SAP instance administrator and change it to match your system by using the following command (this example is for the SAP instance th1):

   set SIDADM=th1adm
   

3. Define the IBM Db2 database name - again th1 is an example. Change it to match your system:

   set DBNAME=th1
   

4. Define the IBM Db2 database administrator:

   set DB2ADM=db2th1
   

5. Define a directory to store backup files:

   set BACKUPDIR=/db2/backup
   

6. Create the following directory if it does not exist:

   mkdir -p $BACKUPDIR
   

   and transfer the ownership of the backup directory to the Db2 administrator:

   chown $DB2ADM $BACKUPDIR
   

   This backup directory needs enough space to store the compressed backup files. Determine the current IBM Db2 database size by calling the GET_DBSIZE_INFO procedure. For more information, see GET_DBSIZE_INFO procedure.

Making sure that IBM Db2 archive logging is enabled

IBM Db2 High Availability and Disaster Recovery (HADR) requires archive logging to be enabled. circular logging is enabled by default after you install IBM Db2 HADR. Most SAP systems on IBM Db2 have archive logging enabled.

Creating an online backup from the source system database

To minimize SAP system downtime, create an online Db2 database backup.

1. Switch to the Db2 admin user:

   su - $DB2ADM
   

2. Start the online backup, including log files:

   db2 backup db $DBNAME online to $BACKUPDIR compress include logs
   

   Keep in mind that the backup takes some time to complete.

   When the backup is complete, a timestamp is printed:

   Backup successful. The time stamp for this backup image is : 20240913091058
   

   Memorize this timestamp. You need it in the next two steps.

3. Use an environment variable to store the timestamp:

   set TIMESTAMP=<your timestamp>
   

   The IBM Db2 backup timestamp uses the format YYYMMDDHHMMSS (Year-Month-Day-Hour-Minute-Second) and looks like 20240913091058. This timestamp is needed on the target SAP server again. Append this TIMESTAMP definition command to the list of saved commands from step Preparation for Migration.

Transferring backup files to the target system

Use the following steps to transfer the backup files to the target system.

1. Copy the backup files from the source SAP system to the target system:

   scp ${BACKUPDIR}/*${TIMESTAMP}* \
       ${TARGETSERVER}:${BACKUPDIR}
   

Restoring the target system

Use the following steps to restore the target system.

1. The database restore is done on the target server:

   ssh $DB2ADM@$TARGETSERVER
   

   The target server cannot know the environment variables that are defined on the source system. But the variables $DBNAME, $TIMESTAMP and $SIDADM are needed on the target system. To define these variables, run the list of commands that you saved in step Preparing for migration and Creating an online backup from the source system database or define the environment variables again.

2. Use the online backup to restore to the database.

   db2 restore database $DBNAME \
       from $BACKUPDIR          \
       taken at $TIMESTAMP
   

   Db2 command asks if you want to overwrite the existing database by restoring the backup:

   SQL2523W  Warning!  Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database will be overwritten by the backup version. The Roll-forward recovery logs associated with the target database will be deleted. Do you want to continue? (y/n)
   

3. Enter y and press Enter.

   The following example is the expected output:

   DB20000I  The RESTORE DATABASE command completed successfully.
   

   If the recovery was not successful, drop the database on the target system in advance with db2 drop database $DBNAME and redo the restore command.

   In contrast to option 1, do not roll forward archive logs. HADR takes this state to synchronize changed data that is in the next step. If the source SAP system is operational, source data changes.

   To transfer the latest changes, configure IBM Db2 HADR database synchronization.

Defining HADR local and remote service ports on the target and source system

Use the following steps to define HADR local and remote service ports on the target and source system.

HADR uses two TCP ports to synchronize data.

1. Check that /etc/services does not contain these TCP port numbers on both systems. Configure port numbers in this file on both servers.

   If local and remote HADR ports are configured in /etc/services, IBM Db2 configuration is more readable by using service names instead of numbers.

   In the example, ports 5920/tcp and 5921/tcp are used, but you can define different ports.

   Overview table of the port numbers to configure:

   TCP port assignment in /etc/services on both servers

   Services name	Value on source server	Value on target server	Comment
   db2th1ha_l	5921/tcp	5920/tcp	Local port
   db2th1ha_r	5920/tcp	5921/tcp	Remote port

2. Use your favorite editor to change /etc/services on both servers.

3. Review if the configuration files are correct, by using the following command:

   grep -e '592[01]/' /etc/services
   

   The following lines are the expected output on the source server:

   db2th1ha_l        5921/tcp        # Db2 HADR local port
   db2th1ha_r        5920/tcp        # Db2 HADR remote port
   

   Port numbers must be enabled on the target server. The following example is the expected output on the target node:

   db2th1ha_l        5920/tcp        # Db2 HADR local port
   db2th1ha_r        5921/tcp        # Db2 HADR remote port
   

Configuring HADR on the target and source system

HADR needs the following set of configurations.

Local and remote hostnames (HADR_LOCAL_HOST and HADR_REMOTE_HOST) must be turned on for both systems. HADR_LOCAL_HOST is always the hostname of the node. The configuration command is run on and the remote host is the hostname of the respective other system.

Local and remote service entries (HADR_LOCAL_SVC and HADR_REMOTE_SVC) are identical because the switch is already configured in /etc/services.

High availability disaster recovery (HADR) synchronization mode explains different IBM Db2 HADR synchronization options and their benefits.

Use the following commands to configure both systems:

1. Local host is the system that the hostname command reports to:

   db2 "update db cfg for $DBNAME using HADR_LOCAL_HOST `hostname`"
   

2. Local port is the local port definition from /etc/services:

   db2 "update db cfg for $DBNAME using HADR_LOCAL_SVC db2th1ha_l"
   

3. For the remote host, verify that $TARGETSERVER points to the other server:

   db2 "update db cfg for $DBNAME using HADR_REMOTE_HOST $TARGETSERVER"
   

4. The remote port is the remote port definition from /etc/services:

   db2 "update db cfg for $DBNAME using HADR_REMOTE_SVC db2th1ha_r"
   

5. Configure the remote IBM Db2 instance.

   As orientation, if the database name is th1, then the instance name looks like db2th1:

   db2 "update db cfg for $DBNAME using HADR_REMOTE_INST $DBINST"
   

6. Make sure that the log index build is set to ON on both systems:

   db2 "update db cfg for $DBNAME using LOGINDEXBUILD ON"
   

7. Define the HADR synchronization mode. The value async is an example, change it to match the HADR Synchronization Mode suitable for your environment:

   db2 "update db cfg for $DBNAME using HADR_SYNCMODE async"
   

Starting HADR and checking the synchronized data

Use the following steps to start HADR and to check whether the data is syncing.

1. Start HADR on the target server in standby. Switch to the target server as $DB2ADM, and run the following command:

   db2 start hadr on db $DBNAME as standby
   

   Expected output looks like the following example:

   DB20000I  The START HADR ON DATABASE command completed successfully.
   

2. Start HADR on the source server as the primary. Switch to the source server as $DB2ADM and run the following command:

   db2 start hadr on db $DBNAME as primary
   

   Expected output looks like the following example:

   DB20000I  The START HADR ON DATABASE command completed successfully.
   

3. Verify the HADR state with:

   db2pd -d $DBNAME -hadr
   

   And check for these fields:

   HADR Status Values, both servers

   Field	Source server	Target server
   HADR_ROLE	PRIMARY	STANDBY
   HADR_STATE	PEER	PEER
   HADR_CONNECT_STATUS	CONNECTED	CONNECTED

Running the core migration

Use the following steps to start migrating the SAP system from source server to the target server.

Adjust the SAP system DNS record to point to the target SAP server. This adjustment makes sure that client systems (such as the system that runs the SAP logon GUI) connect to the target server.

1. Stop the source servers SAP system that includes the Db2 database.

   On the source system login as $SIDADM and run the following command:

   stopsap
   

   Wait for the command to complete.

2. Switch to the target server as $DB2ADM and initiate a takeover by using the following command:

   db2 takeover hadr on database $DBNAME
   

   The takeover command has an option by force that can help if the source system wasn't cleanly shut down. For more information, see TAKEOVER HADR command.

3. As $DB2ADM on the target server. Verify that the IBM Db2 HADR role changed from standby to primary by using the following command:

   db2pd -d th2 -hadr | grep ROLE
   

4. If the IBM Db2 HADR role is primary on the target server, you can start the SAP system on the target server. Switch to the $SIDADM user and run the following command:

   startsap
   

   The IBM Db2 database synchronization is still configured, although not active at this stage.

   Leave HADR configuration as is if the target system is planned to migrate back (as for a disaster scenario). If the source system is removed after the migration, remove the HADR configuration as described in How to remove existing HADR configuration.

The migration is complete.

• SAP system on the source server is down
• SAP system on the target server is up and running