Hello Colleagues, Im part of HANA LAC team that help with the most complex migrations in the region, thanks for take some time in read this blog about Tenant replicacion, this method will be the most common in the next years due a some restriction we will face in on premise and RISE infrastructure.

The most particular case about migration is the downtime, estimate the windows that customers need to achieve and perform a good project, but this not always happen and with the native HANA methodology of HANA System replication (HSR) we can mitigate some risk about Downtime, but as you well know to execute HSR is necessary to have the same SID in both HANA Nodes (and others prerequisites – help.sap.com – General prerequisites for HANA System replication),  when the customer already have the same SID of HEC/RISE is good because we review the others prerequisites and we can move forward but when the it cannot be completed we will face issues and the downtime is impacted

One of this common scenarios is when a customer has already on HEC all infrastructure and wants to move on RISE Contract, if the SID of BD HANA for example is D01 On premise and RISE is D10 and 10TB of size in HANA DB and the Business windows is just 24hrs, in this scenario we cannot move with HSR and is when enter Tenant Replication (Copy / Move) , with this new feature in HANA DB we can move or copy a tenant in few hours (Depend of the bandwidth), for this case mentioned above is possible with good VPN of 100MB/s transfer the tenant to RISE in just 4 hours and later perform the finalize replica and startup the HANA DB in the new target (RISE), then we will proceed with the next steps in app server, post migration and deliver to RISE for post activities migration, we can explain in more details but first we need to fill the prerequisites:

Requirements:

• The Target System Number could be different from the Source System
• The Target System ID could be different from the Source System
• The resources available (memory, disk space, CPU) are the same of the Source System
• The SAP HANA network ports (3xx01, 3xx13, 3xx15, 3xx41 and others) must be open from both directions (source => target and Target => source)
• The hostnames from the source and target systems must be recognized between them. The
  DNS must mutually solve the servers FQDN from both networks.
• Before you configure SAP HANA Tenant Copy Replication, you must copy the system PKI SSFS .key and the .dat file from the primary system to the secondary system:

/usr/sap/<SID>/SYS/global/xsa/security/ssfs/data/SSFS_<SID>.DAT
/usr/sap/<SID>/SYS/global/xsa/security/ssfs/key/SSFS_<SID>.KEY

/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT
/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY

For more information, see SAP Note 2369981.

Validate  keys and ensure the correct permissions (owner, group):

Parameters Setup – Source System:

1.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘communication’,’listeninterface’) = ‘.global’ WITH RECONFIGURE;

2.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘system_replication_communication’,’enable_ssl’) = ‘off’;

3.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET ( ‘communication’,’ssl’) = ‘off’;

4.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘multidb’,’enforce_ssl_database_replication’) = ‘false’;

5.  Stop/Start Database (Source)

Parameters Setup – Target System (RISE):

6.   ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘communication’,’listeninterface’) = ‘.local’;

7.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘system_replication_communication’,’enable_ssl’) = ‘off’;

8.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘communication’,’ssl’) = ‘off’;

9.  ALTER SYSTEM ALTER CONFIGURATION (‘global.ini’, ‘SYSTEM’) SET (‘multidb’,’enforce_ssl_database_replication’) = ‘false’;

10.  Stop/Start Database (Target)

11.  Create Credentials from Source to Target (RISE Target system):

CREATE CREDENTIAL FOR COMPONENT ‘DATABASE_REPLICATION’ PURPOSE ‘SID-hostname.internal:31001’
TYPE ‘PASSWORD’ USING ‘user=”SYSTEM”;password=”Testenantcopy#01″‘

12. Validate credentials are ok :

select * from sys.credentials

13.  Stop Tenant in target and drop (if exist already in target)

ALTER SYSTEM STOP DATABASE SID
DROP DATABASE SID

Validate the tenant doesn’t exist:

select * from M_DATABASES

*Please ensure just systemdb is running or tenant you will create in the Tenan Copy Replication is not present (you can have others tenant with different SID)

14.  Stop/Start Database (Target)

15.  Activate Replica:

Validate replica  :

select * from SYS_DATABASES.M_DATABASE_REPLICA

**Initializing mean the replica is in process to copy the data to the target

• While the replica will be executing the status remains as: Initializing
• After the Replica from source DB finish the status will change to: Active

Replica is ACTIVE and ready.

16.  Ending Replication (Target):

ALTER DATABASE SID FINALIZE REPLICA;

Later of this step you can start DB HANA and execute the next steps of post processing (connect CI/Appserver and start SAP, etc) to deliver the system to RISE.

Special thanks to Rogeiro Perez  for your contribution!.

Jhan Chacon
HANA LAC Principal Technology Architect / Cloud Advisory & BTP