SLD Registration for SAP HANA SR Systems

This page describes the SLD registration for SAP HANA systems installed with system replication for high-availability. This option is available for SAP HANA installations with or without multi-tenancy database containers (MDC). If your SAP HANA database is installed with MDC, please note that the changes described below apply to the SYSTEM-DB as well as to each tenant.

Register SAP HANA SR system in SLD

One of the most important changes that enable us to model SAP HANA SR systems in SLD and LMDB is the implementation of a new association that enables us to model relationships between DB replication groups. This also lead to the introduction of a new parameter in the profile on the SAP HANA system. If all works correctly in the end the associations in the SLD should look like this:

 

In the graphic above you can see that each SLD DS creates an own CIM Object of Type SAP_Database_System.

The SAP_Database_System created by the SLD DS of the Application Server (1) is named “Virtual Database”, the SAP_Database_System(s) created by the HANA SLD DS (2) are named “Physical Database”.  The relationship between the “Virtual Database” and the “Physical Database” which is the Primary DB is modeled with the Association SAP_IdenticalDatabaseSystem (3). The relationship between the Primary DB and the Secondary DB is modeled with the Associations SAP_DatabaseReplicationDependency (4).

To be able to report the system replication dependencies SAP_DatabaseReplicationDependency within SAP HANA you need at least SAP HANA 1.0 revision 102.02 or higher. To be able to report SAP_IdenticalDatabaseSystem automatically via the parameter SLDVIRTDBHOME you need at least SAP HANA 1.0 revision 110 or higher.

Maintain SLD parameters in SAP HANA and Application Server Profile

To be able to model the relationships above we had to introduce a new parameter for SAP HANA which will be handled as of revision 110. The parameter is called SLDVIRTDBHOME and contains the logical hostname under which the SAP HANA DB can always be reached. As the SAP HANA is installed as a SR system there must be one logical hostname that moves from the primary to the secondary site in case a fail-over to the replicated system happens. This is the host that has to go into the parameter SLDVIRTDBHOME.

Parameter SLDVIRTDBHOME

The profile parameter is only taken into account in SAP HANA system with rev. 110 or higher. You could still already maintain this parameter in the profile but for now it will be ignored. This parameter is needed to create the SLD association SAP_IdenticalDatabaseSystem between the current primary system and the virtual database system that is reported by the SAP application server. For SAP HANA systems with lower releases you have to create this relation in LMDB manually after the SLD registration. This is described later in this wiki post.

SLDSYSTEMHOME ≠ SLDVIRTDBHOME in HANA

Now even in a SR scenario you can still run your partaking SAP HANA systems as Scale-out installations. In a scale-out the SAP HANA system is installed with multiple hosts (multiple nodes). This has nothing to do with system replication, but still I have to mention it here, as this setup requires the already known parameter SLDSYSTEMHOME to be set up additionally to SLDVIRTDBHOME.

Please note the SLDSYSTEMHOME on HANA should not be the same as SLDVIRTDBHOME on HANA in a SR scenario. For the SLDSYSTEMHOME parameter you choose one of the hosts that can run the indexserver in MASTER role for one database (which one is pretty much up to you, see the other wiki page above for details). However this hostname belongs to one specific SAP HANA database in your SR scenario. It cannot belong to both HANA databases in the SR scenario. And it would never move to another physical host! SLDVIRTDBHOME belongs to all HANA databases in your SR scenario and it moves to whichever the main host of the Primary is. Please refer to the example below for better understanding.

Also in the profile of the SAP ABAP Application server you might have to make a slight adjustment. The SAP ABAP system reports the database with the value SAPDBHOST. If SAPDBHOST and SLDVIRTDBHOME are the same, then there is no problem. During the SLD registration the following would happen:

  1. SAP ABAP reports a DB system with the parameter SAPDBHOST
  2. HANA reports that it is an SR scenario with a virtual DB host on SLDVIRTDBHOME
  3. In SLD the database formerly reported by HANA is changed to type "Virtual Database" and the relation SAP_IdenticalDatabaseSystem is created to the reporting HANA system

This naturally only works if SAPDBHOST on ABAP matches SLDVIRTDBHOME in HANA. If this is not the case, the mechanism would fail, and no virtual DB or relation SAP_IdenticalDatabaseSystem is created.

To address differences between SAPDBHOST and SLDVIRTDBHOME you can use the parameter SLDSYSTEMHOME on ABAP. So if SAPDBHOST on ABAP is not the same as SLDVIRTDBHOME on HANA, you can set the parameter SLDSYSTEMHOME on ABAP to the same value as SLDVIRTDBHOME on HANA.

The recommended approach to maintain the parameter sldvirtdbhome under the section "[system_landscape_hostname_virtualization]" if the SAP HANA revision is at least at:

HANA 2.0 SPS02 Rev00  2.00.020

HANA 2.0 SPS01 Rev02  2.00.012.02

HANA 1.0 SPS12 Rev13  1.00.112.13

Our HANA DB which used as example below, is configured as a two tier System Replication running on two hosts with a MASTER and a SLAVE indexserver. These two hosts (site a) are replicated to two other hosts (site b) with exactly the same setup.

 

 

The SAP HANA H40 is used by the SAP ABAP system HHA.

So to address this setup the following parameters were added to the global.ini of both SAP HANA sites.

The profile of the (current) primary system running on lddh1hha and lddb2hha:

system_landscape_hostname_virtualization

  • sldsystemhome = lddb1hha
  • sldvirtdbhome = lddbhha

The profile of the (current) secondary system running on lddb3hha and lddb4hha:

 system_landscape_hostname_virtualization

  • sldsystemhome = lddb3hha
  • sldvirtdbhome = lddbhha
 

Hostname Resolution

To ensure that in case of replication scenario in combination with scale-out/standby each site can resolve the host names of other sites, the section [system_landscape_hostname_resolution] has to be maintained in addition to the sldsystemhome parameter. In our example we have each site running on two hosts.

Remark: Please note, that it is sufficient to maintain the system_landscape_hostname_resolution and sldvirtdbhome only once (on the primary) as they will be automatically replicated to the secondary sites.

 

 

system_landscape_hostname_resolution

  • lddb1hha = lddb1hha
  • lddb2hha = lddb1hha
  • lddb3hha = lddb3hha
  • lddb4hha = lddb3hha

In the SAP ABAP system the parameter SLDSYSTEMHOME has been added to the DEFAULT.PFL:

  • SLDSYSTEMHOME = lddbhha

There is one more parameter which is called enable_virtdbhome. This parameter is responsible for the association between the virtual and physical databases. Once the sr_register command is executed, a secondary system will be registered with a primary system. This results in a parameter change enable_virtdbhome = yes for the primary and = no for the secondary system. Such a parameter change is done automatically (e.g. every time when a take over is executed) and in most of the cases does not require a manual adjustment.

 

Parameter enable_virtdbhome

This parameter has been introduced with the following HANA revisions:

  • HANA 2.0 SPS02 Rev00  2.00.020
  • HANA 2.0 SPS01 Rev02  2.00.012.02
  • HANA 1.0 SPS12 Rev13  1.00.122.13 

 Therefore, if the minimum required revision is installed, please check if the parameter really exists in nameserver.ini (section 'sld') and has the correct value as mentioned above.

 

 

After all required parameters are maintained, we can perform the SLD registration.

Please read the following SAP note in case you plan to use FQDM or upper case characters in the above parameters for SLD registration.

SAP Note 2607076 - Support of SLD Registration of an SAP HANA System Using Fully Qualified Domain Names (FQDN) in SLDSYSTEMHOME and SLDVIRTDBHOME

SLD Registration

You must perform the configuration of the SLD data supplier on all SAP HANA systems partaking in the SR scenario using, e.g. HDBLCM. Also on the secondary system you can configure the SLD DS using HDBLCM on OS level, even if the system is in standby-mode. However please see the note below for current restrictions as to when the secondary system is actually registered in SLD.

SLD Registration of the Secondary System

Once the SLD registration is done and the payload is initially sent, you should find all relevant associations in the SLD. However, there is one catch. As the secondary system is in stand-by mode and SAP HANA is a database system that runs on the "no read in standby" principle, it doesn't accept any SQL statements and certain processes are not started automatically. In the affected HANA revisions mentioned in the SAP note 2577511, one of these processes is the process starting the SLD DS. This means, to get the complete SAP HANA SR landscape in the SLD, is indeed necessary to perform a take-over forth and back to get the secondary site registered in SLD/LMDB, otherwise the SLD DS on the stand-by system (the secondary site) will not run until the first switch happens. This activity is no longer required for HANA revisions:

  • >= 122.13 (SPS12)
  • >= 012.02 (SPS01)
  • >= 020.00 (SPS02)

If a secondary site of SAP HANA SR already exists in SLD (e.g. from the previous stand-alone registration), you can skip this step.

 

SAP HANA database Revision 110 - 122.04

With SAP HANA database Revision 110 - 122.01 there is a bug in the SLD data supplier that leads to an incorrect entry in the sldreg.xml. As an result the association SAP_IdenticalDatabaseSystem is not created. Please refer to SAP note 2303938 for a currently manual workaround.

Result

In summary you should see three HANA databases in the end. As before you have to go to the CIM Instances to see your HANA systems. In older SLD releases you have to use the path Administration => Content Maintenance to access the CIM Instances.

Filter for SAP_HDBSystem and the SID of your database. The three systems you see are:

  • The HANA DB reported by the SAP ABAP system
  • The HANA DB which is the current Primary System
  • The HANA DB which is the current Secondary System

SAP HANA DB reported by the SAP ABAP system

In the system reported by ABAP, is not much to see, as it is mainly an empty shell that serves a link between the ABAP system and the SR cluster. This can be identified by the hostname, which is usually the logical hostname that is maintained in the parameter DBSYSTEM of the ABAP stack. Important is the association SAP_IdenticalDatabaseSystem that should point to the current primary HANA system. Ensure that SAP_IdenticalDatabaseSystem is available under the tab "Associations" in SLD, otherwise there will be no link between the SAP ABAP system and the SR cluster.

SAP_IdenticalDatabaseSystem in SAP HANA < Rev. 110

As mentioned above this association is created by the parameter SLDVIRTDBHOME in SAP HANA rev. 110 or higher. Until then you should not see an association here. Please refer to the section of the LMDB maintenance to learn how to create this relation manually.

If you run SAP HANA between rev. 100 and rev. 110 and you do see this association please check the parameter sql_connect_hosts in the global.ini file. In this older revisions of SAP HANA the SLD DS wrongly used this parameter to create and adjust this association on a switch. If the parameter is set and it is not by chance the same hostname that you would maintain in SLDVIRTDBHOME then you will have to adjust the relation in LMDB manually.

SAP HANA DB which is the current Primary System

In the current primary SAP HANA system you want to see two associations that are related to system replication:

  • SAP_IdenticalDatabaseSystem: Which points to the SAP HANA system reported by the ABAP system, you should only see this for SAP HANA rev. 110 and higher
  • SAP_DatabaseReplicationDependency: in the Role Antecedent, which points to the current secondary system 

Expert Step: Remove superfluous Association from SLD

If you made a full take-over and failback to create your secondary system in SLD, you will notice that there are two entries for SAP_DatabaseReplicationDependency. Please manually delete the one with the Role Dependent by selecting it and clicking on the "Remove" button on the current primary database system. This one is supposed to be removed automatically in future.

This will also automatically delete the corresponding faulty association in the SLD entry for the current secondary database system.

Manual Maintenance for SAP HANA < Rev. 102.02

If you have a SAP HANA system older than revision 102.02 the association SAP_DatabaseReplicationDependency is not reported to SLD. Please follow the manual workaround to model the relations in LMDB described below.

SAP HANA DB which is the current Secondary System

On your current secondary system you want to see the association SAP_DatabaseReplicationDependency in the Role Dependent.

Once you have these connections straight you can check the result in the LMDB of SAP Solution Manager.