Migrating SAP S/4HANA to IBM Power Virtual Server

Checking the database trace files

The database trace is written to service specific files on operating system level. The trace directory is located here:

/usr/sap/<SID>/HDB<inst>/<host>/trace/DB_<SID>/

The following alias in the environment of the <sid>adm user helps you to quickly switch to the trace directory on the OS level:

cdtrace

The database trace files use the following naming convention:

<service>_<host>.<port>.<counter>.trc

In the context of dynamic tiering, a file with the following convention can exist (SAP Note 2871785):

esserver_console_<host>.<port>.<counter>.trc Example:

indexserver_saphana01.30003.024.trc You can access these files either directly, at the operating system level, or in one of the following ways:

• SAP HANA Studio -> Administration -> Diagnosis Files
• DBACOCKPIT -> Diagnostics -> Diagnosis Files

More checking information

• SAP HANA Administration Guide - Persistence Consistency Check

The SQL statements that are in the following SAP notes indicate whether a database reorganization is required and the amount of space that is saved after the reorg action takes place.

This check serves two purposes.

1. Highlights whether the reorg action is required on the SAP HANA database.
2. If a reorg action is required, it provides an estimated size after space saving actions are completed.

Extra sizing SAP Notes

• SAP Note 2363248 - SAP BW/4HANA Hardware Sizing
• SAP SD benchmark results
• Measuring in SAPS (SAP Application Performance Standard)

More related SAP Notes for EarlyWatch Alert reports

• SAP Note 1257308 - FAQ: Using EarlyWatch Alert
• SAP Note 1958910 - EarlyWatch Alert For HANA Database
• SAP Note 1911180 - HANA EarlyWatch Alerts (EWA) Issues
• SAP Solution Manager - Help Portal Documentation

Target server must have equal or greater storage capacity than the source system and be sized correctly

Remember to take SAP HANA database growth into consideration and the need to follow the IBM System Storage Architecture and Configuration Guidelines for SAP HANA TDI.

The following document outlines the required storage configuration for the target server in IBM Cloud:

• IBM System Storage Architecture and Configuration Guide for SAP HANA TDI

Consider the extra space that you need to create a file system mount point to store software executable files and the initial SAP HANA system backup. Depending on your planned IBM Cloud PowerVS infrastructure, you can create the file system as an NFS mount to export to other systems in the architecture.

Making sure that the target server OS and patch level match the source server

Check the operating system version and patch level on the target system. For productive systems, the same level makes sure that the installation performs similar and migrating runs with ease. For nonproductive systems, for example, a proof of concept system (POC) in IBM PowerVS, a higher operating system version is a valid option.

cat /etc/os-release

cat /etc/redhat-release

lsb_release -a

Making sure that the file system and mount points match the source system

The source and target systems must have the identical mapping for storage, LVM, and file systems. Only on target is the larger storage capacity that is needed or the Migration. File system structure requirements are also highlighted in the beginning of this section with the TDI requirements. Also, consider that the mount point and file ownership UID and GUID match the source system. Also, mount points need the same <SID> defined on both systems. When you install SAP HANA on the target system, the same <SID> and <instance number> from the source system are used.

export SID=<SID>                           # SAP HANA System ID (uppercase)
export sid=<sid>                           # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>                     # SAP HANA Instance Number

export SiteOnPrem=<PrimarySiteName>        # HANA System Replication Site Name 1 - Migration from On-Prem - Source
export SiteOnCloud=<secondarySiteName>     # HANA System Replication Site Name 2 - Migration to On-Cloud - Target

export NODE1=<Hostname 1>                  # Hostname of On-Prem Server
export NODE2=<Hostname 2>                  # Hostname of IBM Cloud PowerVS Instance

Entries in /etc/hosts for all systems involved in the migration project

The /etc/hosts file needs to contain entries for the Source System and any dependent SAP Netweaver or S/4 FES Application Server. You can use a DNS server for your network resource resolution, but it helps if you include the IP addresses, short name, FQDN, and description to help identify servers in the landscape in the /etc/hosts file, especially if issues occur with network resolution or the DNS services.

Preparing and tuning the OS for SAP HANA

Use the following SAP Notes to begin the preparation phase of the target system for the installation of SAP HANA.

• SAP Note 2777782 - SAP HANA DB: Recommended OS Settings for RHEL 8
• SAP Note 2772999 - Red Hat Enterprise Linux 8.x: Installation and Configuration
• SAP Note 3018133 - Linux: Running SAP applications compiled with GCC 10.x

Make sure that you completed the tasks that are mentioned in the Recommended OS Settings for RHEL 8 as these tasks are important tuning and performance settings that need to be applied. If ignored, it can impact the installation of SAP products and the performance thereafter.

Pre-SAP HANA checks by using the hcmt tool

The SAP HANA hardware and cloud measurement tools hcmt help measure and analyze your hardware or cloud systems before you deploy SAP HANA or apply for SAP HANA certification. The tools consist of the following components:

• SAP HANA hardware and cloud measurement tool
• SAP HANA hardware and cloud measurement analysis

Use the following SAP Note to check and verify the OS and configuration before you install SAP HANA.

• SAP Note 2493172 - SAP HANA Hardware and Cloud Measurement Tools

If you have a port issue when you run hcmt, open a second Terminal session. Navigate to the setup directory of hcmt, now start a session that keeps the required port open.

To run hcmt in server-client mode, you need to start two sessions:

1. hcmt server mode on - a jump host to collect test result from remote servers
2. hcmt client on the target systems that are intended to run SAP HANA, run hcmt performance test by using the full execution plan.

sudo ./hcmt -v -S

hcmt-2.00.062.00.1650891137 (2022-04-25 15:12:20)

Server started, listening on port 50000 ...

sudo ./hcmt -v -p /swrepo/HCMT/setup/config/full_executionplan.json

hcmt-2.00.062.00.1650891137 (2022-04-25 15:12:20)
Loading executionplan
LogVolume (/hana/log):
DataVolume (/hana/data):
Hosts: <`Leave Blank!!!!`>  Leave this field blank, otherwise it will affect the test.
Start execution of plan
Executing Test C9C9F832-854F-492D-8E7EFB4609AC435C
Note: CPU Micro Benchmark

Installing SAP HANA on the target system

Remember the following variables:

export SID=<SID>                           # SAP HANA System ID (uppercase)
export sid=<sid>                           # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>                     # SAP HANA Instance Number

For this example, the installation is up to the point where you need to enter "Y" to continue. Navigate back to the HANA_DATABASE directory.

Run the SAP HANA database lifecycle manager command.

sudo ./hdblcm

The following example is the expected output.

SAP HANA Lifecycle Management - SAP HANA Database 2.00.061.00.1644229038
************************************************************************

This will scan the directories for the required software.

Scanning software locations...
Detected components:
    SAP HANA Database (2.00.061.00.1644229038) in /swrepo/HANA/SAP_HANA_DATABASE/server
    SAP HANA Database Client (2.11.20.1644165757) in /swrepo/HANA/SAP_HANA_CLIENT/client


Do you want to specify additional components location? (y/n) [n]: `n`

Choose n for no additional components location and continue.

Choose an action

Index | Action                    | Description
-------------------------------------------------------------
1     | install                   | Install new system
2     | extract_components        | Extract components
3     | print_detected_components | Print detected components
4     | Exit (do nothing)         |

Enter selected action index [4]: `1`

Enter 1 and press <enter> key to install a new system.

Output continues with the following example.

SAP HANA Database version '2.00.061.00.1644229038' will be installed.

Select additional components for installation:

Index | Components | Description
--------------------------------------------------------------------------------
1     | all        | All components
2     | server     | No additional components
3     | client     | Install SAP HANA Database Client version 2.11.20.1644165757

Enter comma-separated list of the selected indices [3]: `1`

Enter 1 and press <enter> to install all SAP HANA components.

Output continues with the following example.

SAP HANA Database version '2.00.061.00.1644229038' will be installed.

Select additional components for installation:

Index | Components | Description
--------------------------------------------------------------------------------
1     | all        | All components
2     | server     | No additional components
3     | client     | Install SAP HANA Database Client version 2.11.20.1644165757

Enter comma-separated list of the selected indices [3]: `1`

Enter 1 and press <enter> to install all components. Accept a series of defaults on the next line in the output.

Enter Installation Path [`/hana/shared`]:
Enter Local Host Name [`Yourhostname`]:
Do you want to add hosts to the system? (y/n) [`n`]:

Enter `n' for no additional systems. Check the source SAP HANA database system parameters:

• source SAP HANA SID
• source SAP HANA Instance Number

Continue with the same values for the target system:

Enter SAP HANA System ID: `<Needs to match the source system>`
Enter Instance Number [00]: `<Needs to match the source system>`
Enter Local Host Worker Group [default]:

Index | System Usage | Description
-------------------------------------------------------------------------------
1     | production   | System is used in a production environment
2     | test         | System is used for testing, not production
3     | development  | System is used for development, not production
4     | custom       | System usage is neither production, test nor development

Select System Usage / Enter Index [4]: 2

Enter a number that represents the planned function. In the example, 2 indicates a system for testing.

Accept more default values:

Do you want to enable data and log volume encryption? [n]:
Enter Location of Data Volumes [/hana/data/<SID>]:
Enter Location of Log Volumes [/hana/log/<SID>]:
Restrict maximum memory allocation? [n]:
Apply System Size Dependent Resource Limits? (SAP Note 3014176) [y]:

Determine these passwords as set on the source system:

• sapadm password
• <sid>adm password
• System Database User SYSTEM password

Set the same passwords on the target system:

Enter SAP Host Agent User (sapadm) Password: <Use the same password used on the source system>
Confirm SAP Host Agent User (sapadm) Password: <Use the same password used on the source system>
Enter System Administrator (<sid>adm) Password:  <Use the same password used on the source system>
Confirm System Administrator (<sid>adm) Password: <Use the same password used on the source system>
Enter System Administrator Home Directory [/usr/sap/<SID>/home]:
Enter System Administrator Login Shell [/bin/sh]:
Enter System Administrator User ID [1001]: <check that the user ID number matches the source system>
Enter ID of User Group (sapsys) [79]:  <Check that the GUID number matches the source system>
Enter System Database User (SYSTEM) Password: <Use the same password used on the source system>
Confirm System Database User (SYSTEM) Password: <Use the same password used on the source system>

Restart system after machine reboot? [n]:
Summary before execution

At the summary, you can check to make sure that the selections that you made for the installation are correct. Then, select "Y" to begin. After about 20 minutes, you see the following message.

Registering SAP HANA Database Components on Local Host...
- Deploying SAP Host Agent configurations...
Creating Component List...
SAP HANA Database System installed
Log file written to xxxxxx

Checking that SAP HANA is running and determining the version

Run the following HDB proc command to verify that all services started on the primary and secondary SAP HANA system.

sudo -i -u ${sid}adm -- HDB proc

SAP HANA version needs to be equal or greater than the primary server

To verify the SAP HANA database version, use the following command on both nodes.

sudo -i -u ${sid}adm -- HDB version

Initial backup of the MDC/SYSTEMDB SAP HANA database

Optional check of the trace log files

The database trace is written to service specific files on operating system level. The trace directory is in the following location:

/usr/sap/${sid}/HDB<inst>/<host>/trace/DB_${sid}/

The following alias in the environment of the ${sid}adm user allows to you quickly switch to the trace directory on the OS level:

cdtrace

The database trace files use the following naming convention:

<service>_<host>.<port>.<counter>.trc

In the context of dynamic tiering, a file with the following convention can exist (SAP Note 2871785):

esserver_console_<host>.<port>.<counter>.trc

• Example:

indexserver_saphana01.30003.024.trc You can access these files either directly on the operating system level or in one of the following ways:

• SAP HANA Studio -> Administration -> Diagnosis Files
• DBACOCKPIT -> Diagnostics -> Diagnosis Files

Check the SAP HANA database user on the source system

Check with your SAP basis administration team or SAP HANA administrators, which SAP HANA database user is used to access the system. Typically this user the SYSTEM user, or the SAP schema owner user if your SAP basis administration team implemented the SAP security advisories.

Set the environment variables on the primary and secondary SAP HANA systems

To simplify the setup, prepare the following environment variables for ${sid}adm on both nodes. These environment variables are used in subsequent commands in the remainder of the examples.

On both nodes, run the following commands. Remember that the variables must be the same on both systems, source and target.

export SID=<SID>                                 # SAP HANA System ID (uppercase)
export sid=<sid>                                 # SAP HANA System ID (lowercase)
export INSTNO=<INSTNO>                           # SAP HANA Instance Number
export DIR_INSTANCE=/usr/sap/${SID}/HDB${INSTNO} # "${sid}adm" home directory

export SiteOnPrem=<PrimarySiteName>        # HANA System Replication Site Name 1 - Migration from On-Prem - Source
export SiteOnCloud=<secondarySiteName>     # HANA System Replication Site Name 2 - Migration to On-Cloud - Target

export NODE1=<Hostname 1>                  # Hostname of On-Prem Server
export NODE2=<Hostname 2>                  # Hostname of IBM Cloud PowerVS Instance

Make sure that SAP HANA is running on both systems

As the operating system user ${sid}adm, the command HDB proc can be used to verify that all services are started.

Run the following command on both systems, primary and secondary SAP HANA server.

sudo -i -u ${sid}adm -- HDB proc

SAP HANA version must be equal or greater than the primary server

Run the following command on each node to determine the SAP HANA server version.

sudo -i -u ${sid}adm -- HDB version

The target system version must be equal or larger compared with the source system version. The only exception for the version is for an Active/Active read enabled configuration, here the HDB version must be identical on source and target system.

• Therefore, make sure that the system configuration is identical on both the source and target servers. Then, compare the settings in the ini-files on both systems.

• For a scale-out configuration, make sure that the number of worker nodes (scale-out) and roles are identical on both the source and target servers.

• The same ${sid} and instance numbers must be used on both systems.

• Back up PKI SSFS .key and the .dat files from the primary and secondary systems.

• Copy existing PKI keys from the primary to the secondary system.

To make sure that you can recover to the original installed state, if needed, back up the existing keys on both primary and secondary systems.

sudo -i -u ${sid}adm -- cp -p /usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT /usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT_<hostname>

After the backup of the existing PKI SSFS .key and .dat files is done, you now need to copy the PKI SSFS .key and .dat files from primary system to the target system.

The SAP HANA 2.0 data and log transmission channels for the replication process require authentication by using the system PKI SSFS storage certificate files.

• SAP Note 2369981 - Required configuration steps for authentication with HANA System Replication

The system PKI SSFS storage certificate files are stored in /usr/sap/${SID}/SYS/global/security/rsecssfs/ in subdirectories data and key.

On NODE2, run the following commands to copy files SSFS_${SID}.DAT and SSFS_${SID}.KEY from NODE1.

As ${sid}adm user, run the following two commands on NODE2.

scp ${NODE1}:/usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT /usr/sap/${SID}/SYS/global/security/rsecssfs/data/SSFS_${SID}.DAT

scp ${NODE1}:/usr/sap/${SID}/SYS/global/security/rsecssfs/key/SSFS_${SID}.KEY /usr/sap/${SID}/SYS/global/security/rsecssfs/key/SSFS_${SID}.KEY

The copied PKI SSFS storage certificates on NODE2 become active during the start of the SAP HANA system.

Check that the configuration parameter log_mode is set to normal

Make sure that the configuration parameter log_mode is set to normal in the persistence section of the global.ini on both the primary and secondary SAP HANA Servers.

Run the following command on both systems to verify the log_mode setting.

sudo -i -u ${sid}adm -- grep -i 'log_mode' /usr/sap/${SID}/HDB${INSTNO}/exe/config/global.ini

The following output is expected.

log_mode=normal

Register the primary server first

On the primary SAP HANA system, run the following command to register this node as the primary for SAP HANA System Replication.

sudo -i -u ${sid}adm -- hdbnsutil -sr_enable --name=${SiteOnPrem}

The following output is expected.

nameserver is active, proceeding ...
successfully enabled system as system replication source site
done.

Check whether the primary system is registered

Verify that the primary system is successfully registered by using the following command.

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

The following output is expected.

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: primary
operation mode: primary
site id: 1
site name: SiteOnPrem

is source system: true
is secondary/consumer system: false
has secondaries/consumers attached: false
is a takeover active: false
is primary suspended: false

Host Mappings:
~~~~~~~~~~~~~~


Site Mappings:
~~~~~~~~~~~~~~
SiteCloud (primary/)

Tier of SiteCloud: 1

Replication mode of SiteCloud: primary

Operation mode of SiteOnPrem :


Hint based routing site:
done.

Make sure that SAP HANA is not active on the secondary site

The secondary site must not be an active SAP HANA server. Stop SAP HANA database services by using the following command.

sudo -i -u ${sid}adm -- HDB stop

The following output is expected.

hdbdaemon will wait maximal 300 seconds for NewDB services finishing.
Stopping instance using: /usr/sap/${SID}/SYS/exe/hdb/sapcontrol -prot NI_HTTP -nr 10 -function Stop 400

10.08.2023 10:32:07
Stop
OK
Waiting for stopped instance using: /usr/sap/${SID}/SYS/exe/hdb/sapcontrol -prot NI_HTTP -nr 10 -function WaitforStopped 600 2


10.08.2023 10:32:51
WaitforStopped
OK
hdbdaemon is stopped.

Register the secondary system

Now register the secondary system.

sudo -i -u ${sid}adm -- hdbnsutil -sr_register \
    --name=<secondarySiteName> \
    --remoteHost=<primary_host> \
    --remoteInstance=<primary_systemnr> \
    --replicationMode=[sync|syncmem|async] \
    --operationMode=[delta_datashipping|logreplay|logreplay_readaccess]

For example, if you use

• SiteOnCloud as the secondary site name
• syncmem as replication mode and
• logreplay as operation mode

The last command looks like the following example.

sudo -i -u ${sid}adm -- hdbnsutil -sr_register \
    --name=${SiteOnCloud} \
    --remoteHost=${NODE1} \
    --remoteInstance=${INSTNO} \
    --replicationMode=syncmem \
    --operationMode=logreplay

The following output is expected.

Thu 10 Aug 10:36:13 CEST 2023
adding site ...
collecting information ...
updating local ini files ...
done.

Troubleshoot hdbnsutil errors with SELinux enabled

If security-enhanced Linux (SELinux) is enabled, the output of hdbnsutil is not as expected. You can see one of the following two symptoms.

• Command is not recognized error message
• Usage information displayed

SELinux, when set to enforcing, prevents the command hdbnsutil from restarting the saphostagent in the ${sid}adm user context. You can either add proper SELinux security policies or as SAP recommends. Then, disable SELinux.

Check the current SELinux status with the following command.

sestatus

The following output is an example.

SELinux status:                 enforcing

If sestatus command returns with enforcing, then commands even when run with root privileges can be blocked, depending on security policy.

To disable SELinux temporarily, run the following command.

sudo setenforce 0

SELinux is now temporarily disabled until the next restart.

Now check with sestatus again, the status shows disabled.

Check whether the saphostagent process is running with the following command.

sudo ps -ef | grep -i host

If output is empty and no process is displayed, manually restart the saphostagent.

sudo -i -u ${sid}adm -- /usr/sap/hostctrl/exe/saphostexec -restart /usr/sap/hostctrl/exe/host_profile

Check the primary system state

Verify the system replication state on the primary node. Run the following command on the primary server:

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

The following output is expected.

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: primary
operation mode: primary
site id: 1
site name: SiteOnPrem_hostname

is source system: true
is secondary/consumer system: false
has secondaries/consumers attached: true
is a takeover active: false
is primary suspended: false

Host Mappings:
~~~~~~~~~~~~~~

<SiteOnCloud_hostname> -> [SiteOnPrem_hostname] <SiteOnPrem_hostname_hostname>
<SiteOnCloud_hostname> -> [SiteOnCloud] <SiteOnPrem_hostname_hostname>


Site Mappings:
~~~~~~~~~~~~~~
SiteOnPrem_hostname (primary/primary)
    |---SiteOnCloud (syncmem/logreplay)

Tier of SiteCloud: 1
Tier of SiteOnPrem_hostname: 2

Replication mode of SiteOnPrem_hostname: primary
Replication mode of SiteOnCloud: syncmem

Operation mode of SiteOnPrem_hostname: primary
Operation mode of SiteOnCloud logreplay

Mapping: SiteOnPrem_hostname -> SiteOnCloud

Hint based routing site:
done.

Check the secondary system state

Now check the system replication state on the second node. Run the same command on the second server.

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

The following output is expected.

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: false

mode: syncmem
operation mode: unknown
site id: 2
site name: SiteOnCloud

is source system: unknown
is secondary/consumer system: true
has secondaries/consumers attached: unknown
is a takeover active: false
is primary suspended: false
is timetravel enabled: false
replay mode: auto
active primary site: 1

primary masters: <SiteOnPrem_hostname_hostname>
done.

Restart the secondary server

So far both SAP HANA servers are configured as replication partners. Now restart the secondary SAP HANA server to complete the replication setup.

Run the following command on the secondary server.

sudo -i -u ${sid}adm -- HDB start

The following output is expected.

StartService
OK

Starting instance using: /usr/sap/${SID}/SYS/exe/hdb/sapcontrol -prot NI_HTTP -nr 10 -function StartWait 2700 2
OK


10.08.2023 10:38:47
Start
OK

10.08.2023 10:40:17
StartWait
OK

Check HDB info or HDB proc on the secondary side to confirm that SAP HANA is running again. When successful, run the sr_state command on the primary system.

sudo -i -u ${sid}adm -- hdbnsutil -sr_state

The following output is expected.

System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~

online: true

mode: primary
operation mode: primary
site id: 1
site name: SitePrem

is source system: true
is secondary/consumer system: false
has secondaries/consumers attached: true
is a takeover active: false
is primary suspended: false

Host Mappings:
~~~~~~~~~~~~~~

<SiteOnCloud_hostname> -> [SiteOnPrem] <SiteOnPrem>
<SiteOnCloud_hostname> -> [SiteOnCloud] <SiteOnPrem>


Site Mappings:
~~~~~~~~~~~~~~
SiteOnPrem (primary/primary)
    |---SiteOnCloud (syncmem/logreplay)

Tier of SiteOnprem : 1
Tier of SiteOnCloud: 2

Replication mode of SiteOnPrem: primary
Replication mode of SiteOnCloud: syncmem

Operation mode of SiteOnPrem: primary
Operation mode of SiteOnCloud: logreplay

Mapping: SiteOnprem_hostname -> SiteOnCloud

Hint based routing site:
done.

Check replication status

After the secondary system is configured and SAP HANA is started on the secondary server, the replication process automatically starts synchronizing data with a full replica. You can verify the initial replication on the primary server and watch the current completion status of the full replication action.

Run the Python script with the following command.

sudo -i -u ${sid}adm -- python ${DIR_INSTANCE}/exe/python_support/systemReplicationStatus.py

The following output is expected.

|Database |Host     |Port  |Service Name |Volume ID |Site ID |Site Name |Secondary |Secondary |Secondary |Secondary  |Secondary     |Replication |Replication |Replication    |Secondary    |
|         |         |      |             |          |        |          |Host      |Port      |Site ID   |Site Name  |Active Status |Mode        |Status      |Status Details |Fully Synced |
|-------- |-------- |----- |------------ |--------- |------- |--------- |----------|--------- |--------- |---------- |------------- |----------- |----------- |-------------- |-------------|
|SYSTEMDB |<NODE1>  |31001 |nameserver   |        1 |      1 |SiteOnPrem|  <NODE2> |    31001 |        2 |SiteOnCloud|YES           |SYNCMEM     |ACTIVE      |               |         True|
|S4H      |<NODE1>  |31007 |xsengine     |        2 |      1 |SiteOnPrem|  <NODE2> |    31007 |        2 |SiteOnCloud|YES           |SYNCMEM     |ACTIVE      |               |         True|
|S4H      |<NODE1>  |31040 |docstore     |        5 |      1 |SiteOnPrem|  <NODE2> |    31040 |        2 |SiteOnCloud|YES           |SYNCMEM     |ACTIVE      |               |         True|
|S4H      |<NODE1>  |31003 |indexserver  |        3 |      1 |SiteOnPrem|  <NODE2> |    31003 |        2 |SiteOnCloud|YES           |SYNCMEM     |ACTIVE      |               |         True|
|S4H      |<NODE1>  |31011 |dpserver     |        4 |      1 |SiteOnPrem|  <NODE2> |    31011 |        2 |SiteOnCloud|YES           |SYNCMEM     |ACTIVE      |               |         True|

status system replication site "1": ACTIVE
overall system replication status: ACTIVE

Local System Replication State
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mode: PRIMARY
site id: 1
site name: SiteOnPrem_hostname

Four methods to check the system replication status

sudo -i -u ${sid}adm -- python ${DIR_INSTANCE}/exe/python_support/landscapeHostConfiguration.py

sudo -i -u ${sid}adm -- python ${DIR_INSTANCE}/exe/python_support/systemReplicationStatus.py

overall system replication status: ACTIVE

sudo -i -u ${sid}adm -- hdbcons -e hdbindexserver "replication info"

select host, SECONDARY_HOST, PORT, SITE_NAME, SECONDARY_SITE_NAME, REPLICATION_MODE, REPLICATION_STATUS, REPLICATION_STATUS_DETAILS,SECONDARY_ACTIVE_STATUS from M_SERVICE_REPLICATION;

Post replication completion

Before you disable the replication setup, check the trace logs for any inconsistencies or anomalies after the replication action is performed. After the replication completes, the database contains all active services on the primary system only. But you can still examine the trace logs for any inconsistencies or issues.