Request product support from SAP
Request non-product support or provide feedback on SAP Support Portal site
Request product support from SAP
Request non-product support or provide feedback on SAP Support Portal site
Managed System Setup for SAP HANA installations: If your SAP HANA database is installed with one or more nodes but without system replication or multi-tenancy. This guide will also apply to MCOD (Multiple Components One Database) databases which use different schemas for each SAP system.
Managed System Setup for SAP HANA with Multi-Tenant Database Container (MDC): If your SAP HANA system is installed as multi-tenant database container system some setup steps slightly differ from the standard SAP HANA installation. In an MDC system you have one system database and within this database you have several database containers which serve as isolated database for an SAP system.
Managed System Setup for SAP HANA with System Replication (SR): To support high-availability and disaster recovery you can install you SAP HANA system in a system replication scenario. In this case you continuously synchronize you SAP HANA system to a secondary location. This option is available for standard SAP HANA installations as well as for SAP HANA with MDC. If you SAP HANA system is using system replication for high-availability then some steps differ from the standard SAP HANA managed systems setup.
The picture below shows the different SAP HANA deployment options.
Before running the managed system setup, you should check if the SAP HANA system was successfully reported from the SLD into LMDB of SAP Solution Manager. If you changed the SLDSYSTEMHOME for HANA to the SAPDBHOST in ABAP, the assignment between HANA and the ABAP system should happen automatically.
Even if the ABAP system already registered a HANA earlier via the RZ70 SLD data supplier, as long as HANA and the ABAP system register with the same SystemHome value, the assignment between HANA and ABAP system happen automatically. The formerly registered RZ70 HANA system will be enriched with the additional information from the HANA SLD data supplier.
Note: SAP HANA systems with MDC and/or System Replication will have to look differently in LMDB than a simple SAP HANA installation. Please refer to the respective wiki pages for more information.
On the "Software" page, check the SAP HANA DATABASE software is marked as "Installed on Instance". This should at least be the case for the HANA master node.
The next step is to run the managed system configuration for SAP HANA. Unlike other database systems, SAP HANA has its own Technical System Type. Here we have to distinguish between a setup for a standalone HANA and an ABAP system having a HANA as a DB. For ABAP on HANA it is enough to execute the guided procedure for ABAP, which will include the HANA relevant steps as well.
Before you can run the managed system setup, make sure that the Diagnostics Agents for all HANA nodes are available. HANA nodes always register with their internal HANA hostname. So if you installed the agents manually without HLM but with the external HANA hostname you might have to create agents on-the-fly for the internal HANA hostnames. Or you just install the agents with the internal HANA hostname to begin with.
More information on agents on the fly can be found here.
To start the managed system setup for HANA, call transaction SOLMAN_SETUP → Managed System Configuration. Search for your HANA System. You'll find it on the tab “Technical Systems”.
In the first step Assign Product you have to assign product information to a technical system. To do so, click on Edit button at the top screen and click on Set Automatically to set a diagnostics-relevance flag.
In the second step Check Prerequisites you perform an automatic activity to verify if the prerequisites are met.
In the step Assign Diagnostics Agent an agent should be assigned to each server where a HANA node is installed. Furthermore, you can check the status of the corresponding SAP Host Agent.
In the next step you have to maintain the system parameters. To set up the DB Connection in this step you can use the same MONITOR user, created during HANA preparation steps for monitoring earlier.
If you have any problems creating the DB connection, check if there is a DB connection in table DBCON (transaction DBCO). If yes, test the connection using the report ADBC_TEST_CONNECTION. The output of this report will tell you what is wrong and also lead you to the trace file of the workprocess in which the error occurred. If the DB connection doesn't exist yet, please try to create it in DBCO and test it.
The most common reasons for failures here is a not correctly installed HANA client or missing HANA DB libraries. Please refer to the section about the HANA client installation from SAP HANA Managed System Setup section below.
In the Enter Landscape Parameters verify and add/change landscape parameters, if required.
The step Finalize Configuration consists mostly of automatic activities, which are relevant for data collection for scenarios like System Monitoring or Root Cause Analysis. Especially, ensure that the extractor relevant steps (Database Extractor and Extractor Setup) are finished successfully. The manual steps are relevant for a remote SAP support.
Check Configuration step performs a configuration check and updates a system status in the overview of the Managed System Configuration.
If you run a multi-node HANA DB, a manual step is required to make sure, that the HANA is still reachable, if the master node moves to another host.
To ensure that the HANA DB can be monitored and reached by DBACOCKPIT no matter who the master node is, you have to adjust the DB connection used by DBACOCKPIT. You have to add all possible HANA master node servers to the DB connection string.
Call transaction DBCO and open the DB connection for the HANA DB in change mode. Add the server names for all possible master nodes and ports separated by semicolon in the form:
Run the managed system setup for the ABAP on HANA system as usual. There will be some additional, ABAP relevant steps, like Maintain RFC's or Maintain Users, but in general the step sequence of the guided procedure is very similar to the one for HANA.
Note: that expert knowledge in SAP Solution Manager and SLD is required to successfully perform this setup.
To be able to set up your SAP HANA with System Replication (SR) in the way described below please note that your SAP Solution Manager system needs to run on SAP Solution Manager 7.2 SP3 or higher. Please note, that currently only a 2-tier replication scenario is supported.
Apart from the SAP Solution Manager support package you have to make sure the necessary notes are implemented in SAP Solution Manager and the managed systems (ABAP and SAP HANA). You find all required notes here.
Your SAP HANA SR system must be set up following the recommendations in the SAP HANA installation guide and the primary system and the secondary system must be on two different hosts. Check in HANA Studio to see if the SAP HANA system is set up with SR and how this setup looks. The System Replication Status can be found on the "Overview" tab. The exact setup of the system replication can be found under the "Landscape" tab.
Make sure you have performed the OS and DB level preparations for the Managed System Configuration as described in the SAP HANA Managed System Setup section below.
Before running the managed system setup make sure the SAP HANA SR database is replicated correctly from the SLD into LMDB. As in SLD you will see three SAP HANA system with the same SID. The extended SID for the systems will differ as the LMDB attached 0000N to the SID if two systems have the same one.
Note: The extended SID are assigned depending on the order the systems are reported to LMDB for the first time. You could change them to something more meaningful, like <SID>SITEA, <SID>SITEB and <SID>VIRDB. SITEA and SITEB are representing the corresponding sites of the replication scenario. VIRDB is representing a virtual database, which knows both sites (primary and secondary DB) and their replication relations.
Please be careful when changing extended SIDs. You should only do this if the system is not used in any logical components or monitoring yet.
In general the relationships in the LMDB mirror the ones in the SLD. This is why it is important that we delete the superfluous association SAP_DatabaseReplicationDependency after a take-over. Otherwise LMDB would get confused. The relations are modelled like this:
SAP HANA Database reported by the SAP ABAP System
In a HANA Replication scenario the SAP HANA DB reported by SAP ABAP System is maintained in the LMDB as a Virtual Database. By clicking in the navigation tree on the "Related Databases" in the LMDB for selected Virtual HANA DB, you can get a virtualization and replication relation view of selected database. For a virtual DB you will find a relation to the primary database in the SR cluster, which having a role "Physical Database". This relation is created by the SLD association SAP_IdenticalDatabaseSystem.
From here, you can navigate further to the next level by expanding the "Related Databases" and for example display a replication relation of a primary DB to the secondary DB.
SAP HANA DB which is the current Primary System
For each database in LMDB we also maintain the role it has in an SR scenario. For the primary database you will see the role Primary Database. Also because it is an actual database it is maintained as Physical Database. On the view Related Databases (screenshot above) you can see that the Virtual Database it is related to via SAP_IdenticalDatabaseSystem and also the Secondary Database under "Replication Relations".
SAP HANA DB which is the current Secondary System
For the secondary database system you see the role Secondary Database in LMDB. On the view "Related Databases" the Primary Database is displayed under "Replication Relations".
The managed system setup can be either launched from the ABAP system or the SAP HANA database reported by the SAP ABAP system (the virtual database) point of view. SOLMAN_SETUP will automatically recognize which databases belong to the scenario and select them accordingly. Most of the steps are performed exactly as for a standard SAP HANA database managed system setup, you just do it for two databases at once instead of one.
The last step is the activation of the System Monitoring. In SAP Solution Manager 7.2 the monitoring of metrics on HANA instance-level and SAP HANA replication groups is supported by the corresponding templates.
Instance-specific metrics are basically metrics that can be specified "by host". These metrics were moved in a template "SAP HANA DB Instance (instance level separated)" on instance-level. If you want to use this template please make sure that you use the template "SAP HANA DB (instance level separated)" on database system level. The template "SAP HANA DB (NEW)" contains all metrics, also the "instance-level" metrics, but they are configured as metric group that return one variant per host. In this case, assign additionally to "SAP HANA DB (NEW)" template, a "SAP HANA DB Instance" template on an instance level.
The template "SAP HANA DB Replication Group" can only be activated in the virtual database level. It contains system replication specific metrics. The template "SAP HANA DB (NEW)" also contains these SR specific metrics but they are shipped as inactive by default. If you want to use only the database level template, you can do this by activating the SR specific metrics. They are easily identified by the prefix 'SR:'.
In the step "Define Scope" select the virtual database (the one for which you also ran the managed system configuration). The two physical databases will be recognized automatically.
After the activation the metrics will be collected and the DB replication group will be visible in System Monitoring. It is marked which site it the primary site and which one is the secondary site.
Note: As a SAP HANA database cannot be reached if it is in stand-by mode, there are no metrics collected on the secondary site, except those which are delivered by the SAP Hostagent (the metrics on host level and some Availability metrics).
Note: This section is mainly then relevant for you if you don't plan to fail back immediately but have to run the database on SITEB (the new primary site) for some time. If it makes sense to run this reconfiguration or not always depends on how long SITEA will be out. During this time you cannot monitor any system though or will get false alerts.
Please note that you only will be able to continue monitoring the database SR group if system replication is re-established after the take-over. If you never re-establish system replication the new relationships will not be reported into SLD/LMDB and you will not be able to activate the monitoring for the secondary database. This doesn't mean your SITEA system must be running. You just need to register SITEA for system replication with SITEB. Then you should retrigger the SLD DS on SITEB (by toggling the parameter [ ] sld => enable). Now the new relationships are reported to SLD and you can begin the reconfiguration.
After a take-over SITEB will be reporting as the new primary site to SLD. To make sure LMDB, DBACockpit and System Monitoring are aware of this, it's recommended to perform some checks and manual steps if applicable.
Delete superfluous SAP_DatabaseReplicationDependency in SLD
Note: In case of HANA 1.0 revision 110 and higher, this step is not relevant anymore, but always advisable as a double check.
Since the secondary database (new SITEA) doesn't report to SLD currently the SAP_DatabaseReplicationDependency created by it initially is never deleted. This leads to an additional superfluous SAP_DatabaseReplicationDependency association in SLD and hence in LMDB.
The easiest way to get rid of this, is to delete it directly in SLD.
Go to the new primary SAP HANA database in SLD and look for the relation SAP_DatabaseReplicationDependency with the role Dependent. Delete this association. It will be deleted automatically in the secondary database as well.
The LMDB will be updated automatically within 10-15 minutes after deleting the relationship in SLD.
Correct SAP_IdenticalDatabaseSystem in LMDB
Before the take-over the virtual database points to SITEA as identical database. You will have to correct this relationship after the take over.
Note: If you have coincidentally set the parameter sql_connect_hosts to the correct logical host in SITEA and SITEB as described earlier, in SAP HANA rev. 100 to 110 this association will be corrected automatically. As of SAP HANA rev. 110 the parameter SLDVIRTDBHOME will be considered.
Open the virtual database in LMDB and switch to the Related Databases view.
Delete the old relation first.
Save your changes.
Adjust DBACockpit DB Connection
Per default in SAP Solution Manager 7.2 the so called DB-Connect String is used as a parameter for DBACOCKPIT connection. This value is taken from LMDB in form of IP. After a take-over this value is not automatically adjusted in the step "Enter System Parameters" of Managed System Configuration for HANA. As a result the DBA Cockpit Connection status will turn red due to the fact, that the string is still pointing to the IP of the former primary host.
To overcome this situation, you have either to adjust this parameter manually (every time a take-over is performed) or follow a recommended approach by using a virtual hostname instead of dedicated IP in field "Used DB-Connect String", which is then valid for both sites. In this case a manual adjustment will be obsolete, but it needs to be ensured that host name (e.g. the one which is used for a virtual DB) can be reached from SAP Solution Manager point of view.
Adjust the DB-Connect String with the correct host name from the Managed System Configuration / DB Parameters and save. Perform a connection test.
You can check the DB connection in DBACOCKPIT or you can also use report ADBC_TEST_CONNECTION.
Note: during DB Connection Setup: If you get the warning "DBA cockpit connection <DBCNAME> cannot be established" please check the details in the log. If the error message is "Connection failed (RTE: System call 'send' failed, rc=32:Broken pipe)" check that the HDBUSERSTORE is maintained for the HANA system. I
f this is the case, check if the DB connection is working directly in DBACOCKPIT.
If yes, close and reopen the managed system setup. The DB Connection should show green now.
Re-run Monitoring Activation
Now you can rerun the System Monitoring activation. Go to the System Monitoring setup step "Define Scope" and select again the virtual database. Go to the next step. You don't have to change any template assignments here. All you have to do is click "Apply and Activate => All managed objects"
Make sure you have performed the OS and DB level preparations for the Managed System Configuration as described in the SAP HANA Managed System Setup below.
In LMDB the system DB will register with the system SID and the tenants will register with their given SIDs.
To find out, which tenant belongs to which SYSTEM DB, you can do the following:
In this view, in the column "Associated Role", you can see which one (groupcomponent) is the System DB and which one (partcomponent) is a tenant.
If the information supplied from SLD, correctly displayed in the LMDB, you can perform the Managed System Configuration.
Please note, the Managed System Configuration has to be performed for the SYSTEMDB as well as for each tenant.
From the configuration point of view, the setup steps are pretty much the same as for a single HANA DB, but you should pay attention to the steps below.
In the step "Enter System Parameters" where the DB connection is set up, please make sure that the correct database name is pulled in the field "Instance Name". For the SYSTEMDB it will first show the global SID and then after the connection is made it will change to SYSTEMDB.
In the next step "Enter Landscape Parameters" you have to make sure you put in the correct path for installation path and log path for SYSTEMDB and each tenant.
The default installation path is /hana/shared/<SYSTEMDB-SID>. If the path has been changed during the installation, adjust it accordingly. However it should be the same for the SYSTEMDB as well as for all tenants. Please note that the auto-filled default value will be /hana/shared/<Tenant-SID>/. This path doesn't exist and you need to adjust this value.
The instance installation path is under /usr/sap/<SYSTEMDB-SID>/HDB<Inst. No.>. Also here you have to adjust the paths during the setup of the tenant DBs, as again the default auto-filled value will contain the
The instance log path differs between the SYSTEMDB and each tenant.
Note: Setup for SAP HANA with multiple hosts
If your MDC system runs on several hosts it is possible to set up tenants so that they only run on specific hosts. This tenants will not have a DB_<Tenant-SID> sub-directory in the trace folder for hosts it is not running on.
However, even if not actively used by the indexserver the second instance will show up in the step "Enter Landscape Parameters" because shared services from this tenants run on it. You cannot just leave the default value here (which would be the trace directory of the SYSTEMDB), because if you do, this will lead to double monitoring. The trace files will be monitored by the SYSTEMDB as well as by the tenants. This would lead to problems in the monitoring and also the reporting.
The best way to avoid this, is to enter the DB_<Tenant-SID> extension to the path even if this path doesn't exist. This will lead to grey metrics, but at least not to double monitoring and wrong reporting. To avoid a warning when saving the parameter you should uncheck the "Check existence of paths when saving" checkbox when you save this parameter.
As of SAP Solution Manager 7.2 SP05 new templates 'Tenant Database Instance' and 'Tenant Database Instance (instance level separated)' were introduced to support the System Monitoring of MDC.