12/1/2023

SAP HANA Tenant Databases

Generated on: 2023-12-01 07:12:06 GMT+0000

SAP HANA Platform | 2.0 SPS 07

PUBLIC

Original content: https://help.sap.com/docs/SAP_HANA_PLATFORM/78209c1d3a9b41cd8624338e42a12bf6?locale=en-

US&state=PRODUCTION&version=2.0.07

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not re ect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/docs/disclaimer.

This is custom documentation. For more information, please visit the SAP Help Portal 1
12/1/2023

SAP HANA Tenant Databases Operations Guide

SAP HANA tenant databases represent the basis for multitenancy in SAP HANA. Being able to run and manage multiple tenant
databases in one SAP HANA system helps you to lower capital expenditure, simplify database management and build multi-
tenant cloud applications.

This guide covers con guration, administrative, monitoring, and other operating tasks typically performed by the administrator
of an SAP HANA system that supports tenant databases. For more information about how to install an SAP HANA system, see
the SAP HANA Server Installation and Update Guide .

 Note
If you have SAP HANA options installed, review the section about tenant databases in the administration guide of the
corresponding option for additional information before proceeding. Be aware that you need additional licenses for SAP
HANA options and capabilities. For more information, see Important Disclaimer for Features in SAP HANA Platform, Options
and Capabilities.

Important SAP Notes

SAP Note Number Title

2096000 SAP HANA Multitenant Database Containers – Additional

Information

2101244 FAQ: SAP HANA Multitenant Database Containers

2423367 Multitenant database containers will become the standard and only
operation mode

Related Information
Important Disclaimer for Features in SAP HANA
SAP HANA Server Installation and Update Guide

Overview of SAP HANA Tenant Databases

SAP HANA supports multiple isolated databases in a single SAP HANA system. These are referred to as tenant databases.

An SAP HANA system is capable of containing more than one tenant database.

A system always has exactly one system database, used for central system administration, and any number of tenant
databases (including zero). An SAP HANA system is identi ed by a single system ID (SID). Databases are identi ed by a SID and
a database name. From the administration perspective, there is a distinction between tasks performed at system level and
those performed at database level. Database clients, such as the SAP HANA cockpit, connect to speci c databases.

All the databases share the same installation of database system software, the same computing resources, and the same
system administration. However, each database is self-contained and fully isolated with its own:

Set of database users

Database catalog

Repository
This is custom documentation. For more information, please visit the SAP Help Portal 2
12/1/2023
Persistence

Backups

Traces and logs

Although database objects such as schemas, tables, views, procedures, and so on are local to the database, cross-database
SELECT queries are possible. This supports cross-application reporting, for example.

On-premise Deployment Using SAP HANA Tenant Databases

License Keys for SAP HANA Database

The SAP HANA database supports two kinds of license keys: temporary license keys and permanent license keys

SAP HANA licenses can be installed for the system database (global) or for a single tenant database (local). Global licenses are
for the system database and all the tenant databases, but a license installed in a tenant database governs only that tenant
database. If you remove a tenant-speci c license key, that tenant database reverts to the global license key installed in the
system database.

Temporary License Keys

A temporary license key is automatically installed with a new SAP HANA system. A temporary license key is valid for 90 days.
During this period, request and install a permanent license key.

Permanent License Keys

Permanent License Keys: Expiration

This is custom documentation. For more information, please visit the SAP Help Portal 3
12/1/2023
Before a permanent license key expires, request and apply a new permanent license key. If a permanent license key expires, a
(second) temporary license key is automatically installed. This temporary license key is valid for 28 days. During this time, you
can request and install a new permanent license key.

You can request a permanent license key on SAP Support Portal (http://support.sap.com ) under Request Keys. Permanent
license keys are valid until the prede ned expiration date. Furthermore, they specify the amount of memory licensed to an SAP
HANA installation.

Permanent License Keys: Types

There are two types of permanent license key for SAP HANA: unenforced and enforced.

If an unenforced license key is installed, the operation of SAP HANA isn’t affected if its memory consumption exceeds the
licensed amount of memory. However, if an enforced license is installed, the system is locked down when the current memory
consumption of SAP HANA exceeds the licensed amount of memory plus some tolerance. If lockdown occurs, either SAP HANA
needs to be restarted, or a new license key that covers the amount of memory in use needs to be installed.

The two types of permanent license key differ from each other in the following line in the license key le:

License Key Type License Key File Entry

Unenforced SWPRODUCTNAME=SAP-HANA

Enforced SWPRODUCTNAME=SAP-HANA-ENF

SWPRODUCTNAME=SAP-HANA-DEV

SWPRODUCTNAME=SAP-HANA-DIGITAL

 Note
It’s technically possible to install an enforced license in an SAP HANA instance with a regular, unenforced permanent license.
In this case, the unenforced license key has priority. That is, if a valid unenforced license key is found, excessive memory
consumption doesn’t result in a system lockdown. However, if one license key expires and becomes invalid, the other license,
if valid, becomes the valid license key of the instance. If the latter is an enforced license key, then the memory consumption is
checked.

License Keys for Tenant Databases

You can install permanent license keys in individual tenant databases. The license key installed in a tenant database is valid for
that database only and takes precedence over the license key installed in the system database. If a tenant-speci c license key
isn’t installed, the system database license key is effective in the tenant database.

 Tip
The system view SYS.M_LICENSE provides tenant administrators with information on the license key effective in their tenant
database, as well as where the license key is installed: in the tenant database itself or in the system database. System
administrators can use the view SYS_DATABASES.M_LICENSE to see the same information for all tenant databases.

System Lockdown
The system goes into lockdown mode in the following situations:

The permanent license key has expired and either:

You didn’t renew the temporary license key within 28 days, or

This is custom documentation. For more information, please visit the SAP Help Portal 4
12/1/2023
You did renew the temporary license key but the hardware key has changed

The installed license key is an enforced license key and the current memory consumption exceeds the licensed amount
plus the tolerance.

You deleted all license keys installed in your database.

In lockdown mode, it isn’t possible to query the database. Only a user with the system privilege LICENSE ADMIN can connect to
the database and execute license-related queries, such as, obtain previous license data, install a new license key, and delete
installed license keys.

In addition, the database can’t be backed up in lockdown mode.

Additional SAP HANA Licenses

Additional licenses are required for certain applications running on the SAP HANA database, as well as certain SAP HANA
options and capabilities. For more information, see SAP Note 1644792 (License key/installation of SAP HANA).

Related Information
SAP Support Portal
SAP Note 1644792

Server Architecture of Tenant Databases

An SAP HANA database consists of multiple servers, for example, name server, index server, preprocessor server, and so on.
The databases in an SAP HANA system run different combinations of these servers. The most important server is the index
server. It contains the actual data stores and the engines for processing the data and runs in every tenant database.

Only the system database runs the name server. The name server contains landscape information about the system as a whole,
including which tenant databases exist. It also provides index server functionality for the system database. The name server
does not own information about the location of tables and table partitions in tenant databases. Database-related information is
stored in the relevant tenant database catalog.

Tenant databases require only an own index server. Servers that do not persist data, such as the compile server and the
preprocessor server, run on the system database and serve all databases.

 Note
For a full list and description of all SAP HANA servers, see Server Components of the SAP HANA Database .

The following gure shows a sample system with three databases (system database and three tenant databases) on a single
host.

This is custom documentation. For more information, please visit the SAP Help Portal 5
12/1/2023

Single-Host SAP HANA System with Tenant Databases

 Note
If the SAP HANA XS classic server is available, it runs embedded in the (master) index server of the tenant database by
default, although it can be added as a separate service if necessary. The SAP Web Dispatcher, which runs as a separate
database service on the host of the system database, is used to route incoming HTTP requests from clients to the correct
XS classic server based on virtual host names. This is part of network con guration. In addition to the system-internal Web
Dispatcher, you can implement an external Web Dispatcher for load distribution. See the section on using the SAP Web
Dispatcher for load balancing with tenant databases.

Related Information
Server Components of the SAP HANA Database
Connections from Database Clients and Web Clients to SAP HANA
Port Assignment in Tenant Databases
Scale-Out Architecture of Tenant Databases
Using SAP Web Dispatcher for Load Balancing with Tenant Databases

Scale-Out Architecture of Tenant Databases

Tenant databases can be distributed across several hosts in a multiple-host system.

To ensure system availability, an instance of the system database runs on all hosts (worker and standby) in a single master and
multiple workers con guration. Tenant databases can be created on worker hosts and existing databases can be scaled out
through the addition of services. If a host fails, the standby instance will fail over all active databases and their services. Like in a
single-host system, the master candidate for a failing host is determined. On that host the system database is restarted, if
necessary. Up to three hosts can be con gured to act as the master host of a system. These three hosts can be set up in the

This is custom documentation. For more information, please visit the SAP Help Portal 6
12/1/2023
clients with the database name to be reconnected to a tenant database even in the case of a host auto-failover of the master
host with the system database.

The following gure shows a tenant database system with three tenant databases distributed across three hosts. Tenant
database DB1 has only one index server on host 1, while DB2 and DB3 are distributed across several hosts. Tenant database
DB2, for example, is divided into three database shards, each of them with its own index server on a different host. In this
context, a database shard is the union of all tables, partitions and replicas of one database that reside on one index server.
Tenant database DB3 consists of two shards, one on host 2 and one on host 3. System administrators can specify the host when
they create the tenant database, or they can let SAP HANA chose an appropriate host based on load-balancing algorithms.

Multiple-Host System with Tenant Databases

Scale-Out Recommendations
When planning your SAP HANA deployment with tenant databases, various options exist with regard to scale-up versus scale-
out.

In general, scaling up offers some performance advantages over scaling out, as memory access is local and minor overhead
associated with inter-node network communication is avoided.

This is custom documentation. For more information, please visit the SAP Help Portal 7
12/1/2023
Note the following with regard to scale-out:

It is possible to distribute tenant databases across several hosts in a scale-out system.

The primary reason to distribute tenant databases generally is when their size is larger than the capacity of a single
host. However, other reasons for distributing tenant database may exist, for example, a large SAP Business Warehouse
(BW) system requires a scale-out con guration in accordance with its sizing rules.

If tenant databases are distributed in a scale-out con guration due to sizing requirements, caution is advised when
deploying additional tenant databases on the same host as a distributed tenant database shard. The rationale is this:
Workload in distributed scenarios can be somewhat volatile and less predictable. Therefore in many cases, it can be
advantageous to dedicate maximum resources of the host to the distributed tenant database shard in order to maintain
expected performance.

In certain cases, more than one distributed tenant database shard may share the same host. In these cases, in order to
dedicate maximum resources for a master node (for performance reasons), it is advisable to avoid deploying other
tenant databases on the master node. For example, the following deployment should offer performance advantages:

Host 1: Master for tenant database 1

Host 2: Worker for tenant database 1 and worker for tenant database 2

Host 3: Master for tenant database 2

Host 4: Standby host for failover

Related Information
Scaling SAP HANA

The System Database

The system database is created during either installation or conversion from a single-container system to a tenant database
system. The system database contains information about the system as a whole, as well as all its tenant databases. It is used
for central system administration.

A system has exactly one system database. It contains the data and users for system administration. System administration
tools, such as the SAP HANA cockpit, can connect to this database. The system database stores overall system landscape
information, including knowledge of the tenant databases that exist in the system. However, it doesn't own database-related
topology information, that is, information about the location of tables and table partitions in databases. Database-related
topology information is stored in the relevant tenant database catalog.

Administration tasks performed in the system database apply to the system as a whole and all of its databases (for example,
system-level con guration settings), or can target speci c tenant databases (for example, backup of a tenant database). For
more information, see Administration of Tenant Databases.

Things to Remember About the System Database

The system database does not have the same functionality as a tenant database.

The system database is not a database with full SQL support.

The system database cannot be distributed across multiple hosts, in other words, scale-out is not possible.

If you need a full-featured SAP HANA database, you always have to create at least one tenant database.

The system database does not support Application Function Libraries (AFL) and SAP liveCache applications.

Cross-database access between the system database and a tenant database is not possible. The system database can
show monitoring data from tenant databases (views in the schema SYS_DATABASES) but can never show actual content
from tenant databases.

The system database cannot be copied or moved to another host.

SAP HANA options can only run in tenant databases.

This is custom documentation. For more information, please visit the SAP Help Portal 8
12/1/2023
Tenant-speci c con gurations cannot be set in the system database. Only global settings are allowed.

Features can only be restricted or disabled at high level for tenant databases.

Related Information
Administration of Tenant Databases
Memory and CPU Usage for Tenant Databases
Cross-Database Authorization in Tenant Databases
Restricted Features in Tenant Databases

Cross-Database Access
Read-only queries between tenant databases in the same SAP HANA system are possible. This supports cross-application
reporting. Cross-database access must be explicitly enabled.

Every tenant database is self-contained with its own isolated set of database users and isolated database catalog. However, to
support for example cross-application reporting, cross-database SELECT queries are possible. This means that database
objects such as tables and views can be local to one database but be read by users from other databases in the same system.

The following object types on remote databases can be accessed using cross-database access:

Schemas

Rowstore and columnstore tables (not including virtual tables)

SQL views (not including monitoring views)

Graphical calculation views

If they only use supported object types as data sources

If they don’t use procedure-based analytic privileges

Synonyms

The following object types on the local tenant database can access database objects on the remote tenant database:

SQL views

Scripted and graphical calculation views

Procedures

Synonyms

The SAP HANA modeler supports modeling of graphical calculation views using tables and other graphical calculation views as
data sources from different tenant databases. For more information, see Modeling Graphical Calculation Views With Tenant
Databases in the SAP HANA Modeling Guide (For SAP HANA Studio).

For more information about how to enable and con gure cross-database access, see Enable and Con gure Cross-Database
Access.

Related Information
Enable and Con gure Cross-Database Access
Cross-Database Authorization in Tenant Databases (SAP HANA Security Guide)
Troubleshooting Error Situations Related to Cross-Database Access
Workload Management and Cross-Database Queries
Modeling Graphical Calculation Views With Tenant Databases (SAP HANA Modeling Guide)
This is custom documentation. For more information, please visit the SAP Help Portal 9
12/1/2023
Import/Export Catalog Objects with Dependencies for Multi-TenantDB (SAP Community Blog)

Database Isolation
Every tenant database is self-contained and isolated in terms of users, database catalog, repository, logs, and so on. However,
to protect against unauthorized access at the operating system (OS) level, it's possible to increase isolation further through OS
user separation and authenticated communication within databases.

OS User Separation
By default, all database processes run under the default OS user <sid>adm. If it's important to mitigate against cross-
database attacks through OS mechanisms, you can con gure the system for high isolation. In this way, the processes of
individual tenant databases must run under dedicated OS users belonging to dedicated OS groups, instead of all database
processes running under <sid>adm. Database-speci c data on the le system is then protected using standard OS le and
directory permissions.

 Note
<sid>adm is the OS user for the system database.

Authenticated Communication
In addition, once high isolation has been con gured, internal database communication is secured using the Transport Layer
Security (TLS)/Secure Sockets Layer (SSL) protocol. Certi cate-based authentication is used to ensure that only the
processes belonging to the same database can communicate with each other. It’s also possible to con gure internal
communication so that all data communication within databases is encrypted.

 Note
If cross-database access is enabled, communication between con gured tenant databases is allowed.

This is custom documentation. For more information, please visit the SAP Help Portal 10
12/1/2023

High Database Isolation

Con guration
You can specify the isolation level of the system during installation. The default isolation level is low. It’s also possible to change
the isolation level of an existing system (from low to high or from high to low) at any time. For more information, see Increase
the System Isolation Level in the SAP HANA Administration Guide . Once high isolation has been con gured, a dedicated OS
user and group must exist for every tenant database. Otherwise, it's not possible to create or start a tenant database.

Internal database communication is secured with the same mechanism used for securing other internal SAP HANA
communication channels. Once high isolation has been con gured, authenticated communication within databases is enabled
without any change required to the default TLS/SSL con guration for internal communication. However, encryption of data
communication may need to be con gured explicitly.

Related Information
File and Directory Permissions with High Isolation
Secure Internal Communication
Increase the System Isolation Level
SAP HANA Administration Guide

Administration of Tenant Databases

In SAP HANA systems there is a distinction between administration tasks performed at system level and those performed at
database level.

This is custom documentation. For more information, please visit the SAP Help Portal 11
12/1/2023

System Versus Database Administration

Tenant database systems have two levels of administration.

Some administration tasks are performed in the system database and apply globally to the system and all its databases. They
include for example:

Starting and stopping the whole system

Monitoring the system

Con guring parameters in con guration (*ini) les at system level

Setting up and con guring tenant databases, for example:

Creating and dropping tenant databases

Disabling features on tenant databases

Con guring system- and database-speci c parameters in con guration (*ini) les

Scaling out tenant databases by adding services

Backing up tenant databases

Recovering tenant databases

Some administration tasks are performed in the tenant database and apply only to that database. They include for example:

Monitoring the database

Provisioning database users

Creating and deleting schemas, tables, and indexes in the database

Backing up the database

Con guring database-speci c parameters in con guration (*ini) les

Administration Tools
Several tools are available for the administration of SAP HANA. While all tools support database-level administration, system-
level administration of tenant databases requires the SAP HANA cockpit (for example, monitoring availability of tenant
databases, creating and deleting tenant databases).

For more information about the SAP HANA cockpit and other administration tools, see the section on administration tools in
the SAP HANA Administration Guide .

Related Information
Tenant Databases
The System Database
Creating and Con guring Tenant Databases
SAP HANA Administration Tools
Monitoring and Managing Tenant Databases

Database-Speci c Con guration Parameters

In addition to the layers "default", "system", and "host", system con guration les also have a "database" layer to facilitate the
con guration of properties for individual databases.

This is custom documentation. For more information, please visit the SAP Help Portal 12
12/1/2023
In general, you can con gure database-speci c properties both in the system database and in tenant databases themselves.
Properties con gured in the system database can be applied to all databases (if con gured in the system layer) or to speci c
databases (if con gured in database layer).

Properties con gured in a tenant database apply to that tenant database only. Only properties in the following les can be
con gured in tenant databases:

attributes.ini

docstore.ini

dpserver.ini

esserver.ini

executor.ini

extensions.ini

global.ini

indexserver.ini

scriptserver.ini

xsengine.ini

The le multidb.ini is used as a blocklist to protect critical system settings from being changed in tenant databases. The list
is delivered with a default con guration but this can be modi ed. The topic 'Lock Parameters Against Editing for a Tenant
Database' describes how to do this from within SAP HANA cockpit.

File Location
If properties are con gured in the database layer, a database-speci c con guration le is stored at the following location on the
server: /hana/shared/$SID/global/hdb/custom/config/DB_<dbname>

 Example
The properties in the nameserver.ini le aren’t database-speci c. They can only be con gured at system level. The
nameserver.ini le is therefore stored at /hana/shared/$SID/global/hdb/custom/config.

However, the properties in the indexserver.ini can be database-speci c. Properties that are con gured in the system
layer and apply to all databases are stored in the indexserver.ini at
/hana/shared/$SID/global/hdb/custom/config. Properties con gured for an individual database override the
system-layer value and are stored in the indexserver.ini at
/hana/shared/$SID/global/hdb/custom/config/DB_<dbname>.

Layered Con guration

Many properties can be con gured in the system, host, and database layer. Values con gured in the database layer take
precedence over system-layer values.

However, when you’re connected to a tenant database, you see that the database-layer value of a property is also displayed as
the system-layer value. This value occurs because, from the perspective of the tenant database, the database and the system
are effectively the same. The true system-layer value (that is, the value con gured for all databases in the system database) is
displayed in the tenant database as the default-layer value.

Values con gured in the host layer take precedence over database-layer values. Host values can only be con gured in the
system database.

This is custom documentation. For more information, please visit the SAP Help Portal 13
12/1/2023
You can see actual con guration values in SAP HANA cockpit, on the resources Database Overview page (select the Manage
System Con guration link on the Database Administration card), or query the following system views:

M_INIFILE_CONTENTS (SYS_DATABASES)

This view can be accessed only from the system database. It contains the values con gured for all properties on system,
host, and database layer for all active databases.

M_INIFILE_CONTENTS (SYS)

This view is available in every database and contains the values that apply to the database in question. Values that were
con gured in the system layer in the system database are identi ed as default-layer values. Values that were con gured
in the database layer in the tenant database are identi ed as system- and database-layer values. Values con gured at
the host layer are shown only for hosts on which the database is running.

Example
A system has 3 tenant databases DB1, DB2, and DB3, distributed across 2 hosts Host A and Host B:

The default value of the property [execution] max_concurrency in the global.ini le is 0. The system administrator
changes the default con guration of this property in the indexserver.ini file as follows:

First, the system administrator creates a new system-layer value (10) in indexserver.ini. Since the system-layer value
applies to all tenant databases and can’t be changed by a tenant database user, users on all tenant databases initially see the
value 10 as the default con guration:

Next, the system administrator sets a new value (20) for DB1, while leaving the con guration for DB2 and DB3 unchanged.

This is custom documentation. For more information, please visit the SAP Help Portal 14
12/1/2023

 Note
In DB1, the database-layer value is duplicated to the system layer because from the perspective of the tenant database, the
database and the system are effectively the same.

Finally, the system administrator sets a new value (15) for host A. Since host values take precedence over database values, this
value changes the effective value for DB1 and DB2.

Related Information
M_INIFILES System View
M_INIFILE_CONTENTS System View
ALTER SYSTEM ALTER CONFIGURATION Statement (System Management)
SAP HANA Con guration Parameter Reference
Lock Parameters Against Editing for a Tenant Database

System and Statistics Views in Tenant Database Systems

This is custom documentation. For more information, please visit the SAP Help Portal 15
12/1/2023
Every database has its own SYS and _SYS_STATISTICS schemas that contain information about that database only. For system-
level monitoring, additional views are accessible in the system database: the M_DATABASES (SYS) view and the views in the
SYS_DATABASES schema.

M_DATABASES

This view is available in the SYS schema of the system database of a multiple-container system. It provides an overview
of all tenant databases in the system. Only users with the system privilege DATABASE ADMIN can see the contents of
this view.

SYS_DATABASES schema

The views in the SYS_DATABASES schema provide aggregated information from a subset of the views available in the
SYS and _SYS_STATISTICS schemas of all tenant databases in the system. These union views have the additional column
DATABASE_NAME to make it possible to identify from which database the information is coming refers. The system
views in the SYS_DATABASES schema are accessible only from the system database. To be able to view information in
these views, you need the system privilege DATABASE ADMIN or CATALOG READ.

Tools such as the SAP HANA cockpit use these views to support system-level monitoring.

System and Statistics Views

Connections for Tenant Databases

Every tenant database has dedicated ports and connections for SQL-based client communication and internal communication.

The network communication channels used by SAP HANA can be categorized into those used for database clients connecting to
SAP HANA and those used for internal communication. The SAP HANA Administration Guide guide provides an overview of all

This is custom documentation. For more information, please visit the SAP Help Portal 16
12/1/2023
connection types and the standard ports used in the SAP HANA landscape. Additional ports are required to allow
communication to, from and within individual tenant databases.

To connect to a speci ed database, you can connect by specifying the port for the system database and the tenant database
name. This is recommended over specifying the speci c port for the tenant database. For example:

SERVERNODE=myserver:3<instance>13;UID=<tenant_db_username>;PWD=<password>;DATABASENAME=<tenant_db>

Port Assignment in Tenant Databases

Every tenant database has dedicated ports for SQL and internal communication. There is also a dedicated port for HTTP-based
client communication via the SAP HANA XS classic server, which runs by default as an embedded service in the index server.

However, there are no standard port number assignments. Port numbers are assigned automatically from the available port
number range according to availability at the time the database is created or a service is added. Administrators can also
explicitly specify which port numbers to use when they create a tenant database or add a service.

The only exceptions to this are the tenant database that is automatically created when you install a single-tenant system and
when you convert a single-container system to a tenant database system. This database retains the port numbers of the
original single-container system: 3<instance>03 (internal communication), 3<instance>15 (SQL), and 3<instance>08 (HTTP via
SAP HANA classic server). The ports of any subsequently added tenant database are automatically assigned according to
availability at the time.

The default port number range for tenant databases is 3<instance>40—3<instance>99. This means that the maximum number
of tenant databases that can be created per instance is 20. However, you can increase this by reserving the port numbers of
further instances. In the cockpit, a dialog will prompt you to do this, or you can con gure the property [multidb]
reserved_instance_numbers in the global.ini le. The default value of this property is 0. If you change the value to 1,
the port numbers of one further instance are available (for example, 30040—30199 if the rst instance is 00). If you change it
to 2, the port numbers of two further instances are available (for example, 30040—30299 if the rst instance is 00). And so on.

 Note
The port number of the system database are xed: 3<instance>01 (internal), 3<instance>13 (SQL), and 3<instance>14
(HTTP via XS classic server). If restricted SQL access is enabled, port 3<instance>17 is used for SQL requests to the system
database.

Let's look at some simple examples.

 Example
Example 1:

You perform a default SAP HANA system installation. This results in the automatic creation of a single tenant database. This
tenant database has the following port numbers: 3<instance>03 (internal communication), 3<instance>15 (SQL),
3<instance>08 (HTTP via XS classic server).

Then, you create two additional tenant databases. Each of these tenant databases is automatically assigned port numbers
for the following connection types:

Internal communication

SQL

HTTP (This is the port of the XS classic server embedded in the index server.)

The second database is assigned ports 3<instance>40—42, and the third 3<instance>43—45.

This is custom documentation. For more information, please visit the SAP Help Portal 17
12/1/2023
Example 2:

You install a new SAP HANA system without creating an initial tenant, by running the SAP HANA database lifecycle manager
(HDBLCM) with the create_initial_tenant ag set to off. Then, you create three tenant databases. Each of these
tenant databases is automatically assigned the following port numbers:

The rst tenant database is assigned port numbers 3<instance>40—42, the second ports 3<instance>43—45, and the third
3<instance>46—48.

Example 3:

You install a new SAP HANA system without creating an initial tenant, by running the SAP HANA database lifecycle manager
(HDBLCM) with the create_initial_tenant ag set to off. Then, you create a tenant database. The same port
numbers as above are assigned: 3<instance>40 (internal communication), 3<instance>41 (SQL), and 3<instance>42 (HTTP
via XS classic server). Next, you add a separate xsengine service to the rst database. This service is automatically assigned
the next three available port numbers: 3<instance>43—45. Finally, you create a second tenant database. This tenant
database is automatically assigned the next three available port numbers: 3<instance>46—48.

Example 4:

You convert a single-container system to a tenant database system. This results in the automatic creation of one tenant
database. This tenant database has the same port numbers as the original single-container system: 3<instance>03
(internal communication), 3<instance>15 (SQL), 3<instance>08 (HTTP via XS classic server). Then, you add a second index
server to the tenant database. It is automatically assigned port numbers 3<instance>40—42. Finally, you create a second
tenant database. It is automatically assigned ports the next three available port numbers: 3<instance>43—45.

Example 5:

You can run multiple services of the same type in a single tenant on the same host. The service ports must be within the
same port range and must not span across multiple port ranges. For example, you can assign port 30100 to index server A
and port 30103 to index server B. You cannot assign port 30100 to index server A and port 30203 to index server B.

 Note
All of the above examples refer to single-host systems and are based on automatic port number assignment.

You can determine the ports used by a particular tenant database by querying the M_SERVICES system view, either from the
tenant database itself or from the system database.

From the tenant database: SELECT SERVICE_NAME, PORT, SQL_PORT, (PORT + 2) HTTP_PORT FROM
SYS.M_SERVICES WHERE ((SERVICE_NAME='indexserver' and COORDINATOR_TYPE= 'MASTER') or
(SERVICE_NAME='xsengine'))

From the system database: SELECT DATABASE_NAME, SERVICE_NAME, PORT, SQL_PORT, (PORT + 2)
HTTP_PORT FROM SYS_DATABASES.M_SERVICES WHERE DATABASE_NAME='<DBNAME>' and
((SERVICE_NAME='indexserver' and COORDINATOR_TYPE= 'MASTER') or
(SERVICE_NAME='xsengine'))

 Remember
If your system was converted from single-container mode to a tenant database system, the HTTP port number of the rst
tenant database is always 3<instance>08 and not the port number returned using the above queries.

 Note
System privilege DATABASE ADMIN or CATALOG READ is required to read the M_SERVICES system view.

This is custom documentation. For more information, please visit the SAP Help Portal 18
12/1/2023
The following diagram shows an example of the connections and ports used in a system with two tenant databases, installed on
a single host.

Connections for Tenant Databases

HTTP(S) Client Access

The XS classic server allows Web-based applications to access SAP HANA via HTTP(S). The internal Web Dispatcher of the SAP
HANA system manages these incoming HTTP(S) requests. To allow applications to send requests to speci c databases, every
tenant database needs an alias host name. Requests to the alias host name can then be forwarded to the XS server of the
corresponding tenant database. Requests with the physical host name in the HTTP host header are forwarded to the XS server
running on the system database.

The default HTTP ports are used in all cases, that is, 80<instance> (HTTP) and 43<instance> (HTTPS). Alias host names are
mapped to internal HTTP(S) ports so that incoming requests can be routed to the correct database.

You con gure HTTP(S) access to tenant databases by specifying in the xsengine.ini le the URLs by which each tenant
database is publicly accessible. The system then automatically con gures the Web Dispatcher by generating the required pro le
entries in the webdispatcher.ini con guration le. It is not necessary to specify the URL of the system database, this is
done automatically.

For more information, see Con gure HTTP Access to Tenant Databases in the SAP HANA Administration Guide .

Restricted SQL Access

If tenant databases need to be accessible from an external network, you can open an additional SQL port to prevent SQL access
on port 3<instance>13. This prevents the exposure of the system database SQL administration port to the external network.
You enable this feature by setting the property [multidb] systemdb_separated_sql_port to true in the global.ini
le.

This is custom documentation. For more information, please visit the SAP Help Portal 19
12/1/2023
This opens port 17 for SQL requests to the system database and restricts access through port 3<instance>13 for database
mapping. The connection through port 3<instance>13 is re-routed to 3<instance>17 if a connection to the system database is
required. To connect to the system database, DATABASENAME=SYSTEMDB must be speci ed. Make sure that port 17 is not
exposed to the external network.

Related Information
Recommendations for Network Con guration
Communication Channels
Connecting to SAP HANA Databases and Servers
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic

Updating a Single-Container System

During the update to SAP HANA 2.0 SPS 01 or greater, all single-container systems are converted to support tenant databases.

As of SAP HANA 2.0 SPS 01, the multi-container database mode is the only database mode. A single-container system will be
automatically converted to a tenant database system during the update. The following sections describe the changes made
during the update.

The database of a single-container system is converted into a system database and a tenant database. A new user (SYSTEM) is
created in the system database (SYSTEMDB). During the update, a password has to be speci ed for this user. The database
superuser (SYSTEM) of the single-container system becomes the SYSTEM user of the tenant database.

If you have additional questions about the automatic conversion of your single-container system, or wish to discuss migration
support, please contact your SAP support team representative.

Updating a Single-Host, Single-Container system to Support Tenant Databases

In a single-host, single-container system the database is converted to a system database and a single tenant database.

Updating a Multiple-Host, Single-Container system to Support Tenant Databases

In a multiple-host, single-container system the database is converted to a system database on the rst master host and a
single tenant database that is spread across the worker hosts.

This is custom documentation. For more information, please visit the SAP Help Portal 20
12/1/2023

Related Information
SAP Note 2423367
Converting an SAP HANA System to Support Tenant Databases
Create a Tenant Database

Con guration
After update, you need to review and if necessary recon gure certain settings.

Con guration Area After Update

Database con guration Parameters, which were changed are stored with the tenant database and become
database-speci c.

User administration Users of the single-container database are now present in the tenant database. During the
update, you are asked to provide a new password for the system user of the system
database.

Network Ports and URLs do not change after the update.

The tenant database retains the port numbers of the original single-container system:
3 <instance>03 (internal communication), 3 <instance>15 (SQL), and 3 <instance>08
(HTTP via SAP HANA classic server).

The port number of the system database are xed: 3 <instance>01 (internal),
3 <instance>13 (SQL), and 3 <instance>14 (HTTP via XS classic server).

SAP HANA options If you were running SAP HANA options on your single-container system, no con guration
changes are required after the update. SAP HANA options hosts or host roles can be
automatically provisioned to a system that is installed with a single tenant. If the SAP
HANA system contains multiple tenant databases or if the single tenant was not running
when you added the SAP HANA options host or host role, it must be manually provisioned
to the tenant. For more information, see Important Disclaimer for Features in SAP HANA
Platform, Options and Capabilities.

XS advanced runtime If you have XS advanced runtime installed, a separate xsengine process is created and the
internal Web Dispatcher of the SAP HANA system routes by default to the single tenant.

Related Information
Important Disclaimer for Features in SAP HANA
SAP HANA Server Installation and Update Guide
Port Assignment in Tenant Databases
This is custom documentation. For more information, please visit the SAP Help Portal 21
12/1/2023

Security
After update, you need to review and if necessary recon gure certain security-related settings.

Con guration Area After Update

User administration You need to set up new users for administration (at least for recovery) in the system
database.

Network security The system database uses additional ports. These ports that might be rewalled for
security reasons in the system. If this the case, you need to open these ports so that the
system database can be accessed from the SAP HANA cockpit on other hosts.
The system database is accessible via SQL port 3 <instance_no>13.

TLS/SSL con guration for external If TLS/SSL is enabled for both the system database and tenant database, the in-database
communication certi cate collection containing the certi cates used for trust validation is available only in
the tenant database. If you want to use the same certi cates, you will need import them
into the certi cate store of the system database and add them to a certi cate collection
there.

 Caution
If TLS/SSL is being enforced for client connections (that is,
parameter[communication] sslEnforce in global.ini set to true), it will not be
possible to establish a connection to the system database. You have to set
sslEnforce to false rst.

If the certi cates used for trust validation are stored in a PSE in the le system, both the
tenant database and the system database will have access, so no recon guration is
required.

However, you should validate that sharing the certi cate stores for system database and
tenant is actually intended.

Database isolation The default system isolation level is low. It is possible to change the isolation level (from
low to high or from high to low) at any time after the update. Once high isolation has been
con gured, a dedicated OS user and group must exist for every tenant database.
Otherwise, it's not possible to create or start a tenant database.

Auditing Existing audit policies are available in the tenant database database only. You need to
create new audit policies for administration tasks in the system database.

Related Information
User Administration Tools
TLS/SSL Con guration on the SAP HANA Server
Increase the System Isolation Level
Decrease the System Isolation Level

Backup and Recovery

After update, you need to review and if necessary recon gure certain settings related to backup and recovery.

Con guration Area After Update

System database If you do not change your backup con guration, a backup of the tenant database is created
by default. It can be restored into any existing tenant database. The system database has
to be backed up separately.

This is custom documentation. For more information, please visit the SAP Help Portal 22
12/1/2023

Con guration Area After Update

Third-party tools If your backup strategy is based on data snapshots taken by a third-party tool, we
recommend that you get in touch with your snapshot tool vendor to check if the tool
supports snapshots of SAP HANA tenant database systems. If you use a script that is
based on the documented SQL statements, refer to the documentation to adapt it for use
with tenant databases.

Data snapshots As of SAP HANA 2.0 SPS 04, data snapshots are supported on single-tenant and multiple-
tenant systems.

Retention policy Without adjusting your backup retention policy, only the tenant database backups are
maintained. As a consequence, the system database backup catalog grows unchecked,
consumes main memory, and prolongs backup times. Furthermore, system database data
and log backups will eat up your backup space.

Backup history The migration from single-container mode to tenant databases does not break the backup
history. Single database data and log backups can be used to recover a tenant database
system.

Disaster recovery In the event of a disaster, you rst have to recover the system database in operational
mode offline and then the tenant database using the system database connectivity. The
system database requires to be in operational state online while recovering the tenant
database.

Related Information
SAP HANA SQL Reference Guide for SAP HANA Platform
Recovering an SAP HANA Database

Landscape
After update, you need to review and if necessary recon gure certain landscape-related settings.

Con guration Area After Update

Host addition and removal After the update, hosts can be added to or removed from a single-host or multiple-host
SAP HANA system using the SAP HANA database lifecycle manager (HDBLCM).

Scale-out To scale out a tenant database or distribute it across multiple hosts, you can add further
server components, for example, an additional index server or a separate XS server. You
add a service to a tenant database using the ALTER DATABASE statement. The statement
is executed on the system database for a speci c tenant database.

Service addition and removal Add or remove service statements are executed on the system database for a speci c
tenant database.

Related Information
Adding and Removing Hosts
Add Services in a Tenant Database

Perform an Offline Update

This is custom documentation. For more information, please visit the SAP Help Portal 23
12/1/2023
You can perform an offline update of an SAP HANA system replication landscape. A single-container system will be
automatically converted to a tenant database system during the update. Converting an SAP HANA system to a tenant
database system is permanent and cannot be reversed.

Prerequisites
The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded
service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service
as described in SAP Note 1917938.

The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

You are logged on as the system administrator user <sid>adm.

Procedure
1. Stop all SAP HANA systems on all sites.

2. Update the primary system using the SAP HANA database lifecycle manager. The migration to a tenant database
system is done automatically.

3. Wait until the update has nished and the system is active again.

4. Create a data backup of the system database.

5. Prepare the secondary system for authentication by copying the system PKI SSFS .key and the .dat le from the
primary system to the secondary system. For more information, see SAP Note 2369981 .

The .key and .dat les can be found in the following location:

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

6. Repeat steps 2, 3, and 5 on all remaining secondary systems, following the replication chain.

Related Information
SAP Note 1917938 - Migration of the statistics server for Revision 74 or higher
SAP Note 2369981 - Required con guration steps for authentication with HANA System Replication
Con guring SAP HANA System Replication

Perform a Near-Zero Downtime Update

You can perform a near-zero downtime update of an SAP HANA system replication landscape. A single-container system will be
automatically converted to a tenant database system during the update. Converting an SAP HANA system to a tenant
database system is permanent and cannot be reversed.

Prerequisites
The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded
service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service
as described in SAP Note 1917938.

The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).
This is custom documentation. For more information, please visit the SAP Help Portal 24
12/1/2023
The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

You are logged on as the system administrator user <sid>adm.

Full data shipping has been successfully completed after setting up the system replication landscape. For more
information, see Initializing the Secondary in the SAP HANA Administration Guide.

Procedure
1. Update the secondary system using the SAP HANA database lifecycle manager. The migration to a tenant database
system is triggered automatically.

2. Wait until the update has nished and all systems are in sync again. The replication will be possible in this situation
although the primary is still a single-container system.

3. Perform a takeover to the updated secondary system. Only now the migration to a tenant database system is nalized
for the secondary.

4. Update the primary system using the SAP HANA database lifecycle manager. Set the no_restart option to prevent a
restart of the primary system after the update. The migration to a tenant database system is done automatically.

5. Prepare the secondary system for authentication by copying the system PKI SSFS .key and the .dat le from the
primary system to the secondary system. For more information, see SAP Note 2369981 .

The .key and .dat les can be found in the following location:

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

6. Register this former primary system as the new secondary to the new primary (former secondary) and start it. The
conversion to a tenant database system is performed automatically.

Related Information
SAP Note 1917938 - Migration of the statistics server for Revision 74 or higher
Con guring SAP HANA System Replication
Initializing the Secondary

Security and Tenant Databases

SAP HANA provides a range of security features and functions at the database and system level to ensure secure access
control and secure system setup and con guration.

The following table provides an overview of standard security features in the SAP HANA database.

For more detailed information, see the relevant section in the SAP HANA Security Guide .

Security Feature Description

User and role management Every tenant database has its own database users and roles, including a tenant database-
speci c superuser SYSTEM.

Depending on the isolation level of the system, there may be only one operating system
(OS) user (the default <sid>adm user), or one OS user for each tenant database, which
must be created.

This is custom documentation. For more information, please visit the SAP Help Portal 25
12/1/2023

Security Feature Description

Authentication and SSO The SAP HANA database supports a number of authentication mechanisms, including
database user name/password, SAML bearer tokens, JSON Web tokens, Kerberos, and
LDAP directory server name and password. Whether a per-database con guration is
possible depends on the authentication mechanism and the user client:

Authentication by database user name and password is database speci c.

For Kerberos-based authentication, a per-database con guration is not possible.

Databases users in all databases must be mapped to users in the same Key
Distribution Center.

For certi cate-based authentication (SAML, JWT, X.509 certi cates), a per-
database con guration is possible for JDBC/ODBC client access. Different trust
stores (containing different certi cates) can be con gured for individual
databases. For this purpose, we recommend using certi cates and certi cate
collections (also referred to as personal security environments or PSEs) stored in
the database as opposed to the le system.

For LDAP-based authentication, a per-database con guration is possible.

Connections to different LDAP directory servers can be set up by creating separate
LDAP providers in each database. To secure communication between the SAP
HANA database and the LDAP server (including the transmission of passwords),
different trust stores (containing different certi cates) can be con gured for
individual databases using in-memory certi cates and certi cate collections.

 Note
LDAP-based authentication is only possible for users if authentication using
their local SAP HANA password is disabled.

Database-speci c trust stores cannot be con gured for HTTP client access
through SAP HANA Extended Services, classic model (SAP HANA XS classic).
Therefore, user authentication based on SAML assertions and X.509 certi cates
cannot be database speci c.

Authorization SAP HANA's standard authorization mechanisms are applied to users at the database level
with the following additions:

In the system database, the system privilege DATABASE ADMIN exists to allow
system administrators to perform certain tasks on tenant databases (for example,
stop a tenant database or back up a tenant database).

A cross-database authorization mechanism exists to support read-only queries

between tenant databases. This is made possible through the association of a user
in one tenant database with a user in another database. Cross-database access is
disabled by default and must be enabled and con gured by a system
administrator before such user mappings can be set up.

Encryption of data communication in the Secure communication based on the Transport Layer Security (TLS)/Secure Sockets Layer
network (SSL) protocol can be con gured separately for external communication between
individual databases and JDBC/ODBC clients. Separate key and trust stores must be
available and con gured for each database. For this purpose, we recommend using
certi cates and certi cate collections stored in the database as opposed to the le
system.

For communication with HTTP clients, a per-database con guration of TLS/SSL keys and
certi cates is also possible.

This is custom documentation. For more information, please visit the SAP Help Portal 26
12/1/2023

Security Feature Description

Data-at-rest encryption Data and log volume encryption, as well as data and log backup encryption can enabled for
the system database and tenant databases individually. Data and log volume encryption
ensures that anyone who can access the data and log volumes on disk using operating
system commands cannot see the actual data and redo log entries. Backup encryption
prevents unauthorized parties from reading the content of backups.

Masking and anonymization Data masking is an additional layer of access control that can be applied to tables and
views. A column mask protects sensitive or con dential data in a particular column of a
table or view by transforming the data in such a way that it is only visible partially or
rendered completely meaningless for an unprivileged user, while still appearing real and
consistent.

Anonymization allows you to gain statistically valid insights from your data while protecting
the privacy of individuals. Unlike masking and pseudonymization, anonymization methods
(also called privacy-enhancing methods) provide a more structured approach to modifying
data for privacy protection. The quality of such anonymized or privacy-enhanced data is
still sufficient for meaningful analysis. Data anonymization capabilities are integrated into
calculation views.

Masking and anonymization are both applied at the database level.

Auditing Actions performed in every tenant database and the system database can be audited
individually.

To ensure the privacy of tenant database audit trails, they are by default written to a
database table that is local to the database being audited. By default, tenant database
administrators cannot change the audit trail targets for their database. The system
administrator can , but this is not recommended.

If the audit trail target for tenant databases is changed to the syslog, audit entries contain
a eld Database Name so that it is possible to differentiate entries from different tenant
databases.

Additional System-Level Security Features

The following table provides an overview of additional feature to ensure the secure setup and con guration of the SAP HANA
system .

Security Feature Description

Database isolation To maximize system security by preventing cross-tenant attacks through operating system
mechanisms, it is possible to con gure the system for high isolation. In high isolation
mode, the processes of individual tenant databases must run under dedicated OS users
belonging to dedicated OS groups, instead of all processes running under the single default
OS user <sid>adm (low isolation). Data in the le system is protected using le and
directory permissions.

Con guration change blacklist To ensure the stability and performance of the overall system or for security reasons, it
may be necessary to prevent certain system properties from being changed by tenant
database administrators, for example, properties related to resource management. A
con guration change blocklist (multidb.ini) is available for this purpose. This blocklist
contains several critical properties by default. You can customize the default con guration
as well as add further properties by editing the le, for example, in the SAP HANA cockpit.

Restricted features To safeguard and/or customize your system, certain features of the SAP HANA database
can be disabled in tenant databases.

Related Information
This is custom documentation. For more information, please visit the SAP Help Portal 27
12/1/2023
SAP HANA User Management
SAP HANA Authentication and Single Sign-On
Certi cate Management in SAP HANA
SAP HANA Authorization
Securing Data Communication
Data and Log Volume Encryption
Backup Encryption
Auditing Activity in SAP HANA
SAP HANA Data Masking
SAP HANA Data Anonymization
Database Isolation
Restricted Features in Tenant Databases
Prevent Changes to System Properties in Tenant Databases

Cross-Database Authorization in Tenant Databases

Read-only queries between tenant databases are possible through the association of the requesting user with a remote identity
on the remote database(s). Cross-database access is not enabled by default and must be con gured before such user
mappings can be set up.

Every tenant database is self-contained with its own isolated set of database users and isolated database catalog. However, to
support for example cross-application reporting, cross-database SELECT queries are possible. This means that database
objects such as tables and views can be local to one database but be read by users from other databases in the same system.

A user in one database can run a query that references objects in another database if the user is associated with a sufficiently
privileged user in the remote database. This associated user is called a remote identity. This is the user who executes the query
(or part of the query) in the remote database and therefore the user whose authorization is checked.

For more information about which object types on remote databases can be accessed using this mechanism and which local
object types can access remote database objects, see Cross-Database Access in the SAP HANA Administration Guide .

Example
Assume that we have a system with 2 tenant databases: DB1 and DB2.

USER2 in DB2 wants to query the table SCHEMA1.TABLE1 in DB1, for example, SELECT * FROM DB1.SCHEMA1.TABLE1.

This can be achieved as follows:

1. The administrator of DB1 creates a user in DB1 with a remote identity in DB2:

CREATE USER USER1 WITH REMOTE IDENTITY USER2 AT DATABASE DB2

2. The administrator of DB1 grants user USER1 the privileges required to read the table SCHEMA1.TABLE1:

GRANT SELECT ON SCHEMA1.TABLE1 TO USER1 [WITH GRANT OPTION]

Now, USER2 in DB2 can select from SCHEMA1.TABLE1 in DB1.

For more information about the syntax notation, see CREATE USER in the SAP HANA SQL and System Views Reference .

Things to Note About Remote Identities

This is custom documentation. For more information, please visit the SAP Help Portal 28
12/1/2023
A user can be the remote identity for only one user in another database.

An existing user can be assigned a remote identity using the ALTER USER statement.

The association between a user and a remote identity is unidirectional. In the above example, USER2 can access
SCHEMA1.TABLE1 in DB1 as USER1, but USER1 cannot access objects in DB2 as USER2.

Only the SELECT privileges of the user in the remote database are considered during a cross-database query. Any other
privileges the remote user may have are ignored.

Before users with remote identities can be created, an administrator must enable cross-database access for the system
in the system database and specify which databases can communicate with one another. For more information, see
Enable and Con gure Cross-Database Access in the SAP HANA Administration Guide .

Users receive a Not authorized error if they attempt a cross-database operation that is not supported by the
current con guration.

System Views for Monitoring Cross-Database Authorization

The following system views contain information about cross-database authorization in a tenant database:

USERS (SYS)

The column HAS_REMOTE_USERS indicates whether or not a particular user in the local database has remote identities
in other databases.

REMOTE_USERS (SYS)

This system view shows which local users can be used by users on other databases for cross-database query execution.

 Note
The system views EFFECTIVE_PRIVILEGES and ACCESSIBLE_VIEWS do not include privileges that a user has through a
remote identity.

Related Information
Cross-Database Access
CREATE USER Statement (Access Control)
ALTER USER Statement (Access Control)
USERS System View
REMOTE_USERS System View
Enable and Con gure Cross-Database Access

Restricted Features in Tenant Databases

To safeguard and/or customize your system, certain features of the SAP HANA database can be disabled in tenant databases.

Some features of the SAP HANA database are not required or desirable in certain environments, in particular features that
provide direct access to the le system, the network, or other resources. The table below lists those features that you can
explicitly disable in tenant databases.

The system view M_CUSTOMIZABLE_FUNCTIONALITIES lists all features that can be disabled and their status. This view exists
in both the SYS schema of every database, where it contains database-speci c information, and in the SYS_DATABASES schema
of the system database, where it contains information about the enablement of features in all databases. For more information,
see M_CUSTOMIZABLE_FUNCTIONALITIES in the SAP HANA SQL and Systems View Reference .

For more information about how to disable features, see in the SAP HANA Administration Guide .

This is custom documentation. For more information, please visit the SAP Help Portal 29
12/1/2023

 Note
Features are hierarchically structured. If you disable a feature with sub-features, these are also disabled.

Feature Feature Description Why Disable?

RINTEGRATION R language Feature not required

in all deployment
scenarios

XB_MESSAGING_SUBSCRIPTIONS Subscriptions For External Messaging

Providers

AFL Access to Application Function Libraries Feature not required

(AFL) for business logic in native C++ in all deployment
scenarios

XB_EXTERNAL_CONNECTIVITY External Connectivity With XB Message

Bus

BACKUP Backup operations File system access

not wanted

BACKUP.IGNOREPATH_RESTRICT Ignore path restrictions for backup File system access

operations not wanted,
safeguard against
directory traversal
attacks

IMPORTEXPORT Import and export operations File system access

not wanted

IMPORTEXPORT.IMPORT Import operations File system read

access not wanted

IMPORTEXPORT.EXPORT Export operations File system write

access not wanted

IMPORTEXPORT.IGNORE_PATH_RESTRICT Ignoring of path restrictions for import File system access

and export not wanted,
safeguard against
directory traversal
attacks

BUILTINPROCEDURE Execution of procedures associated with --

critical and/or optional functions

BUILTINPROCEDURE.REORG_GENERATE Data redistribution operations Feature not required

in all deployment
BUILTINPROCEDURE.REORG_EXECUTE scenarios

BUILTINPROCEDURE.REORG_CLEAR_LOGS

BUILTINPROCEDURE.GEM Procedure to use the graph engine Feature not required

in all deployment
scenarios

BUILTINPROCEDURE.MANAGEMENT_CONSOLE_PROC Access to the built-in SAP HANA Safeguard against

management console (hdbcons) leakage of SAP HANA
process information

BUILTINPROCEDURE.KERNELCALL Access to rowstore internal maintenance Safeguard against

features leakage of SAP HANA
process information

This is custom documentation. For more information, please visit the SAP Help Portal 30
12/1/2023

Feature Feature Description Why Disable?

BUILTINPROCEDURE.TREXVIADBSL Operation of an SAP Business ByDesign Feature not required

system in all deployment
scenarios

BUILTINPROCEDURE.COMPRESS_FILE Compression of trace les before they Feature not required

are transferred in all deployment
scenarios

BUILTINPROCEDURE.GET_FULL_SYSTEM_INFO_DUMP Triggering of complete information dump Feature not required

of the entire system in all deployment
scenarios

BUILTINPROCEDURE.FULL_SYSTEM_INFO_DUMP_CREATE Triggering creation of complete Feature not required

information dump of the entire system in all deployment
scenarios

BUILTINPROCEDURE.FULL_SYSTEM_INFO_DUMP_DELETE Triggering deletion of complete Feature not required

information dump of the entire system in all deployment
scenarios

BUILTINPROCEDURE.FULL_SYSTEM_INFO_DUMP_RETRIEVE FULL_SYSTEM_INFO_DUMP_RETRIEVE Feature not required

execution in all deployment
scenarios

BUILTINPROCEDURE.DSO Creation of and access to DataStore Feature not required

Objects (DSOs) for SAP Business in all deployment
Warehouse (BW) powered by SAP HANA scenarios

BUILTINPROCEDURE.STATISTICSSERVER_CONFIGCHECKPROC Validation of the statistics server Feature not required

con guration and its e-mail noti cation in all deployment
capability scenarios

BUILTINPROCEDURE.BW_PRECHECK_RELEASE_LOCK Operation of an SAP BW powered by SAP Feature not required

HANA system in all deployment
BUILTINPROCEDURE.BW_PRECHECK_ACQUIRE_LOCK_WITH_TYPE scenarios

BUILTINPROCEDURE.BW_PRECHECK_ACQUIRE_LOCK

BUILTINPROCEDURE.BW_CONVERT_CLASSIC_TO_IMO_CUBE

BUILTINPROCEDURE.BW_F_FACT_TABLE_COMPRESSION

BUILTINPROCEDURE.UPDATE_LANDSCAPE_CONFIGURATION Changes to system landscape and the Feature not required

available services in a system in all deployment
scenarios

ALTERSYSTEM Execution of the statement ALTER Feature not required

SYSTEM RECONFIGURE SERVICE, which in all deployment
ALTERSYSTEM.RECONFIGURE_SERVICE re-reads the service con guration scenarios

SMARTDATAACCESS Federated access to other database Feature not required

systems through virtual tables in all deployment
scenarios

DXC Data acquisition and consumption of Feature not required

data models from the SAP Business in all deployment
Suite scenarios

DYNAMIC_TIERING SAP HANA Dynamic Tiering operations Feature not required

in all deployment
DYNAMIC_TIERING.CREATE_EXTENDED_STORAGE Creation of extended storage scenarios

DYNAMIC_TIERING.DROP_EXTENDED_STORAGE Deletion of extended storage

This is custom documentation. For more information, please visit the SAP Help Portal 31
12/1/2023

Feature Feature Description Why Disable?

DYNAMIC_TIERING.ALTER_EXTENDED_STORAGE Changes to extended storage

DYNAMIC_TIERING.ALTER_TABLE_TYPE Conversion of a regular database table to

an extended table or the reverse

DYNAMIC_TIERING.BULK_INSERT_OPTIMIZATION Bulk insert optimization that executes

large inserts into extended tables using a
load statement

DYNAMIC_TIERING.QUERY_PLAN_RELOCATION Query relocation operation that moves

data from SAP HANA and SAP HANA
Dynamic Tiering for optimal query
performance

ACCELERATOR_FOR_ASE SAP HANA Accelerator for SAP ASE

operations

BOE SAP BusinessObjects Explorer API Feature not required

in all deployment
scenarios

SMART_DATA_STREAMING SAP HANA Streaming Analytics Feature not required

operations in all deployment
scenarios

GRAPH_ENGINE SAP HANA Graph Engine Feature not required

in all deployment
scenarios

LDAP All operations related to LDAP group Feature not required

authorization including in all deployment
creating/modifying LDAP providers, scenarios
changing user authorization mode to
LDAP, mapping LDAP groups to SAP
HANA roles, and so on.

 Caution
If the LDAP feature is disabled,
existing users with authorization
mode LDAP cannot log on. The
authorization mode of these users
can be changed to LOCAL.

EPMPLANNING SAP HANA Enterprise Performance Feature not required

Management planning feature in all deployment
scenarios

PLANNINGENGINE Planning engine features Feature not required

in all deployment
scenarios

Related Information
Disable Features on a Tenant Database
M_CUSTOMIZABLE_FUNCTIONALITIES System View

Default Blocklisted System Properties in Tenant Databases

This is custom documentation. For more information, please visit the SAP Help Portal 32
12/1/2023
In systems that support tenant databases, there’s con guration change blocklist multidb.ini, which is delivered with a
default con guration.

The following table lists the system properties that are included in the multidb.ini le by default. So, tenant database
administrators can’t change these properties. System administrators can still change these properties in the system database
in all layers.

You can customize the default con guration change blocklist by changing existing entries in the multidb.ini le and adding
new ones. For more information about how to prevent changes to speci c system properties in tenant databases, see Prevent
Changes to System Properties in Tenant Databases in the SAP HANA Administration Guide .

File/Section Properties Description

auditing configuration default_audit_trail_type Prevents

con guration of
emergency_audit_trail_type audit trail
targets and the
alert_audit_trail_type
maximum audit
critical_audit_trail_type statement
length
audit_statement_length

auditing_csvtextfile max_file_size Prevents

con guration of
max_files the CSV text le
audit trail les

communication * Prevents
con guration of
default key and
trust stores, as
well as other
critical
communication
settings

global.ini/customizable_functionalities * Prevents
disabling of
restricted
features

global.ini/extended_storage * Prevents
con guration of
global.ini/persistence basepath_datavolumes_es extended
storage (SAP
basepath_logvolumes_es
HANA dynamic
basepath_databackup_es tiering)

basepath_logbackup_es

global.ini/system_replication keep_old_style_alert Prevents

con guration of
enable_full_sync certain system
replication
operation_mode
settings

global.ini/system_replication_communication *

global.ini/system_replication_hostname_resolution *

This is custom documentation. For more information, please visit the SAP Help Portal 33
12/1/2023

File/Section Properties Description

global.ini/xb_messaging * Prevents
con guration of
messaging

multidb.ini/readonly_parameters * Prevents
con guration of
the
multidb.ini
le itself

indexserver.ini/authentication SapLogonTicketTrustStore Prevents

con guration of
the trust store
for user
authentication
with
logon/assertion
tickets

memorymanager allocationlimit Prevents

con guration of
minallocationlimit memory
allocation
global_allocation_limit
parameters
async_free_threshold

async_free_target

execution max_concurrency Prevents

con guration of
session maximum_connections threading and
parallelization
maximum_external_connections
parameters
sql sql_executors

Related Information
Prevent Changes to System Properties in Tenant Databases
Unlock Blocklisted Parameters
Copy Blocklisted Parameters

Managing Tenant Databases

As the administrator of a tenant database system, you are responsible for creating and con guring new tenant databases,
subsequently monitoring the availability and performance of databases, as well as performing certain database administration
tasks.

 Note
Administration of tenant databases is possible using the SAP HANA cockpit. However, command-line tools are required for
some tasks.

 Note

This is custom documentation. For more information, please visit the SAP Help Portal 34
12/1/2023
If you have SAP HANA options installed, review the section about tenant databases in the administration guide of the
corresponding option for additional information before proceeding. Be aware that you need additional licenses for SAP
HANA options and capabilities. For more information, see Important Disclaimer for Features in SAP HANA Platform, Options
and Capabilities.

Managing Audit Policies

You can change or delete audit policies for one or more tenant databases.

For more information, see Manage Audit Policies for Tenant Databases in Security Administration and User Management .

Related Information
Creating and Con guring Tenant Databases
Monitoring and Managing Tenant Databases
Memory and CPU Usage for Tenant Databases
Important Disclaimer for Features in SAP HANA
Manage Audit Policies for Tenant Databases

Creating and Con guring Tenant Databases

You create tenant databases after installation if no initial tenant was created, after conversion from a single-container system
to a multiple-container system, or anytime a new database is needed.

As a system administrator, you create tenant databases from the system database. You can then con gure the new databases
as required:

Increase the database isolation level

Disable certain features that are not required in tenant databases (for example, backup operations). Disabled features
in tenant databases can still be accessed through the system database.

Enable and con gure cross-database access if read-only queries between tenant databases is required

Edit the con guration change blacklist so that critical system properties cannot be changed by tenant database
administrators

Con gure the SAP Web Dispatcher if tenant databases will be accessed by HTTP clients via the SAP HANA XS classic
server

 Note
Administration of tenant databases is possible using the SAP HANA cockpit. However, command-line tools are required for
some tasks.

Related Information
Converting an SAP HANA System to Support Tenant Databases
Increase the System Isolation Level
Create a Tenant Database
Disable Features on a Tenant Database
Enable and Con gure Cross-Database Access
Prevent Changes to System Properties in Tenant Databases
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic
Administration of Tenant Databases
This is custom documentation. For more information, please visit the SAP Help Portal 35
12/1/2023

Converting an SAP HANA System to Support Tenant Databases

You can convert an SAP HANA system to support tenant databases using the SAP HANA database lifecycle manager
(HDBLCM) resident program. Converting an SAP HANA system to a tenant database system is permanent and cannot be
reversed.

If your system was installed in single-container mode, you can still implement tenant databases by converting the system to a
tenant database system. During the conversion process, the system database and one tenant database are created. The
tenant database contains all the data of the original system, including users, system con guration, connection properties (port
con guration), and system license. However, it does not contain the backup history.

After conversion, you can create and con gure further tenant databases as needed.

 Note
After conversion, a port offset value of 100 is used to reserve ports for system replication communication. A port offset that
you de ned before the conversion is not changed.

Related Information
Convert to Tenant Databases Using the Graphical User Interface
Convert to Tenant Databases Using the Command-Line Interface
Convert to Tenant Databases Using the Web User Interface

Convert to Tenant Databases Using the Graphical User Interface

You can convert an SAP HANA system to support tenant databases using the SAP HANA database lifecycle manager
(HDBLCM) resident program in the graphical user interface. Converting an SAP HANA system to a tenant database system is
permanent and cannot be reversed.

Prerequisites
The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The host has access to the installation directories <sapmnt> and <sapmnt>/<SID>.

The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

The SAP HANA database server is up and running.

You are logged on as root user or as the system administrator user <sid>adm.

Procedure
1. Change to the SAP HANA resident HDBLCM directory:

cd <sapmnt>/<SID>/hdblcm

By default, <sapmnt> is /hana/shared.

2. Start the SAP HANA database lifecycle manager interactively in the graphical user interface:

./hdblcmgui

This is custom documentation. For more information, please visit the SAP Help Portal 36
12/1/2023
The SAP HANA database lifecycle manager graphical user interface appears.

 Note
To activate the local secure (LSS) store during installation, run hdblcmgui with the parameter
secure_store=localsecurestore.

3. Select Convert to Tenant Databases from the activity options. Then select Next.

4. Provide the password of the <sid>adm user and the SYSTEM user of SYSTEMDB, then select Next.

5. Review the summary, and select Run to nalize the con guration.

Results
Your SAP HANA system is a tenant database system with one system database and one tenant database, both of which are
running. You can verify this by adding both databases to SAP HANA cockpit and querying the public view M_DATABASES from
the system database. The result will look like this:

| DATABASE_NAME |DESCRIPTION | ACTIVE_STATUS |

|-----------------|----------------------------------|---------------|
| SYSTEMDB | SystemDB-<SID>-<INSTANCE> | YES |
| <SID> | SingleDB-<SID>-<INSTANCE> | YES |

Note the following about the tenant database:

It contains all the data (including users, con guration, and connection properties) of the original system (but not the
original backup history).

Con guration les that are tenant-speci c (e.g. indexserver.ini, xsengine.ini, etc.) are now stored at the following
location: /usr/sap/<SID>/SYS/global/hdb/custom/con g/DB_<database_name>.

Its trace les are now stored at the following location:

/usr/sap/<SID>/HDB<instance>/<host>/trace/DB_<database_name>.

 Note
Any trace les that were in the trace directory before the system was converted are not moved.

Next Steps
Create and con gure any additionally required tenant databases. For more information, see Create a Tenant Database .

 Note
If you con gured the properties of the index server, script server, or xsengine server in your original system, these
settings initially apply to all new tenant databases. You must explicitly con gure tenant database if required. For
more information, see System Properties in Tenant Database Systems in the SAP HANA Administration Guide .

If HTTP access via the SAP HANA XS classic server is required, update the con guration of the Web Dispatcher. For more
information, see Con gure HTTP Access to Tenant Databases in the SAP HANA Administration Guide .

Related Information
Password Policy Con guration Options
Create a Tenant Database
Deploy a Delivery Unit Archive (*.tgz)
Install a Permanent License
Creating Backups
Database-Speci c Con guration Parameters
This is custom documentation. For more information, please visit the SAP Help Portal 37
12/1/2023
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic

Convert to Tenant Databases Using the Command-Line Interface

You can convert an SAP HANA system to support tenant databases using the SAP HANA database lifecycle manager
(HDBLCM) resident program in the command-line interface. Converting an SAP HANA system to a tenant database system is
permanent and cannot be reversed.

Prerequisites
The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The host has access to the installation directories <sapmnt> and <sapmnt>/<SID>.

The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

The SAP HANA database server is up and running.

You are logged on as root user or as the system administrator user <sid>adm.

Procedure
1. Change to the SAP HANA resident HDBLCM directory:

cd <sapmnt>/<SID>/hdblcm

By default, <sapmnt> is /hana/shared.

2. Start the SAP HANA database lifecycle manager interactively in the command line:

./hdblcm --action=convert_to_multidb

3. Provide the password of the <sid>adm user and SYSTEM user of SYSTEMDB user.

4. Review the summary, and select y to nalize the con guration.

Results
Your SAP HANA system is a tenant database system with one system database and one tenant database, both of which are
running. You can verify this by adding both databases to SAP HANA cockpit and querying the public view M_DATABASES from
the system database. The result will look like this:

| DATABASE_NAME |DESCRIPTION | ACTIVE_STATUS |

|-----------------|----------------------------------|---------------|
| SYSTEMDB | SystemDB-<SID>-<INSTANCE> | YES |
| <SID> | SingleDB-<SID>-<INSTANCE> | YES |

Note the following about the tenant database:

It contains all the data (including users, con guration, and connection properties) of the original system (but not the
original backup history).

Con guration les that are tenant-speci c (e.g. indexserver.ini, xsengine.ini, etc.) are now stored at the following
location: /usr/sap/<SID>/SYS/global/hdb/custom/con g/DB_<database_name>.

Its trace les are now stored at the following location:

/usr/sap/<SID>/HDB<instance>/<host>/trace/DB_<database_name>.

This is custom documentation. For more information, please visit the SAP Help Portal 38
12/1/2023

 Note
Any trace les that were in the trace directory before the system was converted are not moved.

Next Steps
Create and con gure any additionally required tenant databases. For more information, see Create a Tenant Database .

 Note
If you con gured the properties of the index server, script server, or xsengine server in your original system, these
settings initially apply to all new tenant databases. You must explicitly con gure tenant database if required. For
more information, see System Properties in Tenant Database Systems in the SAP HANA Administration Guide .

If HTTP access via the SAP HANA XS classic server is required, update the con guration of the Web Dispatcher. For more
information, see Con gure HTTP Access to Tenant Databases in the SAP HANA Administration Guide .

Related Information
Password Policy Con guration Options
Create a Tenant Database
Deploy a Delivery Unit Archive (*.tgz)
Install a Permanent License
Creating Backups
Database-Speci c Con guration Parameters
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic
import_content
nostart
nostart_tenant_db
timeouts

Convert to Tenant Databases Using the Web User Interface

You can convert an SAP HANA system to support tenant databases using the SAP HANA database lifecycle manager Web user
interface. Converting an SAP HANA system to a tenant database system is permanent and cannot be reversed.

Prerequisites
The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The host has access to the installation directories <sapmnt> and <sapmnt>/<SID>.

The SAP HANA system has been installed or updated with the SAP HANA database lifecycle manager (HDBLCM).

The SAP HANA database server is up and running.

You should verify that the following prerequisites are ful lled before trying to access the SAP HANA database lifecycle manager
from a Web browser.

The communication port 1129 is open.

Port 1129 is required for the SSL communication with the SAP Host Agent in a standalone browser via HTTPS.

This is custom documentation. For more information, please visit the SAP Help Portal 39
12/1/2023
The following Web browser requirements are ful lled:

Microsoft Windows

Internet Explorer - Version 9 or higher

If you are running Internet Explorer version 9, make sure that your browser is not running in compatibility
mode with your SAP HANA host. You can check this in your browser by choosing Tools Compatibility
View Settings .

Microsoft Edge

Mozilla Firefox - Latest version and Extended Support Release

Google Chrome - Latest version

SUSE Linux - Mozilla Firefox with XULRunner 10.0.4 ESR

Mac OS - Safari 5.1 or higher

 Note
For more information about supported Web browsers for the SAP HANA database lifecycle manager Web interface,
see the browser support for sap.m library in the SAPUI5 Developer Guide .

You are logged on as the system administrator user <sid>adm.

The <sid>adm user has read and execute permissions for the directory that contains the installation medium.

Procedure
1. Access the SAP HANA HDBLCM Web user interface.

Option Description

Web browser Enter the SAP HANA database lifecycle manager (HDBLCM)
URL in an HTML5-enabled browser:
https://<hostname>:1129/lmsl/HDBLCM/<SID>/index.html

 Note
The URL is case sensitive. Make sure you enter upper and
lower case letters correctly.

SAP HANA cockpit a. Enter the URL of the SAP HANA cockpit administration
and monitoring console in your browser.

https://<host_FQDN>:<port>

 Note
FQDN = fully quali ed domain name

b. Drill down on the name of the system from My

Resources or from a group.

c. The links in Platform Lifecycle Management each

launch additional functionality, giving you expanded
capabilities for managing the resource.

2. Select the Convert to Tenant Databases tile.

This is custom documentation. For more information, please visit the SAP Help Portal 40
12/1/2023
3. Optional: Modify the following parameters in the Advanced Parameters Con guration dialog. To access the Advanced
Parameters Con guration dialog, click on the gear icon in the footer bar of the SAP HANA HDBLCM Web user interface.

Option Description

Import Delivery Units In The System Database Import Delivery Units In The System Database

Do Not Start Instance After Recon guration Do Not Start Instance After Recon guration

Do Not Start Tenant Database After Recon guration Do Not Start Tenant Database After Recon guration

Timeouts Sets customized timeouts (start_instance,

stop_instance).

4. Provide the password of the <sid>adm user and SYSTEM user of SYSTEMDB user, then select Next.

5. Review the summary, and select Run to nalize the con guration.

Results
Your SAP HANA system is a tenant database system with one system database and one tenant database, both of which are
running. You can verify this by adding both databases to SAP HANA cockpit and querying the public view M_DATABASES from
the system database. The result will look like this:

| DATABASE_NAME |DESCRIPTION | ACTIVE_STATUS |

|-----------------|----------------------------------|---------------|
| SYSTEMDB | SystemDB-<SID>-<INSTANCE> | YES |
| <SID> | SingleDB-<SID>-<INSTANCE> | YES |

Note the following about the tenant database:

It contains all the data (including users, con guration, and connection properties) of the original system (but not the
original backup history).

Con guration les that are tenant-speci c (e.g. indexserver.ini, xsengine.ini, etc.) are now stored at the following
location: /usr/sap/<SID>/SYS/global/hdb/custom/con g/DB_<database_name>.

Its trace les are now stored at the following location:

/usr/sap/<SID>/HDB<instance>/<host>/trace/DB_<database_name>.

 Note
Any trace les that were in the trace directory before the system was converted are not moved.

Next Steps
Create and con gure any additionally required tenant databases. For more information, see Create a Tenant Database .

 Note
If you con gured the properties of the index server, script server, or xsengine server in your original system, these
settings initially apply to all new tenant databases. You must explicitly con gure tenant database if required. For
more information, see System Properties in Tenant Database Systems in the SAP HANA Administration Guide .

If HTTP access via the SAP HANA XS classic server is required, update the con guration of the Web Dispatcher. For more
information, see Con gure HTTP Access to Tenant Databases in the SAP HANA Administration Guide .

Related Information
SAPUI5 Developer Guide

This is custom documentation. For more information, please visit the SAP Help Portal 41
12/1/2023
Password Policy Con guration Options
Create a Tenant Database
Deploy a Delivery Unit Archive (*.tgz)
Install a Permanent License
Creating Backups
Database-Speci c Con guration Parameters
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic

Parameter Reference: Converting an SAP HANA System to

Support Tenant Databases
Parameters can be speci ed when converting an SAP HANA system to tenant databases in order to customize the
con guration task.

The SAP HANA database lifecycle manager convert to multidb action also supports the following parameters:

batch

configfile

dump_configfile_template

help

list_systems

read_password_from_stdin

version

For more information about these parameters, see the SAP HANA Server Installation and Update Guide

For a complete list of the parameters, call the help of the convert to multidb task with the following command:

./hdblcm --action=convert_to_multidb --help

Related Information
batch
con g le
dump_con g le_template
help
list_systems
read_password_from_stdin
version
Specifying Passwords

import_content
Imports delivery units.

Syntax

This is custom documentation. For more information, please visit the SAP Help Portal 42
12/1/2023
In the command line, the following syntax is used:

--import_content[=off]

Remarks

The default for this parameter is --import_content.

Related Information
SAP HANA Content

nostart
Prevents the SAP HANA system from being started.

Syntax

In the command line, the following syntax is used:

--nostart

nostart_tenant_db
Prevents the SAP HANA tenant databases from being started.

Syntax

In the command line, the following syntax is used:

--nostart_tenant_db

Convert a System Replication Landscape to Support Tenant

Databases
An SAP HANA system replication landscape can be converted to support tenant databases in an offline or near-zero downtime
approach.

You can convert an SAP HANA single database container system that is part of a system replication con guration to support
tenant databases. You have the choice to convert your SAP HANA system after taking all sites offline, or to convert in a near-
zero downtime approach to minimize system downtime.

Offline Conversion
To perform an offline conversion all systems at all sites must rst be stopped. Then, starting with the primary site, execute the
conversion script. Once the primary site is converted and online again, continue the conversion procedure with the next site,
following the replication chain.

Near-Zero Downtime Conversion

This is custom documentation. For more information, please visit the SAP Help Portal 43
12/1/2023
In order to carry out a near-zero downtime conversion, execute the conversion script on the secondary site. Once the
conversion of this site is complete, perform a takeover. After stopping all other systems, execute the conversion script on the
primary site and reregister the primary system.

Related Information
Perform an Offline Conversion
Perform a Near-Zero Downtime Conversion

Perform an Offline Conversion

You can perform an offline conversion of an SAP HANA system replication landscape to support tenant databases. Converting
an SAP HANA system to a tenant database system is permanent and cannot be reversed.

Prerequisites
The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded
service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service
as described in SAP Note 1917938.

The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

You are logged on as the system administrator user <sid>adm.

Procedure
1. Stop all SAP HANA systems on all sites.

2. Run the following command on the master host of the primary system:

<sapmnt>/<SID>/hdblcm/hdblcm --action=convert_to_multidb

By default, <sapmnt> is /hana/shared.

3. Specify a new system user password.

4. Wait until the conversion has nished and the system is active again.

5. Create a data backup of the system database.

6. Repeat steps 2 through 4 on all remaining secondary systems, following the replication chain.

Related Information
SAP Note 1917938
Con guring SAP HANA System Replication

Perform a Near-Zero Downtime Conversion

You can perform a near-zero downtime conversion of an SAP HANA system replication landscape to support tenant databases.
Converting an SAP HANA system to a tenant database system is permanent and cannot be reversed.

This is custom documentation. For more information, please visit the SAP Help Portal 44
12/1/2023

Prerequisites
The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded
service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service
as described in SAP Note 1917938.

The SAP HANA system has been installed with its server software on a shared le system (export options rw,
no_root_squash).

The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).

You are logged on as the system administrator user <sid>adm.

Procedure
1. Run the following command on master host of the secondary system:

<sapmnt>/<SID>/hdblcm/hdblcm --action=convert_to_multidb

By default, <sapmnt> is /hana/shared.

2. Specify a new system user password.

3. Wait until the conversion has nished and all systems are in sync again.

4. Stop all systems except the one you just converted.

5. Perform a takeover by the converted system.

6. Run the following command on master host of the primary system:

<sapmnt>/<SID>/hdblcm/hdblcm --action=convert_to_multidb --nostart

7. Reregister the original primary system as the new secondary system.

Related Information
SAP Note 1917938
Con guring SAP HANA System Replication

Increase the System Isolation Level

You can increase the isolation level of an existing system from low (default) to high. With high isolation, the processes of
individual tenant databases run under dedicated operating system (OS) users belonging to dedicated (OS) groups and internal
communication is secured.

Prerequisites
You have root access to the SAP HANA system.

You’re logged on to the system database.

You have the system privilege DATABASE ADMIN.

Internal SAP HANA communication has been appropriately con gured for TLS/SSL.

[communication] ssl in the global.ini le must have the value systemPKI.

 Note

This is custom documentation. For more information, please visit the SAP Help Portal 45
12/1/2023
For more information, see Secure Internal Communication and Server-Side TLS/SSL Con guration Properties for
Internal Communication in the SAP HANA Security Guide .

If the system is running in an SAP HANA system replication con guration, the system PKI SSFS data le and key le have
been copied from the primary system to the same location on the secondary systems:

$DIR_INSTANCE/../global/security/rsecssfs/data/SSFS_<SID>.DAT

$DIR_INSTANCE/../global/security/rsecssfs/key/SSFS_<SID>.KEY

Procedure
1. For every tenant database, create a dedicated OS user and group:

a. As root user, log on to the server on which the name server of the system database is running.

b. Create new groups for every tenant database:

groupadd <groupname>

c. Create new users for every tenant database, specifying sapsys as the primary group:

useradd -g sapsys <username>

d. Add every new user to the sidshm group and their own group as secondary groups:

usermod -G <sid>shm,<usergroup> <username>

 Note
If the system is distributed across multiple hosts, you must create identical users and groups on every host. Users
and groups must have the same names and IDs on all hosts.

2. Stop all tenant databases in the system.

In the system database, in an SQL console, execute:

ALTER SYSTEM STOP DATABASE <databasename>;

 Tip
You can also stop tenant databases in the Database Management app in SAP HANA cockpit.

3. Con gure the system for high isolation.

As the operating system user <sid>adm, log on to the server on which the master index server is running and run the
following command:

python /usr/sap/<SID>/HDB<instance>/exe/python_support/convertMDC.py --change=databaseIsolatio

This command runs the following actions:

Stops the system

Changes the value of the [multidb] database_isolation property in the global.ini le to high

Starts the system

4. Assign every database to their respective OS user and group.

In the system database, in an SQL console, execute:

ALTER DATABASE <databasename> OS USER '<username>' OS GROUP '<groupname>'

 Tip
This is custom documentation. For more information, please visit the SAP Help Portal 46
12/1/2023
You can also assign OS users and groups in the Database Management app of the SAP HANA cockpit.

5. Start all tenant databases.

In the system database, in an SQL console, execute:

ALTER SYSTEM START DATABASE <database_name>

 Tip
You can also start tenant databases in the Database Management app of the SAP HANA cockpit.

Results
The system is now running in high isolation mode. As a result:

The processes of individual tenant databases run under dedicated OS users belonging to dedicated OS groups, and the
processes of the system database run under the <sid>adm user.

Internal database communication is authenticated using X.509 client certi cates. Depending on how SSL for internal
communication is con gured, data communication within databases may also be encrypted. For more information about
secure internal communication, see the SAP HANA Security Guide .

Operations that require operating system access are restricted to users with the correct permissions. For more
information, see the section on le and directory permissions with high isolation.

New tenant databases can only be created if a dedicated OS user and group exist.

Related Information
Database Isolation
Start a Tenant Database
Create a Tenant Database
Assign the OS User and Group for High Isolation
Secure Internal Communication
File and Directory Permissions with High Isolation
Isolation Level High for Backups and Third-Party Backup Tools
Server-Side TLS/SSL Con guration Properties for Internal Communication
SAP HANA Security Guide

Database Isolation
Every tenant database is self-contained and isolated in terms of users, database catalog, repository, logs, and so on. However,
to protect against unauthorized access at the operating system (OS) level, it's possible to increase isolation further through OS
user separation and authenticated communication within databases.

OS User Separation
By default, all database processes run under the default OS user <sid>adm. If it's important to mitigate against cross-
database attacks through OS mechanisms, you can con gure the system for high isolation. In this way, the processes of
individual tenant databases must run under dedicated OS users belonging to dedicated OS groups, instead of all database
processes running under <sid>adm. Database-speci c data on the le system is then protected using standard OS le and
directory permissions.

 Note
This is custom documentation. For more information, please visit the SAP Help Portal 47
12/1/2023
<sid>adm is the OS user for the system database.

Authenticated Communication
In addition, once high isolation has been con gured, internal database communication is secured using the Transport Layer
Security (TLS)/Secure Sockets Layer (SSL) protocol. Certi cate-based authentication is used to ensure that only the
processes belonging to the same database can communicate with each other. It’s also possible to con gure internal
communication so that all data communication within databases is encrypted.

 Note
If cross-database access is enabled, communication between con gured tenant databases is allowed.

High Database Isolation

Con guration
You can specify the isolation level of the system during installation. The default isolation level is low. It’s also possible to change
the isolation level of an existing system (from low to high or from high to low) at any time. For more information, see Increase
the System Isolation Level in the SAP HANA Administration Guide . Once high isolation has been con gured, a dedicated OS
user and group must exist for every tenant database. Otherwise, it's not possible to create or start a tenant database.

Internal database communication is secured with the same mechanism used for securing other internal SAP HANA
communication channels. Once high isolation has been con gured, authenticated communication within databases is enabled
without any change required to the default TLS/SSL con guration for internal communication. However, encryption of data
communication may need to be con gured explicitly.

This is custom documentation. For more information, please visit the SAP Help Portal 48
12/1/2023

Related Information
File and Directory Permissions with High Isolation
Secure Internal Communication
Increase the System Isolation Level
SAP HANA Administration Guide

File and Directory Permissions with High Isolation

In an SAP HANA system con gured for high isolation, database-speci c data on the le system is protected using standard le
and directory permissions. All le and directory permissions are managed by the SAP HANA system and don’t need to be set by
the administrator.

System Database
The following table shows who has access to which data on the le system:

Files and Directories Tenant OS User in Tenant OS <sid>adm User

Group

Files in directory containing system con guration les Read permission (644) Read permission (644)

Files in trace directory of the system database Read and write permissions
(600)

Directory containing Backint parameter le Read permission (700) Read permission (700)

Backint parameter le Read and write permissions Read and write permissions
(660) (600)

Tenant Database
The following table shows who has access to which data on the le system:

 Note
If you want to grant the system administrator access to the tenant database backup les and directories, you need to add
the <sid>adm user to each tenant's operating system group.

Files and Directories Tenant OS User in Tenant OS <sid>adm User

Group

Database-speci c directories containing: Read, write, and execute

Data volumes permissions (770)

Log volumes

Log mirror volumes

Backups

Database-speci c directories containing: Read, write, and execute Read, write, and execute
Con guration (*ini) les permissions (770) permissions (770)

Trace les

This is custom documentation. For more information, please visit the SAP Help Portal 49
12/1/2023

Files and Directories Tenant OS User in Tenant OS <sid>adm User

Group

Files in database-speci c directory containing: Read and write permissions Read and write permissions
Con guration (*ini) les (666) (666)

Trace les

Directory containing Backint parameter le Read, write, and execute Read, write, and execute
permissions (750) permissions (750)

Backint parameter le Read and write permissions Read and write permissions
(640) (640)

Related Information
Working with Third-Party Backup Tools
SAP HANA Security Guide

Decrease the System Isolation Level

If you con gured a system for high isolation during installation or later, you can decrease it back to the default low level if
necessary. With low isolation, the processes of all databases run under the default operating system (OS) user <sid>adm.

Prerequisites
You have root access to the SAP HANA system.

You’re logged on to the system database.

You have the system privilege DATABASE ADMIN.

Procedure
1. Stop all tenant databases in the system.

In the system database, execute the SQL statement ALTER SYSTEM STOP DATABASE <databasename>.

 Tip
You can also stop tenant databases in the Manage Databases app of the SAP HANA cockpit.

2. Con gure the system for low isolation.

As the operating system user <sid>adm, log on to the server on which the master index server is running and run the
following command:

python /usr/sap/<SID>/HDB<instance>/exe/python_support/convertMDC.py --change=databaseIsolatio

This command runs the following actions:

Stops the system

Changes the value of the [multidb] database_isolation property in the global.ini le to low

Starts the system

3. Clear the assignment of OS users and groups to tenant databases.

In the system database, in an SQL console, execute

This is custom documentation. For more information, please visit the SAP Help Portal 50
12/1/2023

ALTER DATABASE <database_name> OS USER '' OS GROUP ''

for every tenant database.

 Tip
You can also clear the OS users and groups in the Manage Databases app of the SAP HANA cockpit.

4. Start all tenant databases.

In the system database, in an SQL console, execute

ALTER SYSTEM START DATABASE <database_name>

 Tip
You can also start tenant databases in the Database Management app of the SAP HANA cockpit.

Results
The system is now running in low isolation mode again.

The processes of all databases run under <sid>adm.

Internal database communication isn’t authenticated.

Related Information
Start a Tenant Database
Stop a Tenant Database

Create a Tenant Database Using Replication

You can create tenant databases by replicating from existing tenant databases.

Prerequisites
You have con gured tenant replication.

You've navigated to the Database Overview page of the system database of the source or target system. See Getting to
the Database Overview Page in the SAP HANA Administration with SAP HANA Cockpit guide.

You have the system privilege DATABASE ADMIN.

You have created a complete system backup for the source tenant database.

 Caution
When you use the cockpit to move a tenant, the source database is deleted as part of the process. If the source is
running SAP HANA 2.0 SP01 or earlier, its backups are also deleted as part of the process—you can't roll back! Before
moving, SAP recommends that you run a backup, then replicate the backup to a new location.

For the target (the database where you're putting the moved or copied database):

You must have the system privileges DATABASE ADMIN.

This is custom documentation. For more information, please visit the SAP Help Portal 51
12/1/2023
If the system is con gured for high isolation, the operating system (OS) user and group required for the new tenant
database already exist. For more information, see Database Isolation in the SAP HANA Administration Guide .

You are logged in to the system database (SYSTEMDB).

Procedure
1. At the top of the Database Overview page, click Database Management.

2. To create a new tenant based on an existing tenant, choose Create Tenant Create Tenant Using Replication .

3. To create a copy of an existing tenant database, select Copy using replication. To remove the original tenant after the
copy has been created, select Move using replication.

4. Select the source database and tenant.

5. Enter a name for the new tenant.

Restrictions apply to tenant names. Alphanumerical string of uppercase alpha characters [A-Z], digits [0-9] are
permitted, starting with a letter. Depending on the le system, tenant names with up to 253 characters are supported.

6. (Optional) Specify the number of the internal communication port of the listed services.

Under Advanced Settings, specify the port number for each service. If you don't enter a port, it’s assigned automatically
based on port number availability. In multihost systems enter host and port of a service. For more information about port
number assignment, see Connections for Tenant Databases in the SAP HANA Master Guide .

7. (For high isolation system only) Enter a dedicated OS user and group for the source.

8. If con guration changes are required for the replication, warnings appear to indicate the required changes. Select
Approve to proceed.

You may see a warning that you do not have the privilege required to check if the databases are fully con gured for
tenant replication. Please contact your system administrator to make sure that tenant replication has been properly
con gured.

9. If prompted, enter the SAP Control credentials required for the restart of the system.

10. If a trust relationship has not yet been established between the source system and the target system, select an existing
public key certi cate or upload a certi cate.

11. Review the summary, then choose Copy Tenant Database or Move Tenant Database to start replicating the tenant
database.

Next Steps
Register the new tenant in SAP HANA Cockpit Manager so it can be managed by SAP HANA Cockpit.

Related Information
Linux Kernel Parameters
Delete a Tenant Database
Start a Tenant Database
Monitoring Tenant Databases in SAP HANA Cockpit
CREATE DATABASE Statement (Tenant Database Management)
SAP HANA Administration Guide
SAP HANA Master Guide
Con gure Tenant Replication
Copy or Move a Tenant Database Using Replication

Start a Tenant Database

This is custom documentation. For more information, please visit the SAP Help Portal 52
12/1/2023
You can start tenant databases either individually, or all at once by starting the whole system.

Prerequisites
You've navigated to the Database Overview page of the database you want to manage. See Getting to the Database
Overview Page.

You are logged in to the system database (SYSTEMDB).

You have the system privilege DATABASE ADMIN or DATABASE START.

Context
For more information about how to start the whole system, see the sections on stopping and starting a database.

Procedure
1. At the top of the Database Overview page, click Database Management.

2. Click the Start button for the tenant you want to start.

Related Information
Start a Database
ALTER SYSTEM START DATABASE Statement (Tenant Database Management)
M_DATABASES System View
SAP HANA SQL Reference
Prevent the Start of a Tenant Database at System Startup

Delete a Tenant Database

You can delete tenant databases that are no longer required.

Prerequisites
You've navigated to the Database Overview page of the database you want to manage. See Getting to the Database
Overview Page.

You are logged in to the system database (SYSTEMDB).

You have the system privilege DATABASE ADMIN.

Context
If you delete a tenant database that is running SAP HANA 2.0 SPS 01 or later, you have the option to keep the backup
directories of the deleted tenant. Backups can then only be removed by deleting them from the le system. If you delete a
tenant database that is running an earlier version of SAP HANA, the backup directories are deleted automatically. It’s therefore
recommended that if you want to preserve these backup directories, you relocate them before deleting the database.

 Note
If a tenant SAP HANA database is enabled for usage with XS advanced and mapped to an organization/space in XS
advanced, then it is recommended not to use cockpit (or the SQL command line interface) to delete the tenant database but

This is custom documentation. For more information, please visit the SAP Help Portal 53
12/1/2023
to use the XS advanced xs command line interface. This is necessary so that XS advanced is aware that the tenant database
is no longer available. Note, too, that if you use the XS advanced xs CLI to delete a tenant database used by XS advanced, all
data in the tenant database is lost. See also 'Maintaining Tenant Databases in XS Advanced'.

Procedure
1. At the top of the Database Overview page, click Database Management.

2. Select the tenant to delete and click Stop.

Once stopped, its status changes to Stopped.

3. Click the  (Delete)icon for the tenant.

4. If this database is running SAP HANA 2.0 SPS 01 or later, choose whether to Keep Backup Directories or Delete
Directories and proceed with the database deletion, or Cancel the database deletion. If the database is running an
earlier version of SAP HANA, choose whether to Delete Tenant or Cancel the database deletion.

Results
The system commences the process to delete the database. Once deleted, the database disappears from the list. Volumes and
trace les are removed.

Next Steps
If you con gured the SAP Web Dispatcher to route HTTP requests to the deleted database, you need to update the
con guration.

Related Information
ALTER SYSTEM STOP DATABASE Statement (Tenant Database Management)
DROP DATABASE Statement (Tenant Database Management)
Execute SQL Statements in SAP HANA Studio
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic
SAP HANA SQL and System Views Reference
Start a Tenant Database
Maintaining Tenant Databases in XS Advanced

Disable Features on a Tenant Database

To safeguard and/or customize your system, certain features of the SAP HANA database can be disabled in tenant databases.
You can do this in the SAP HANA cockpit.

Prerequisites
The system database is registered in the SAP HANA cockpit.

You have the system privilege INIFILE ADMIN.

Context
Some features of the SAP HANA database are not required or desirable in certain environments, in particular features that
provide direct access to the le system, the network, or other resources. To maximize your control over the security of your

This is custom documentation. For more information, please visit the SAP Help Portal 54
12/1/2023
system, you can disable these features in tenant databases, for example import and export operations or the ability to back up
the database.

The system view M_CUSTOMIZABLE_FUNCTIONALITIES provides information about those features that can be disabled and
their status. This view exists in both the SYS schema of every database, where it contains database-speci c information, and in
the SYS_DATABASES schema of the system database, where it contains information about the enablement of features in all
databases.

For more information about the features that can be disabled and why, see Restricted Features in SAP HANA Tenant Databases
in the SAP HANA Security Guide .

You disable features in tenant databases in the customizable_functionalities section of the global.ini le.

 Note
All features are enabled in the system database and cannot be disabled.

Procedure
1. Determine which feature(s) you want to disable by referring to the view M_CUSTOMIZABLE_FUNCTIONALITIES (SYS) of
the system database.

2. On the Overview page of the system database in the SAP HANA cockpit, open Con guration of System Properties by
clicking the corresponding administration link.

3. Select the con guration le global.ini le and the section customizable_functionalities.

4. Add a new parameter for the feature that you want to disable:

a. Specify the database on which you want to blacklist the properties.

b. In the Key eld, enter the name of feature that you want to disable and set the value to false.

 Note
If you want to disable the feature on all tenant databases (including any that will be created in the future), enter
false as the system layer value.

5. Repeat for further features not required in the tenant database(s).

6. Restart the affected tenant database(s).

Results
The feature is disabled. You can verify this in the view M_CUSTOMIZABLE_FUNCTIONALITIES (SYS_DATABASES).

Tenant database administrators can see which features are enabled in their database using the view
M_CUSTOMIZABLE_FUNCTIONALITIES (SYS).

Related Information
Start a Tenant Database
System and Statistics Views
Restricted Features in Tenant Databases

Enable and Con gure Cross-Database Access

This is custom documentation. For more information, please visit the SAP Help Portal 55
12/1/2023
Read-only queries between tenant databases are supported but not enabled by default. You must rst enable this feature for
the system in the system database and then con gure which databases may communicate with one another. You can do this in
the SAP HANA cockpit.

Prerequisites
The system database is registered in the SAP HANA cockpit.

You have the system privilege INIFILE ADMIN.

Context
Every tenant database is self-contained with its own isolated set of database users and isolated database catalog. However, to
support for example cross-application reporting, cross-database SELECT queries are possible. This means that database
objects such as tables and views can be local to one database but be read by users from other databases in the same system.

So, for example, the following query would be possible:

SELECT *
FROM schema1.table1 AS tab1, db2.schema2.table2 as tab2
WHERE tab2.column2 = 'foobar'

For more information about which object types on remote databases can be accessed using this mechanism and which local
object types can access remote database objects, see Cross-Database Access.

To allow queries between databases, you must rst enable cross-database access and then specify which databases may
communicate with one other. You can do this by con guring the global.ini con guration le in the SAP HANA cockpit.

Procedure
1. On the Overview page of the system database in the SAP HANA cockpit, open Manage System Con guration.

2. Locate the parameter cross_database_access in the con guration le global.ini.

3. Choose Override Value to change the parameter value to true.

Alternatively, enable cross-database access by executing the following statement in the system database:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') set ('cross_database_access',

'enabled')='true' WITH RECONFIGURE;

4. Enable communication from one tenant database to one or more other tenant databases by executing the following
statement in the system database:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') set ('cross_database_access',

'targets_for_<source_db_name>')='<target_db1>[,<target_db2>...]' WITH RECONFIGURE;

 Example
You have two databases DB1 and DB2 and you want to be able to access DB1 from DB2. So you add the parameter
withtargets_for_DB2 the value DB1.

 Note
Cross-database access is con gured only in one direction. If in the above example you also want DB2 to be able to
access DB1, you would have to add the parameter targets_for_DB1 with the value DB2.

Results
This is custom documentation. For more information, please visit the SAP Help Portal 56
12/1/2023
Cross-database queries are now possible between the con gured databases.

Next Steps
Create remote identities for those users who require cross-database access. For more information, see Cross-Database
Authorization in Tenant Databases in the SAP HANA Security Guide .

In order for a user in one database to be able to run a query or create an object that references objects in another database,
the user must be mapped to a sufficiently privileged user in the remote database.

Related Information
Cross-Database Access
Troubleshooting Error Situations Related to Cross-Database Access
Cross-Database Authorization in Tenant Databases

Cross-Database Access
Read-only queries between tenant databases in the same SAP HANA system are possible. This supports cross-application
reporting. Cross-database access must be explicitly enabled.

Every tenant database is self-contained with its own isolated set of database users and isolated database catalog. However, to
support for example cross-application reporting, cross-database SELECT queries are possible. This means that database
objects such as tables and views can be local to one database but be read by users from other databases in the same system.

The following object types on remote databases can be accessed using cross-database access:

Schemas

Rowstore and columnstore tables (not including virtual tables)

SQL views (not including monitoring views)

Graphical calculation views

If they only use supported object types as data sources

If they don’t use procedure-based analytic privileges

Synonyms

The following object types on the local tenant database can access database objects on the remote tenant database:

SQL views

Scripted and graphical calculation views

Procedures

Synonyms

The SAP HANA modeler supports modeling of graphical calculation views using tables and other graphical calculation views as
data sources from different tenant databases. For more information, see Modeling Graphical Calculation Views With Tenant
Databases in the SAP HANA Modeling Guide (For SAP HANA Studio).

For more information about how to enable and con gure cross-database access, see Enable and Con gure Cross-Database
Access.

Related Information
This is custom documentation. For more information, please visit the SAP Help Portal 57
12/1/2023
Enable and Con gure Cross-Database Access
Cross-Database Authorization in Tenant Databases (SAP HANA Security Guide)
Troubleshooting Error Situations Related to Cross-Database Access
Workload Management and Cross-Database Queries
Modeling Graphical Calculation Views With Tenant Databases (SAP HANA Modeling Guide)
Import/Export Catalog Objects with Dependencies for Multi-TenantDB (SAP Community Blog)

Workload Management and Cross-Database Queries

Cross-database queries are executed on one or more databases. The workload management settings of the tenant database
executing the query or part of the query are applied.

To balance and manage different types of workload in SAP HANA (OLAP, OLTP, mixed, and internal), it is possible to classify
workloads based on user and application context information and apply resource limitations (for example, a statement memory
limit). Workload classes allow SAP HANA to in uence dynamic resource consumption at the session or statement level.

The execution of any plan operations of a cross-database query in a remote tenant database is subject to the resource
limitations of the workload classes and mappings de ned in the remote database. If multiple remote tenant databases are
involved in query execution, then different limitations may apply to different portions of the execution plan.

 Note
For cross-database queries workload classes in the remote tenant database is the only way of applying resource limitations;
in this case only the following set of workload class mapping properties is available:

APPLICATION USER NAME

CLIENT

APPLICATION COMPONENT NAME

APPLICATION COMPONENT TYPE

APPLICATION NAME

USER NAME

For cross-database queries it is not possible to control resource allocation by setting user parameters; normally, you can set
values for the parameters STATEMENT MEMORY LIMIT, STATEMENT THREAD LIMIT and PRIORITY on user level, but this is
not supported in this case. Also global ini le con gurations (statement memory limit, statement thread limit) are not
supported for cross-database queries.

For more information about workload management using workload classes and workload mappings, see Workload Management
in the SAP HANA Administration Guide .

Related Information
Workload Management
Managing Workload with Workload Classes

Troubleshooting Error Situations Related to Cross-Database

Access

This is custom documentation. For more information, please visit the SAP Help Portal 58
12/1/2023
If you are using cross-database access to query data from other tenant databases in your system, some error situations may
arise.

Situation 1
You are creating views, procedures, or synonyms to access objects on other tenant databases in the same system. After
dropping and re-creating an object on a remote tenant database, you can no longer access the view or procedure on the local
tenant database. You get error messages such as invalidated view or invalidated procedure. You also notice that
the IS_VALID column in the system views VIEWS and PROCEDURES do not accurately re ect the fact that the view or procedure
is invalid. In addition, there are entries missing in the OBJECT_DEPENDENCIES system view for the affected views, procedures,
or synonyms.

What's the problem?

Cross-database access supports only read-only operations. Changes to an object on one tenant database cannot therefore be
re ected accurately on other tenant databases that contain objects dependent on the changed object. This affects the validity
ag in the relevant system views, as well as the object dependencies. Remote objects may stay valid if they retain their internal
object identi er during re-creation and are re-created in an compatible way, but they will become invalid if their internal object
identi er changes.

What can I do?

You need to re-create the dependent object in the local tenant database in order for it to become valid again.

Situation 2
You are querying an SQL view or a calculation view on a remote tenant database and the view itself accesses objects on a third
tenant database (multi-level cross-database access). You are getting error messages such as
insufficient privilege: not authorized. Analytic privileges on the third tenant database may be evaluated based
on the wrong database user.

What's the problem?

Cross-database queries do not support multiple tenant database levels as part of a view hierarchy, even if communication
between databases is enabled (including the required authorized remote users).

What can I do?

This is custom documentation. For more information, please visit the SAP Help Portal 59
12/1/2023
Nothing. The feature is not supported.

Situation 3
Your system is running in high isolation mode. Queries that involve more than one remote tenant database run into timeouts.
You are getting error messages such as execution plan aborted or
current operation canceled by request and transaction rolled back. Accessing objects on remote tenant
databases individually works ne.

What's the problem?

The communication channels that are enabled for cross-database queries are applied in a strict fashion to the underlying
network channels as well. This means that one tenant database can only open a network connection to another tenant
database if communication between these two databases has been explicitly enabled. The execution plan for a query that
involves objects from multiple tenant databases could however lead to direct network connections between any of the tenant
databases, even if communication between them has not been explicitly enabled. This speci cally applies to joins between
tables on two different remote tenant databases.

What can I do?

You need to enable communication between all tenant database pairs that can potentially be involved in a query (including
authorized remote users). For more information about how to do this, see Enable and Con gure Cross-Database Access.

This is custom documentation. For more information, please visit the SAP Help Portal 60
12/1/2023

Related Information
Enable and Con gure Cross-Database Access

Prevent Changes to System Properties in Tenant Databases

To ensure the stability and performance of the overall system or for security reasons, you can prevent certain system properties
from being changed by tenant database administrators, for example, properties related to resource management. A
con guration change blacklist is available for this purpose. You con gure the blacklist in the SAP HANA cockpit.

Prerequisites
The system database is registered in the SAP HANA cockpit.

You have the system privileges INIFILE ADMIN.

Context
System con guration (*.ini) les have a database layer to facilitate the con guration of system properties for individual tenant
databases. However, it may be desirable to prevent changes to certain properties being made directly in tenant databases
because they could for example affect the performance of the system as a whole (CPU and memory management properties).

For this reason, a dedicated con guration change blacklist, multidb.ini, is available. This blacklist contains several critical
properties by default. You can customize the default con guration, as well as add further properties by editing the le in the
SAP HANA cockpit.

This is custom documentation. For more information, please visit the SAP Help Portal 61
12/1/2023

 Note
Properties in the blacklist can still be con gured at all levels in the system database. For more information about con guring
system properties, see Con guring SAP HANA System Properties (INI Files).

Procedure
1. On the Overview page of the system database in the SAP HANA cockpit, open Con guration of System Properties by
clicking the corresponding administration link.

2. Select the con guration le multidb.ini and the section readonly_parameters.

3. Add a new parameter to the blacklist:

a. Specify on which layer you want to blacklist the properties.

You can choose from the following layers:

Layer Result

System Con guration not possible in any tenant database.

Database Con guration not possible in the speci ed tenant

database(s)

 Note
Layered con guration is possible. A lower-layer con guration overrides a higher-layer con guration. This also
allows you to change the default con guration of the blacklist. The example below shows you how you could do
this.

b. In the Key eld, enter the ini le section that contains the properties you want to blacklist.

If the section exists in more than one con guration le, you can specify the exact con guration le by entering
<file>/<section>. If you do not specify a con guration le, the properties will be blacklisted in all les that
contain the section.

For example, to specify the communication section in all con guration les, enter communication. But to
specify the communication section in the xsengine.ini le only, enter xsengine.ini/communication.

c. In the Value eld, enter the properties that you want to blacklist.

If you want to add all the properties in the section, enter *. If you want to add all the properties in all sections of a
speci c le, enter <filename>/* (for example, xsengine.ini/*).

d. Choose OK.

e. Add further parameters as required.

Results
Tenant database administrators cannot change the properties in the con guration change blacklist. If they try, they will get the
error message: Change not allowed for tenant database. System administrators can still change the properties in
the system database in all layers.

Example: Layered Con guration

The property [sql] sql_executors is blacklisted for all tenant databases in all con guration les by default. You could
create a layered con guration for example as follows:

You change the sql entry at the system layer and enter plan_cache_size as the value. This overrides the default
con guration so that [sql] plan_cache_size is blacklisted instead of [sql] sql_executors.

This is custom documentation. For more information, please visit the SAP Help Portal 62
12/1/2023
You change the sql entry at the system layer and enter sql_executors and plan_cache_size as the value. This
overrides the default con guration so that both [sql] plan_cache_size and [sql] sql_executors are
blacklisted.

You add a new entry indexserver.ini/sql at the system layer with the value plan_cache_size as the value. This
adds a speci c con guration for the indexserver.ini le. Here, now only [sql] plan_cache_size is blacklisted.

Related Information
Con guring SAP HANA System Properties (INI Files)

Default Blocklisted System Properties in Tenant Databases

In systems that support tenant databases, there’s con guration change blocklist multidb.ini, which is delivered with a
default con guration.

The following table lists the system properties that are included in the multidb.ini le by default. So, tenant database
administrators can’t change these properties. System administrators can still change these properties in the system database
in all layers.

You can customize the default con guration change blocklist by changing existing entries in the multidb.ini le and adding
new ones. For more information about how to prevent changes to speci c system properties in tenant databases, see Prevent
Changes to System Properties in Tenant Databases in the SAP HANA Administration Guide .

File/Section Properties Description

auditing configuration default_audit_trail_type Prevents

con guration of
emergency_audit_trail_type audit trail
targets and the
alert_audit_trail_type
maximum audit
critical_audit_trail_type statement
length
audit_statement_length

auditing_csvtextfile max_file_size Prevents

con guration of
max_files the CSV text le
audit trail les

communication * Prevents
con guration of
default key and
trust stores, as
well as other
critical
communication
settings

global.ini/customizable_functionalities * Prevents
disabling of
restricted
features

global.ini/extended_storage * Prevents
con guration of
extended
storage (SAP

This is custom documentation. For more information, please visit the SAP Help Portal 63
12/1/2023

File/Section Properties Description

HANA dynamic
global.ini/persistence basepath_datavolumes_es
tiering)
basepath_logvolumes_es

basepath_databackup_es

basepath_logbackup_es

global.ini/system_replication keep_old_style_alert Prevents

con guration of
enable_full_sync certain system
replication
operation_mode
settings

global.ini/system_replication_communication *

global.ini/system_replication_hostname_resolution *

global.ini/xb_messaging * Prevents
con guration of
messaging

multidb.ini/readonly_parameters * Prevents
con guration of
the
multidb.ini
le itself

indexserver.ini/authentication SapLogonTicketTrustStore Prevents

con guration of
the trust store
for user
authentication
with
logon/assertion
tickets

memorymanager allocationlimit Prevents

con guration of
minallocationlimit memory
allocation
global_allocation_limit
parameters
async_free_threshold

async_free_target

execution max_concurrency Prevents

con guration of
session maximum_connections threading and
parallelization
maximum_external_connections
parameters
sql sql_executors

Related Information
Prevent Changes to System Properties in Tenant Databases
Unlock Blocklisted Parameters
Copy Blocklisted Parameters

This is custom documentation. For more information, please visit the SAP Help Portal 64
12/1/2023

Con gure HTTP(S) Access to Tenant Databases via SAP HANA

XS Classic
To enable Web-based applications to send HTTP(S) requests to tenant databases via the SAP HANA XS classic server, the
internal SAP Web Dispatcher must be con gured so it knows which requests to dispatch to which database on the basis of DNS
alias host names. You do this by specifying the public URL of every tenant database in the xsengine.ini con guration le.

Prerequisites
You are logged on to the system database.

You have the system privilege INIFILE ADMIN.

The network administrator has de ned an alias hostname in your organization's Domain Name System (DNS) for every
tenant database in the SAP HANA system. The alias hostname must refer to the hostname of the machine that is used
for HTTP(S) access to the tenant database.

You have a role based on the role template sap.hana.xs.wdisp.admin::WebDispatcherAdmin. This is required
to access the SAP HANA Web Dispatcher Administration tool for con guring HTTPS.

Context
The XS classic server allows Web-based applications to access SAP HANA via HTTP(S). The internal Web Dispatcher of the SAP
HANA system manages these incoming HTTP(S) requests. To allow applications to send requests to speci c databases, every
tenant database needs an alias host name. Requests to the alias host name can then be forwarded to the XS server of the
corresponding tenant database. Requests with the physical host name in the HTTP host header are forwarded to the XS server
running on the system database.

The default HTTP ports are used in all cases, that is, 80<instance> (HTTP) and 43<instance> (HTTPS). Alias host names are
mapped to internal HTTP(S) ports so that incoming requests can be routed to the correct database.

You con gure HTTP(S) access to tenant databases by specifying in the xsengine.ini le the URLs by which each tenant
database is publicly accessible. The system then automatically con gures the Web Dispatcher by generating the required pro le
entries in the webdispatcher.ini con guration le. It is not necessary to specify the URL of the system database, this is
done automatically.

 Note
This automatic con guration of the Web Dispatcher is controlled by the parameter [profile]
wdisp/system_auto_configuration in the webdispatcher.ini con guration le. If this parameter is set to false,
you need to con gure the webdispatcher.ini le manually.

For HTTPS access, you must subsequently con gure the required client certi cates and trust stores using the SAP Web
Dispatcher Administration tool. The following approaches are supported:

Using a single "wildcard" server certi cate in a single trust store that covers all databases in the system

Wildcard certi cates are more exible when tenant databases are frequently added and deleted. However, if you use a
wildcard certi cate, either the server requires its own sub-domain or you must ensure that the certi cate cannot be
abused from other servers.

 Caution
Do not use a wildcard server certi cate if strict isolation between tenant databases is required. If authentication
relies on a wildcard certi cate and a shared trust store, users of one tenant database will be able to log on to other
databases in the system.

This is custom documentation. For more information, please visit the SAP Help Portal 65
12/1/2023

Using individual certi cates in individual trust stores for each database

Individual certi cates for each database are more suitable in a at domain structure for individual servers. They also
ensure strict isolation between tenant databases. However, they involve more administrative effort to maintain.

Procedure
1. Specify the public URLs of all tenant databases in the xsengine.ini le in one of the following ways:

Option Description

SAP HANA studio a. Open the Administration editor and choose the Con guration
tab.

b. Navigate to the xsengine.ini le and expand the

public_urls section.

c. For each tenant database in the system, add the new

properties http_url and https_url at the database layer
and enter its public URL as the value:

http://<virtual_hostname>:80<instance>

https://<virtual_hostname>:43<instance>

 Note
The scheme (http/https) must be included in the URL.

SQL For each tenant database, execute the statements:

ALTER SYSTEM ALTER CONFIGURATION ('xsengine.ini',
'database', ' <tenant_DB_name>') SET ('public_urls',
'http_url') = 'http://<virtual_hostname>:80<instance>' WITH
RECONFIGURE;

ALTER SYSTEM ALTER CONFIGURATION ('xsengine.ini',

'database', ' <tenant_DB_name>) SET ('public_urls',
'https_url') = 'https://<virtual_hostname>:43 <instance>'
WITH RECONFIGURE;

 Note
The following values are set at the default layer and represent the URLs of the system database:

http://$(SAPLOCALHOST):80$(SAPSYSTEM)

https://$(SAPLOCALHOST):43$(SAPSYSTEM)

By default, the system database initially retrieves any request with the port 80<instance_no>. However, as soon as
you con gure the URLs of tenant databases, it is available under http://<localhost>:80<instance> only, and not the
fully quali ed domain name (FQDN). The local host is known to SAP HANA without the FQDN.

If you want to change this default behavior and con gure a different URL for the system database, you can do so by
executing the following statement:

ALTER SYSTEM ALTER CONFIGURATION ('nameserver.ini', 'system') SET('public_urls',

'http_url') = 'http://<virtual_hostname>:80<instance>' WITH RECONFIGURE;

New entries are now created in the webdispatcher.ini le at the host layer for every database. You can verify this
by executing the following statement (from the system database):

This is custom documentation. For more information, please visit the SAP Help Portal 66
12/1/2023
SELECT KEY, VALUE, LAYER_NAME FROM SYS.M_INIFILE_CONTENTS WHERE FILE_NAME =
'webdispatcher.ini' AND SECTION = 'profile' AND KEY LIKE 'wdisp/system%'

This returns the following result for example:

KEY | VALUE
wdisp/system_0 | GENERATED, SID=SYS, EXTSRV=http://localhost:30014, SRCVHOST='myhost'
wdisp/system_1 | GENERATED, SID=MYD, EXTSRV=http://localhost:30042, SRCVHOST='mydatabase.exam

2. Optional: Secure incoming communication by con guring HTTPS.

Option Description

Single a. Start the SAP HANA Web Dispatcher Administration tool at http://<localhost>:80<instance>/sap/hana/xs/wd
certi cate
b. For the default SAPSSLS.pse trust store, create a new SSL key pair and certi cate request:
for all
databases
i. From the main menu, choose SSL and Trust Con guration PSE Management .

ii. From the Manage PSE menu, choose SAPSSLS.pse.

iii. Choose Recreate PSE.

iv. Enter a distinguished name that matches the host name of all tenant databases.

 Example
Physical host name: myhost.example.com

Tenant host name 1: mydatabase1.example.com

Tenant host name 2: mydatabase2.example.com

In this case, you specify CN=*.example.com as the DN, thus creating a server certi cate that mat
the system database.

v. Choose Create.

vi. Create a certi cate request and submit to your certi cate authority (CA) for signing (Create CA Respo

c. Import the signed certi cate

For more information, see Con gure HTTPS (SSL) for Client Application Access.

This is custom documentation. For more information, please visit the SAP Help Portal 67
12/1/2023

Option Description

Individual a. Start the SAP HANA Web Dispatcher Administration tool at http://<localhost>:80<instance>/sap/hana/xs/wd
certi cates
b. For each tenant database and the system database, create a new trust store with a unique certi cate:
for each
database i. From the main menu, choose SSL and Trust Con guration PSE Management .

ii. On the PSE management screen, choose Create New PSE.

iii. Enter a le name for the new PSE.

 Example
example.pse

iv. Enter the distinguished name:

CN=<host name used for the tenant database in the public_urls section of

v. Choose Create.

vi. For the new PSE, create a certi cate request and submit to your CA for signing (Create CA Response)

vii. Import the signed certi cate into the new PSE (Import CA Response).

c. Con gure the Web Dispatcher to use multiple certi cates:

i. In the webdispatcher.ini le, create or change the parameter[profile] icm/ssl_config_0

ID=ssl_config_main, CRED=SAPSSLS.pse, SNI_CREDS=<semicolon (';') separate

files>

ii. Add ,SSLCONFIG=ssl_config_main to the value of the icm/server_port parameter for the HT
icm/server_port_1).

 Example
icm/server_port_1 = PROT=HTTPS,PORT=4443$(SAPSYSTEM),PROCTIMEOUT=600, SS

Results
You can access the XS server of tenant databases via the con gured URLs.

 Tip
If you experience slow response times when accessing the XS server of a tenant database (for example, Web-based
applications running on the tenant database), this indicates that the server is not able to resolve the host name correctly
using the DNS and retries repeatedly. If this is the case, contact your network administrator for a detailed problem analysis.

As a workaround, you can manually override virtual host name resolution on the machine where the browser is running by
modifying the /etc/hosts le on the local machine. In this le, append a new line, starting with the static IP address of the
server, followed by the virtual host name of your tenant database, for example, "10.20.30.40 mydatabase.example.com". To
edit this le you need admin or root privileges.

Next Steps
Optional: Enable access to Web-based applications from the SAP HANA studio.

This is custom documentation. For more information, please visit the SAP Help Portal 68
12/1/2023
Some Web-based tools are accessible from the SAP HANA studio, for example, the SAP HANA cockpit and SAP HANA Lifecycle
Management tool. If you want to be able to access these tools from a tenant database registered in the studio, you must
specify the alias hostname in the properties. You can do this as follows:

1. In the Systems view, right-click the tenant database and choose Properties.

2. Open the XS Properties page and enter the alias hostname in the XS Host eld.

Related Information
Con gure HTTPS (SSL) for Client Application Access
Using SAP Web Dispatcher for Load Balancing with Tenant Databases

Con gure Host-Independent Tenant Addresses

You can con gure the access to tenant databases to be independent of the SAP HANA system ID number by mapping additional
ports to a tenant database.

Context
The client connection to a tenant database is established over port 3<instance_no>13 of the system database. If a tenant
database is moved to another system, the instance number of the system and consequently the connection port will change. To
establish a connection independent of its current host, you can specify additional port numbers and map them to the tenants.

Con gure a connection that is independent of the actual host IP address by mapping an IP address to each tenant database at
operating system level. Add an additional port on which the system database listens for incoming connections. A client
connection is then established by calling the IP address of the tenant, the name of the tenant database and the additional listen
port.

 Sample Code

SERVERNODE=11.0.0.1:65001;UID=db1user;PWD=Aa123456;DATABASENAME=DB1

This is custom documentation. For more information, please visit the SAP Help Portal 69
12/1/2023
Once the tenant was moved to the target system, the additional listen port has to be removed on the source system and added
on the target system. The tenant-speci c IP address must be added for the target host at operating system level. A client
connection to the tenant database can still be established with the same information as before the move.

Procedure
Con gure additional ports on which the system database listens in addition to port 3<instance_no>13. Any available port
number except 0 is permitted.

You can do this by executing the following SQL statement:

ALTER SYSTEM ALTER CONFIGURATION ('nameserver.ini' , 'system') SET ('multidb' , 'listenports' ) = '

Next Steps
To remove all additional ports for a tenant database, execute the following SQL statement:

ALTER SYSTEM ALTER CONFIGURATION ('nameserver.ini' , 'system') UNSET ('multidb' , 'listenports' ) W

Related Information
Copying and Moving Tenant Databases

Reset the SYSTEM Password of a Tenant Using the Cockpit

If the password of the SYSTEM user in a tenant database is unknown, you can reset it from the system database.

Prerequisites
You've navigated to the Database Overview page of the database you want to manage. See Getting to the Database
Overview Page.

There’s no user available with the system privilege USER ADMIN that can reset the SYSTEM user password.

This is custom documentation. For more information, please visit the SAP Help Portal 70
12/1/2023

 Note
If you can log on as SYSTEM or another user with the system privilege USER ADMIN, don’t use the procedure
described here to change the password of the SYSTEM user. Instead, change the password using the User editor in
SAP HANA cockpit

You’re connected to the system database and have the system privilege DATABASE ADMIN.

Procedure
1. At the top of the Database Overview page, click Database Management.

2. Select the tenant and click Stop.

Once stopped, its status changes to Not running.

3. Click Tenant Actions and then Reset SYSTEM Password.

4. Enter and con rm a new temporary password for the SYSTEM user.

5. Select Reset Password & Restart.

Results
The password for the SYSTEM user is reset and the tenant database is restarted.

The next time you log on with the SYSTEM user, you will be prompted to change the password in line with the password
policy of the tenant database

If the SYSTEM user was previously deactivated, locked, or expired, it’s now activated again. In this case, we recommend
that you return it to its deactivated state.

If auditing is enabled, the password change is automatically logged in both the system and tenant database audit trails.

Related Information
Monitoring Tenant Databases in SAP HANA Cockpit
Resetting the SYSTEM User Password

Monitoring and Managing Tenant Databases

To ensure the overall performance and stability of an SAP HANA system, you as the system administrator can monitor all
tenant databases in the system using the system database. You also can perform administration tasks such as stopping and
starting tenant databases, or adding and removing services.

 Note
Administration of tenant databases is possible using the SAP HANA cockpit. However, command-line tools are required for
some tasks.

Support Model
The following is the general approach for analyzing and resolving issues in tenant databases:

1. Tenant database administrators analyze issues in their tenant databases using the available diagnosis and trace les.

2. If tenant database administrators discover issues that they cannot analyze using diagnosis and trace les, they contact
the system administrator.

This is custom documentation. For more information, please visit the SAP Help Portal 71
12/1/2023
3. The system administrator can rst check the health of the tenant database in the system database by analyzing the
monitoring data available in the SYS_DATABASES schema.

4. If the system administrator cannot see what the problem is from the system database, the tenant database
administrator needs to provide him with the necessary privileges to access the tenant database directly so that the
system administrator can analyze the issue there.

Related Information
Administration of Tenant Databases
Start a Tenant Database
Delete a Tenant Database
View Diagnosis Files of an Unavailable Tenant Database
Add Services in a Tenant Database

Monitoring Tenant Databases in SAP HANA Cockpit

As the tenant database administrator, you can monitor the availability, resource usage, and performance of tenant databases in
the SAP HANA cockpit from the system database.

Aggregate database information is available on the Database Overview page of the system database. Clicking the Database
Management link displays information about all databases in your system and allows you to monitor and administer your tenant
database. You can also create new tenant databases on this page. The system privilege DATABASE ADMIN is required to
perform operations on a tenant database.

Refer to the following sections of the SAP HANA cockpit documentation:

Database Details for an overview of the Manage Databases page which provides you with detailed information about all
databases.

Service Details for an overview of the Manage Services page which provides you with detailed information about
database services for an individual database.

Key Performance Indicators for an overview of the values tracked by the Performance Monitor to enable you to analyze
host-level and service-level performance of the SAP HANA database.

Alerts for details of monitoring alerts from the system database which occur in tenant databases.

Related Information
Using the Database Overview Page to Manage a Database
Database Details
Service Details
Key Performance Indicators
Monitor Alerts for a Tenant Database

Service Details
Manage Services provides you with detailed information about database services for an individual database.

 Note
Not all of the columns listed below are visible by default. You can add and remove columns in the Columns dialog, which you
open by clicking the  (Settings) icon in the table toolbar.

This is custom documentation. For more information, please visit the SAP Help Portal 72
12/1/2023
The following table lists the information available for services.

Column Description

Host Name of the host on which the service is running

Service Service name, for example, indexserver, nameserver, xsengine, and so on

Status The status of the service

The following statuses are possible:

Running

Running with Issues (where at least one service isn’t running, or there is at least one high
alert)

Starting

Stopping

Stopped

Not Running

To investigate why the service isn’t running, you can navigate to the crash dump le created
when the service stopped.

 Note
The crash dump le opens in the Trace tool of the SAP HANA Web-based Development
Workbench. To see this information, you need the role
sap.hana.xs.ide.roles::TraceViewer or the parent role
sap.hana.xs.ide.roles::Developer.

Role Role of the service in a failover situation

Automatic failover takes place when the service or the host on which the service is running fails.

The following values are possible:

Master

The service is the active master worker.

No entry

The service is a slave worker.

Standby

The service is in standby mode. It doesn’t contain any data and doesn’t receive any requests.

Port Port that the system uses for internal communication between services

Start Time Time at which the service started

 Note
The time is given in the timezone of the SAP HANA server.

Service Alerts Alerts triggered for the service.

Process ID Process ID

CPU Mini chart visualizing the CPU usage of the service

Clicking the mini chart opens the Performance Monitor for a more detailed breakdown of CPU
usage.

This is custom documentation. For more information, please visit the SAP Help Portal 73
12/1/2023

Column Description

Memory Mini chart visualizing the memory usage of the service

Dark green shows the service's used memory.

Light green shows the service's peak memory.

The gray stroke represents the effective allocation limit.

The light gray background represents the physical memory.

Clicking the mini chart opens the Memory Analysis app for a more detailed breakdown of memory
usage.

Used Memory (MB) Amount of memory currently used by the service

Clicking the mini chart opens the Memory Analysis app for a more detailed breakdown of memory
usage.

Peak Memory (MB) Highest amount of memory ever used by the service

Effective Allocation Limit (MB) Effective maximum memory pool size that is available to the process considering the current
memory pool sizes of other processes

Physical Memory on Host (MB) Total memory available on the host

All Process Memory on Host (MB) Total used physical memory and swap memory on the host

Allocated Heap Memory (MB) Heap part of the allocated memory pool

Allocated Shared Memory (MB) Shared memory part of the allocated memory pool

Allocation Limit (MB) Maximum size of allocated memory pool

CPU Process Usage (%) CPU usage of process

CPU Host (%) CPU usage on host

Virtual Memory on Host (MB) Virtual memory size on the host

Process Physical Memory (MB) Process physical memory used

Process Virtual Memory (MB) Process virtual memory

Shrinkable Size of Caches (MB) Memory that can actually be freed in the event of a memory shortage

Size of Caches (MB) Part of the allocated memory pool that can potentially be freed in the event of a memory shortage

Size of Shared Libraries (MB) Code size, including shared libraries

Size of Thread Stacks (MB) Size of service thread call stacks

Used Heap Memory (MB) Process heap memory used

Used Shared Memory (MB) Process shared memory used

SQL Port SQL port number

Action The available action for the service

Reset Memory Statistics Resets all memory statistics for all services.
Peak used memory is the highest recorded value for used memory since the last time the memory
statistics were reset. This value is useful for understanding the behavior of used memory over time
and under peak loads. Resetting peak used memory allows you, for example, to establish the impact
of a certain workload on memory usage. If you reset peak used memory and run the workload, then
you can then examine the new peak used memory value.

Go To Alerts Displays the alerts for this database.

This is custom documentation. For more information, please visit the SAP Help Portal 74
12/1/2023

Related Information
Memory Usage in the SAP HANA Database
Memory Analysis
The Performance Monitor
Monitoring Alerts

Alert Details
When you select an alert, detailed information about the alert is displayed on the right.

The following detailed information about an alert is available:

Detail Description

Category The category of the alert checker that issued the alert
Alert checkers are grouped into categories, for example, those related to memory usage
those related to transaction management and so on.

Source Where the alert came from, whether the database itself, or a service such as SAP
EarlyWatch Alert service.

Next Scheduled Run When the related alert checker is next scheduled to run
If the alert checker has been switched off (alert checker status Switched Off) or it failed
the last time it ran (alert checker status Failed), this eld is empty because the alert
checker is no longer scheduled.

Interval The frequency with which the related alert checker runs
If the alert checker has been switched off (alert checker status Switched Off) or it failed
the last time it ran (alert checker status Failed), this eld is empty because the alert
checker is no longer scheduled.

Alerting Host & Port Name and port of the host that issued the alert
In a system replication scenario, alerts issued by secondary system hosts can be
identi ed here. This allows you to ensure availability of secondary systems by addressing
issues before an actual failover.

For more information about monitoring secondary systems in SAP HANA, see Monitoring
Secondary Sites in the SAP HANA Administration Guide.

Alert Checker Name and description of the related alert checker

Proposed Solution Possible ways of resolving the problem identi ed in the alert, with a link to the supporting
app, if available

Past Occurrences of Alert Con gurable graphical display indicating how often the alert occurred in the past

Related Information
Monitoring Secondary Systems

Alert Priorities
The priority of an alert indicates the severity of the problem and how quickly action needs to be taken.

Priority Description

This is custom documentation. For more information, please visit the SAP Help Portal 75
12/1/2023

Priority Description

Information Action recommended to improve system performance or stability

Low Medium-term action required to mitigate the risk of downtime

Medium Short-term action required (few hours, days) to mitigate the risk of downtime

High Immediate action required to mitigate the risk of downtime, data loss, or data corruption

Alert Checker Details

When you select an alert checker Alert Con guration, detailed information about the alert checker and its con guration is
displayed on the right.

The following detailed information about an alert checker is available:

Detail Description

Header information The name of the alert checker, its status, and the last time it ran

Description Description of what the alert checker does, for example what performance indicator it
measures or what setting it veri es

Alert Checker ID The unique ID of the alert checker

Category The category of the alert checker

Alert checkers are grouped into categories, for example those related to memory usage,
those related to transaction management, and so on.

Threshold Values for Prioritized Alerting The values that trigger high, medium, low, and information alerts issued by the alert
checker
The threshold values and the unit depend on what the alert checker does. For example,
alert checker 2 measures what percentage of disk space is currently used so its thresholds
are percentage values.

 Note
Thresholds can be con gured for any alert checker that measures variable values that
should stay within certain ranges, for example, the percentage of physical memory
used or the age of the most recent data backup. Many alert checkers verify only
whether a certain situation exists or not. Threshold values cannot be con gured for
these alert checkers. For example, alert checker 4 detects services restarts. If a service
was restarted, an alert is issued.

Interval The frequency with which the alert checker runs

Schedule Active Indicator of whether the alert checker is running automatically at the con gured interval

Proposed Solution Possible ways of resolving the problem identi ed by the alert checker

Related Information
Alert Checker Statuses
Con gure Alert Thresholds

Alert Checker Statuses

This is custom documentation. For more information, please visit the SAP Help Portal 76
12/1/2023
The status of an alert checker indicates whether it is running on schedule, it has failed and been disabled by the system, or you
switched it off.

Status Description

Active The alert checker is running on schedule.

Failed The alert checker failed the last time it ran (for example due to a shortage of system
resources), so the system disabled it.
The alert checker remains disabled for a speci c length of time before it is automatically
re-enabled. This length of time is calculated based on the values in the following columns
of the table STATISTICS_SCHEDULE (_SYS_STATISTICS):

INTERVALLENGTH

SKIP_INTERVAL_ON_DISABLE

Once INTERVALLENGTH x SKIP_INTERVAL_ON_DISABLE has elapsed, the alert checker is

re-enabled. The default values for all alert checkers are such that failed checkers remain
disabled for 1 hour. The system determines the status of every alert checker and/or
whether the time to re-enablement has elapsed every 60 seconds.

You can also re-enable the alert checker manually by switching it back on in Alert
Con guration.

Switched Off You switched off the alert checker schedule.

If you want the alert checker to run again automatically, you must manually switch it back
on.

Related Information
Switch Alerts Off/On
Con gure Alert Thresholds

Default Blocklisted System Properties in Tenant Databases

In systems that support tenant databases, there’s con guration change blocklist multidb.ini, which is delivered with a
default con guration.

The following table lists the system properties that are included in the multidb.ini le by default. So, tenant database
administrators can’t change these properties. System administrators can still change these properties in the system database
in all layers.

You can customize the default con guration change blocklist by changing existing entries in the multidb.ini le and adding
new ones. For more information about how to prevent changes to speci c system properties in tenant databases, see Prevent
Changes to System Properties in Tenant Databases in the SAP HANA Administration Guide .

File/Section Properties Description

auditing configuration default_audit_trail_type Prevents

con guration of
emergency_audit_trail_type audit trail
targets and the
alert_audit_trail_type
maximum audit
critical_audit_trail_type statement
length
audit_statement_length

This is custom documentation. For more information, please visit the SAP Help Portal 77
12/1/2023

File/Section Properties Description

auditing_csvtextfile max_file_size Prevents

con guration of
max_files the CSV text le
audit trail les

communication * Prevents
con guration of
default key and
trust stores, as
well as other
critical
communication
settings

global.ini/customizable_functionalities * Prevents
disabling of
restricted
features

global.ini/extended_storage * Prevents
con guration of
global.ini/persistence basepath_datavolumes_es extended
storage (SAP
basepath_logvolumes_es
HANA dynamic
basepath_databackup_es tiering)

basepath_logbackup_es

global.ini/system_replication keep_old_style_alert Prevents

con guration of
enable_full_sync certain system
replication
operation_mode
settings

global.ini/system_replication_communication *

global.ini/system_replication_hostname_resolution *

global.ini/xb_messaging * Prevents
con guration of
messaging

multidb.ini/readonly_parameters * Prevents
con guration of
the
multidb.ini
le itself

indexserver.ini/authentication SapLogonTicketTrustStore Prevents

con guration of
the trust store
for user
authentication
with
logon/assertion
tickets

This is custom documentation. For more information, please visit the SAP Help Portal 78
12/1/2023

File/Section Properties Description

memorymanager allocationlimit Prevents

con guration of
minallocationlimit memory
allocation
global_allocation_limit
parameters
async_free_threshold

async_free_target

execution max_concurrency Prevents

con guration of
session maximum_connections threading and
parallelization
maximum_external_connections
parameters
sql sql_executors

Related Information
Prevent Changes to System Properties in Tenant Databases
Unlock Blocklisted Parameters
Copy Blocklisted Parameters

Unlock Blocklisted Parameters

Remove a parameter from the blocklist for a tenant database so that the parameter can be edited.

Prerequisites
You've navigated to the Database Overview page of the database you want to manage. See Getting to the Database
Overview Page.

You have the system privilege INIFILE ADMIN.

You are connected to the system database.

Context
By removing a parameter from the blocklist, you can enable it to be edited. However, you can remove only parameters that you
or other users have added to the blocklist—you can't remove parameters that are on the blocklist by default. Default
parameters are displayed without delete or edit controls on the Blocklisted Parameters for Tenants page.

Procedure
1. At the top of the Database Overview page, click Database Management.

2. On the Manage Databases screen, click (upper right).

To see the Manage Blocklisted Features button, you might need to widen the window or click the three dots in the upper
right corner of the screen. Manage Blocklisted Parameters

3. On the Blocklisted Parameters for Tenants page, the active tenant is highlighted in the left pane. Click the name of
another tenant to manage its parameters.

4. To remove a parameter to the blocklist, click the red X to the right of the parameter to be deleted and con rm the
deletion.
This is custom documentation. For more information, please visit the SAP Help Portal 79
12/1/2023
The cockpit displays the blocklist without the parameter you removed.

Related Information
Lock Parameters Against Editing for a Tenant Database

View Diagnosis Files of an Unavailable Tenant Database

If a tenant database is unavailable, for example because it's stopped or experiencing major performance problems, the tenant
database administrator can't access diagnosis les. In this case, you as the system administrator can access the diagnosis les
of the tenant database from the system database using the SAP HANA database explorer.

Procedure
Open the Host Diagnostic Files folder of your cockpit database, then click the diagnostic le that you want to examine to open it
in an editor. The Host Diagnostic Files folder contains all diagnostic les that have been con gured for the SAP Host Agent.

 Note
You cannot open binary trace les (marked with a binary icon) in the database explorer. You can only download binary trace
les.

For more information about con guring the SAP Host Agent, see the SAP Host Agent documentation.

The cockpit database must have valid SAP Control Credentials set in the cockpit. If the user has not set valid SAP Control
Credentials, then an error is returned.

The diagnosis les of the system database are displayed.

Next Steps
If more detailed diagnosis information is required (for example for SAP Support), you can trigger the collection of a full system
information dump for tenant databases. For more information, see Collecting Diagnosis Information for SAP Support in the SAP
HANA Administration Guide .

Related Information
Add a Database to the SAP HANA Database Explorer
View Diagnostic Files in the SAP HANA Database Explorer
SAP Host Agent

System and Statistics Views in Tenant Database Systems

Every database has its own SYS and _SYS_STATISTICS schemas that contain information about that database only. For system-
level monitoring, additional views are accessible in the system database: the M_DATABASES (SYS) view and the views in the
SYS_DATABASES schema.

M_DATABASES

This view is available in the SYS schema of the system database of a multiple-container system. It provides an overview
of all tenant databases in the system. Only users with the system privilege DATABASE ADMIN can see the contents of
this view.

This is custom documentation. For more information, please visit the SAP Help Portal 80
12/1/2023
SYS_DATABASES schema

The views in the SYS_DATABASES schema provide aggregated information from a subset of the views available in the
SYS and _SYS_STATISTICS schemas of all tenant databases in the system. These union views have the additional column
DATABASE_NAME to make it possible to identify from which database the information is coming refers. The system
views in the SYS_DATABASES schema are accessible only from the system database. To be able to view information in
these views, you need the system privilege DATABASE ADMIN or CATALOG READ.

Tools such as the SAP HANA cockpit use these views to support system-level monitoring.

System and Statistics Views

Memory and CPU Usage for Tenant Databases

Manage and control the memory and CPU usage of your system by con guring limits for individual tenant databases. If
necessary, you can also reserve memory for the system database.

Managing Resource Usage of Tenant Databases

Several system properties allow you to in uence the allocation of memory and CPU resources in SAP HANA systems. System
properties (INI) les have a database layer to facilitate the con guration of properties for individual tenant databases.

The following properties are useful for in uencing the resource consumption of tenant databases.

[memorymanager] allocationlimit in the global.ini le

Use this property to limit the maximum amount of memory (in MB) that can be allocated individually to processes of a
tenant database. Each process of a tenant database can allocate the speci ed value. Setting the allocation limit too low

This is custom documentation. For more information, please visit the SAP Help Portal 81
12/1/2023
can cause the tenant database to become inaccessible until more memory can be allocated.

 Example
Executed from the system database:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'DATABASE', 'MYDB')

SET ('memorymanager','allocationlimit') = '8192' WITH RECONFIGURE;

 Note
Memory alignment happens on the y and can therefore take some time. To make it happen immediately, you can
restart the database.

[execution] max_concurrency in the global.ini le

Use this property to in uence the maximum number of CPU cores that can be used for each tenant database by limiting
the number of concurrently running threads used by the JobExecutor subsystem. A reasonable default value is the
number of cores divided by the number of tenant databases. Don’t specify a value of 0. A change of this value takes
effect immediately.

 Example
Executed from the system database:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'DATABASE', 'MYDB')

SET ('execution', 'max_concurrency') = '4' WITH RECONFIGURE;

 Note
In NUMA architectures, setting the max_concurrency parameter isn’t enough to achieve the desired performance
gains, so also bind sockets that share memory using the affinity setting. For more information, see Controlling CPU
Consumption.

Managing Memory Usage of System Database

After installation, the system database contains only data required to monitor and manage the system, as well as statistics
data related to itself. The system has an average memory consumption of 15 GB.

If the system database is experiencing performance problems, for example, out-of-memory situations, you can reserve a
minimum amount of memory (MB) for the system database by con guring the parameter [multidb]
systemdb_reserved_memory in the global.ini le.

Related Information
Controlling Parallel Execution of SQL Statements
Con guring SAP HANA System Properties (INI Files)

Using SAP Web Dispatcher for Load Balancing with Tenant

Databases
If an SAP HANA system has multiple instances of SAP HANA extended services, classic model (SAP HANA XS classic) and is
distributed across multiple hosts, you can implement an external SAP Web Dispatcher to distribute the load of inbound HTTP
requests and to enure high availability.
This is custom documentation. For more information, please visit the SAP Help Portal 82
12/1/2023
The following section describes how to con gure an external SAP Web Dispatcher for SAP HANA systems with tenant
databases.

Before You Start

Note the following points:

The external SAP Web Dispatcher is a separate installation and does not form part of the SAP HANA system. It must
have a minimum version of 745 Patch Level 21.

An SAP Web Dispatcher process also runs on all SAP HANA hosts on which an instance of SAP HANA XS is active. This
internal SAP Web Dispatcher is a xed part of the SAP HANA system. In a system with tenant databases, this internal
SAP Web Dispatcher must also be con gured to enable HTTP access to individual databases. For more information, see
Con gure HTTP(S) Access to Tenant Databases.

All information and con guration steps described in SAP Note 1855097 are still valid. In particular, the parameter
wdisp/filter_xs_internal_uri has to be set to false in the webdispatcher.ini con guration le of your
SAP HANA system.

The con guration described in the following sections describes access to tenant databases. However, it is also valid for
the system database. For the Web Dispatcher, there is no difference between tenant databases and the system
database.

The SAP Web Dispatcher handles only HTTP(S) access to SAP HANA.

For more information about con guring secure HTTPS access, see Con gure HTTP(S) Access to Tenant Databases
(internal Web Dispatcher con guration) and Con guring SAP Web Dispatcher to Support SSL in the SAP HANA Web
Dispatcher documentation.

Related Information
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic
Con guring SAP Web Dispatcher to Support SSL
Virtual-Host-Based Routing
Con guring an External SAP Web Dispatcher for Tenant Databases

Virtual-Host-Based Routing
An example explains the basics of virtual-host-based routing.

The Website travelapp.com provides Web-based services for information about popular travel destinations. Services are
implemented as separate applications, which run on separate Web servers on one host (travelapp.com). Virtual host names
are used to distinguish between the available services: london.travelapp.com and paris.travelapp.com. Both virtual
host names are aliases for travelapp.com. This can be illustrated as follows:

This is custom documentation. For more information, please visit the SAP Help Portal 83
12/1/2023
Virtual-Host-Based Routing

John wants to read information about London. Therefore, he enters london.travelapp.com into his browser. As
london.travelapp.com is an alias for travelapp.com, the browser sends the HTTP request to travelapp.com, but it
uses london.travelapp.com as the host header of this request. The request arrives at a controller or dispatcher process on
travelapp.com. This dispatcher process decides whether to forward the request to the Web server responsible for displaying
information about London or the Web server responsible for displaying information about Paris. This decision is made based on
the host header, that is the host name that the user originally entered into the browser. london.travelapp.com is assigned
to the application for London and paris.travelapp.com is assigned to the application for Paris.

Jane requires information about Paris and enters paris.travelapp.com into her browser. This request also arrives at the
dispatcher process and is dispatched to the Paris application based on the host header of the request.

Load Balancing
travelapp.com has proved to be a successful service with many users. As a result, one host is no longer sufficient, and the
application has been installed on a second host. In addition, a load balancer is needed to distribute requests between the two
hosts. The aliases london.travelapp.com and paris.travelapp.com have to be changed to point to the host of the load
balancer to guarantee that all requests are handled by the load balancer (dmz.travelapp.com). This can be illustrated as
follows:

Virtual-Host-Based Routing with Load Balancing

John again wants to read information about London. Therefore, he enters london.travelapp.com into his browser. As
london.travelapp.com is an alias for dmz.travelapp.com, the browser sends the HTTP request to
dmz.travelapp.com, but it uses london.travelapp.com as the host header of this request. This request arrives at the
load balancer, which simply forwards the request to hosta.travelapp.com or hostb.travelapp.com based on the
current load. It must not change the host header of the request because this request is later necessary in the dispatcher. After
that, the dispatcher handles the request as if no load balancer is involved, regardless of the fact that the host name in the host
header actually points to another host.

SAP HANA Tenant Databases

Translated to the context of SAP HANA tenant databases, the load balancer is an external SAP Web Dispatcher, and the
dispatcher is the system-internal SAP Web Dispatcher, as illustrated in the following gure:

This is custom documentation. For more information, please visit the SAP Help Portal 84
12/1/2023

Virtual-Host-Based Routing for SAP HANA Tenant Databases

Con guring an External SAP Web Dispatcher for Tenant

Databases
Virtual host names for differentiated HTTP access to tenant databases are con gured in the system-internal SAP Web
Dispatcher. If you're using an external SAP Web Dispatcher for load balancing, you must also con gure the external Web
Dispatcher. Otherwise, information about the selected virtual hosts can't be transported to the SAP HANA system.

 Remember
All of the con guration settings mentioned here are done in the external Web Dispatcher and not in the internal Web
Dispatcher that is part of the SAP HANA system. The external Web Dispatcher is a separate installation and does not form
part of the SAP HANA system. Before you can con gure the external Web Dispatcher, the internal Web Dispatcher must
already have been con gured to enable HTTP access to individual databases. For more information, see Con gure HTTP(S)
Access to Tenant Databases.

Single Versus Multiple Tenant Access via External Web Dispatcher

Every tenant database that needs to be accessed through the external Web Dispatcher requires a wdisp/system_<XX>
parameter entry in the external Web Dispatcher pro le (sapwebdisp.pfl). The XSSRV subparameter speci es the XS server
to connect to, and the XSVHOST subparameter speci es the virtual host name of the tenant database.

 Example
wdisp/system_<xx> = SID=<3-digit ID>, XSSRV=http://<physical host name of SAP HANA server>:<p

 Note
Virtual host names are con gured in the public_urls section of the xsengine.ini con guration le (or in
webdispatcher.ini). The is part of the internal Web Dispatcher con guration. For more information, see Con gure
HTTP(S) Access to Tenant Databases.

If only one tenant database needs to be accessed through the external Web Dispatcher, a single wdisp/system_<XX> entry
for the tenant database with the above con guration is sufficient, as depicted in the following gure:

This is custom documentation. For more information, please visit the SAP Help Portal 85
12/1/2023

 Note
The gure shows a simpli ed depiction of the Web Dispatcher pro le (sapwebdisp.pfl). In the real con guration, the
XSSRV subparameter requires port numbers, and line breaks are not allowed.

Access to a Single Tenant Database

 Note
An external Web Dispatcher is not mandatory to access a single tenant. But there are scenarios in which an external Web
Dispatcher is required, for example sophisticated applications (for example, some SAP Fiori scenarios) or for security
purposes. For more information, see the relevant application documentation and the SAP Web Dispatcher documentation.

Virtual hosts names are used to con gure tenant differentiation. Two scenarios are possible:

Option 1: Tenant databases are accessed via HTTP through the external Web Dispatcher only; there is no direct HTTP
access to the tenant databases (recommended)

Option 2: Tenants databases are accessed via HTTP both through the external Web Dispatcher and directly, bypassing
the external Web Dispatcher

This con guration requires additional virtual host names and is more complex than option 1. However, this option is
useful if the external Web Dispatcher is being added to an existing landscape.

Related Information
SAP Web Dispatcher Documentation on SAP Help Portal
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic
Option 1: Con guring Access to Multiple (or All) Tenant Databases Through External Web Dispatcher Only
Option 2: Con guring Access to Multiple (or All) Tenant Databases Through External Web Dispatcher and Directly

Option 1: Con guring Access to Multiple (or All) Tenant

Databases Through External Web Dispatcher Only
Use this con guration if you want tenant databases to be accessed through the external Web Dispatcher only. With this
con guration, there is no direct HTTP access to the tenant databases.

The main part of this con guration involves setting the virtual host names of tenant databases con gured in the external Web
Dispatcher pro le to point to the host of the external Web Dispatcher, instead of the host of the SAP HANA system. As a result,
all requests to the virtual host name of a tenant database rst go to the external Web Dispatcher and are then forwarded to
the internal Web Dispatcher in the SAP HANA system.

This is custom documentation. For more information, please visit the SAP Help Portal 86
12/1/2023

 Remember
Before you can con gure the external Web Dispatcher, the internal Web Dispatcher must already have been con gured to
enable HTTP access to individual databases. For more information, see Con gure HTTP(S) Access to Tenant Databases.

Single-Host Systems
The wdisp/system_<xx> entry for each tenant database is con gured in the external Web Dispatcher pro le as follows:

XSSRV speci es the actual physical SAP HANA host name and port to which to requests are sent.

XSVHOST speci es the virtual host name of the tenant database to which requests are sent.

 Note
If a tenant database has multiple virtual host names assigned, only one needs to be entered in XSVHOST.

SRCVHOST speci es the virtual host name that is used to map incoming HTTP requests to the wdisp/system entry
that represents a particular tenant.

 Note
With this con guration option, XSVHOST and SRCVHOST are always identical.

The following gure depicts this con guration in a single-host system:

Access to Multiple Tenant Databases (Single Host)

 Note
The gure shows a simpli ed depiction of the Web Dispatcher pro le (sapwebdisp.pfl). In the real con guration, the
XSSRV subparameter requires port numbers, and line breaks are not allowed.

In the example depicted above, what happens when the user enters london.example.com into her browser?

1. The browser opens a TCP/IP connection to webdispatcher.example.com because london.example.com is only

an alias name for webdispatcher.example.com.

2. The browser sends an HTTP request over this connection. The host header of this HTTP request is
london.example.com, which is the URL that the user entered.
This is custom documentation. For more information, please visit the SAP Help Portal 87
12/1/2023
3. The external Web Dispatcher receives the HTTP request, checks the host header and uses this to map the request to a
wdisp/system entry. As london.example.com is the SRCVHOST value for wdisp/system_0, the request is
associated with wdisp/system_0.

4. The external Web Dispatcher opens a TCP/IP connection to the XSSRV value of wdisp/system_0
(hdb.example.com).

5. The external Web Dispatcher sets the destination of the request to the tenant database speci ed in the XSVHOST
subparameter of wdisp/system_0 (london.example.com) by injecting a proprietary HTTP header into the request.

6. The internal SAP HANA Web Dispatcher receives the request. Because of the injected HTTP header eld, it identi es
that the request is destined for tenant database 1 and forwards it to the XS server of tenant database 1.

Multiple-Host Systems
In a multiple-host system, the external Web Dispatcher must be con gured to connect to all hosts. This means that all hosts
with a running XS server (or that may have an XS server in the future) have to be entered as the value for XSSRV as a semi-
colon (;) separated list. Even if a tenant database is not running on a host, you should add the host to the list anyway. This will
enable the smooth moving of tenant databases without the need to change the external Web Dispatcher con guration.

 Remember
In the internal Web Dispatcher con guration, the virtual host name in the XSVHOST subparameter must be to assigned to
the tenant database on all hosts.

The following gure depicts the con guration in a multiple-host system:

 Note
The gure shows a simpli ed depiction of the Web Dispatcher pro le (sapwebdisp.pfl). In the real con guration, the
XSSRV subparameter requires port numbers, and line breaks are not allowed.

Access to Multiple Tenant Databases (Multiple Hosts)

Now what happens when the user enters london.example.com into her browser?

This is custom documentation. For more information, please visit the SAP Help Portal 88
12/1/2023
The process is identical to the single-host scenario with one exception: The external Web Dispatcher periodically checks which
host(s) a tenant database is actually running on. If a tenant database is running on multiple hosts, the external Web Dispatcher
performs load balancing between these hosts.

Related Information
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic

Option 2: Con guring Access to Multiple (or All) Tenant

Databases Through External Web Dispatcher and Directly
Use this con guration if you want tenant databases to be accessed both through the external Web Dispatcher and directly,
bypassing the external Web Dispatcher.

With this con guration, additional virtual host names are required for each tenant database. These virtual host names point to
the physical host name of the external Web Dispatcher. The virtual host names that are assigned to the tenant databases still
point to the host of the SAP HANA system.

 Remember
Before you can con gure the external Web Dispatcher, the internal Web Dispatcher must already have been con gured to
enable HTTP access to individual databases. For more information, see Con gure HTTP(S) Access to Tenant Databases.

Single-Host Systems
The wdisp/system_<xx> entry for each tenant database is then con gured in the external Web Dispatcher pro le as follows:

XSSRV speci es the actual physical host name and port to which to requests are sent.

XSVHOST speci es the virtual host name of the tenant database to which requests are sent.

 Note
If a tenant database has multiple virtual host names assigned, only one needs to be entered in XSVHOST.

SRCVHOST speci es the virtual host name that is used to map incoming HTTP requests to the wdisp/system_<xx>
that represents a particular tenant.

The following gure depicts this con guration in a single-host system:

This is custom documentation. For more information, please visit the SAP Help Portal 89
12/1/2023

Access to Multiple Tenant Databases in Single-Host System

 Note
The gure shows a simpli ed depiction of the Web Dispatcher pro le (sapwebdisp.pfl). In the real con guration, the
XSSRV subparameter requires port numbers, and line breaks are not allowed.

In the example depicted above, what happens when the user enters uk.example.com into his browser?

1. The browser opens a TCP/IP connection to webdispatcher.example.com because uk.example.com is only an alias
name for webdispatcher.example.com.

2. The browser sends an HTTP request over this connection. The host header of this HTTP request is uk.example.com,
which is the URL that the user entered.

3. The external Web Dispatcher receives the HTTP request, checks the host header and uses it to map the request to a
wdisp/system entry. As uk.example.com is the SRCVHOST value for wdisp/system_0, the request is associated
with wdisp/system_0.

4. The external Web Dispatcher opens a TCP/IP connection to the XSSRV value of wdisp/system_0
(hdb.example.com).

5. The external Web Dispatcher sets the destination of the request to the tenant database speci ed in the XSVHOST
parameter of wdisp/system_0 (london.example.com) by injecting a proprietary HTTP header into the request.

6. The internal SAP HANA Web Dispatcher receives the request. Because of the injected HTTP header eld, it identi es
that the request is destined for tenant database 1 and forwards it to the XS server of tenant database 1.

Multiple-Host Systems
In a multiple-host system, the external Web Dispatcher must be con gured to connect to all hosts. This means that all hosts
with a running XS server (or that may have an XS server in the future) have to be entered as the value for XSSRV as a semi-
colon (;) separated list. Even if a tenant database is not running on a host, you should add the host to the list anyway. This will
enable the smooth moving of tenant databases without the need to change the external Web Dispatcher con guration.

 Remember
In the internal Web Dispatcher con guration, the virtual host name in the XSVHOST subparameter must be to assigned to
the tenant on all hosts.

The following gure depicts the con guration in a multiple-host system:

This is custom documentation. For more information, please visit the SAP Help Portal 90
12/1/2023

 Note
The gure shows a simpli ed depiction of the Web Dispatcher pro le (sapwebdisp.pfl). In the real con guration, the
XSSRV subparameter requires port numbers, and line breaks are not allowed.

Access to Multiple Tenant Databases in Multiple-Host System

What happens after the user enters uk.example.com into his browser?

The process is identical to the single-host scenario with one exception: The external Web Dispatcher periodically checks on
which host(s) a tenant database is actually running. If a tenant database is running on multiple hosts, the external Web
Dispatcher performs load balancing between these hosts.

Related Information
Con gure HTTP(S) Access to Tenant Databases via SAP HANA XS Classic

Copying and Moving Tenant Databases

Using SAP HANA system replication mechanisms, SAP HANA tenant databases can be copied and moved securely and
conveniently from one SAP HANA system to another with near-zero downtime. This allows you to respond exibly to changing
resource requirements and to manage your system landscape efficiently.

The following sections provide an overview of copying or moving a tenant database using system replication.

Process Overview

Use Cases

Which Data Is Copied or Moved?

Recoverability After Copy or Move

This is custom documentation. For more information, please visit the SAP Help Portal 91
12/1/2023
Client Communication After Move

Prerequisites and Implementation Considerations

Other Copy and Move Methods

Process Overview
Copying and moving a tenant database are essentially the same process. First, the tenant database is copied through the
replication of all of its data to a newly created tenant database in a target system:

Once all data has been successfully transferred, the new tenant database is started as a separate, independent database:

If the aim is to move the tenant database to the new system, the original tenant database is deleted and the new tenant
database takes over:

This is custom documentation. For more information, please visit the SAP Help Portal 92
12/1/2023

The only difference between copying and moving a tenant database therefore is what happens to the original tenant database
after all data has been transferred to the new tenant database in the target system.

In both cases, the new tenant database starts running as a fully separate, independent database.

Several tenant databases can be copied or moved to a system at the same time. It is also possible to copy or move a tenant
database to a system with a different isolation level than the source system.

You can also use this mechanism to create a copy of a tenant database on the same host or to copy/move a tenant database to
another host that is part of the same system.

Use Cases
Copying and moving a tenant database from one system to another in this way has several applications, including:

Load balancing between systems

For example, a tenant database is running a more demanding workload than anticipated, so you move it to a system
running on a host with more CPU resources.

Management of deployment environment

For example, you want to copy a tenant database running in your test system to the live production system.

Tenant-database-speci c upgrades

For example, you want to upgrade a single tenant database but not the entire system, so you move the tenant database
to a system already running the higher version.

Template databases

For example, you create a tenant database with a default con guration that you want to reuse as the basis for new
tenant databases in other systems. You can simply copy the tenant database as a template to other systems.

Which Data Is Copied or Moved?

When a tenant database is copied or moved, data is replicated from the original tenant database to the new tenant database in
the target system.

The following table indicates which types of data are replicated and which are not.

Type of Data Replicated?

Data and logs of the tenant database Yes

This is custom documentation. For more information, please visit the SAP Help Portal 93
12/1/2023

Type of Data Replicated?

Trace and log les No

Data backups No

Con guration (*.ini) les with tenant-database-speci c values No

This refers to les in the directory
$DIR_INSTANCE/../SYS/global/hdb/custom/config/<database_name>

Certi cates and certi cate collections stored in the tenant database Yes
This refers to the digital certi cates and certi cate stores used for certi cate-based user authentication and
secure communication between SAP HANA and JDBC/ODBC clients.

 Note
If these certi cates are stored in the le system in personal security environments (PSEs), they will not be
replicated. To ensure that they are replicated, migrate the le-system-based PSEs to in-database
certi cate collections before copying or moving the tenant database. For more information about how to do
this, see SAP Note 2175664.

Encryption root keys (for data and log volume encryption, backup encryption and the internal data encryption Copy: No
service)
Move: Partially
 Note
The root key used for data volume encryption is not replicated during the move process.

Key management con gurations if the local secure store (LSS) is used with an external key management Yes
system (KMS)

Application function libraries No

Recoverability After Copy or Move

When you copy a tenant database, the new tenant database does not have a backup history and cannot be recovered
immediately after being copied. For this reason, it is important to perform a full data backup after you copy.

When you move a tenant database, the backup history of the original tenant database is retained in the new tenant database.
As long as data and log backups of the source system are at a location accessible to the target system, the new tenant
database is recoverable immediately after the move.

 Caution
If you subsequently create a tenant database in the source system with the same name as the moved tenant database, the
backup les of the original database are overwritten.

Client Communication After Move

We recommend that you do not specify physical host names in the SQL client connect string. Otherwise, you would have to
recon gure all of your applications after a move. Instead, con gure virtual host names or virtual IP addresses. For more
information on virtual IP addresses, see Con gure Host-Independent Tenant Addresses.

Prerequisites and Implementation Considerations

The copy and move process involves the creation of a new tenant database in the target system. Therefore, the target
tenant database must not already exist in the target system.

The target system must have a software version equal to or higher than the source system.

This is custom documentation. For more information, please visit the SAP Help Portal 94
12/1/2023
If the source system is using the LSS in conjunction with an external KMS, then the target system must also use the LSS
and a key management con guration ID (other than DEFAULT) must be provided to initiate the copy or move. Only a key
administrator (user with ENCRYPTION ROOT KEY ADMIN) system privilege can obtain this information from the
system view SYS.KEY_MANAGEMENT_CONFIGURATIONS. The key administrator may add a dedicated con guration for
the target system in the source system before the copy or move.

If the source system is not using the LSS with a KMS, then the target system may use either the LSS or the SSFS secure
store in the system. For more information, see Server-Side Secure Stores and Using the LSS with an External Key
Management System.

If data volume encryption is enabled in the original system, data is decrypted before replication and then re-encrypted
(with a new root key) in the new database. However, during the copy and move process, data must be replicated via a
secure (SSL/TLS) network connection by default.

In a running system replication, it is possible to copy or move tenant databases into a primary system or from a primary
system into another target system different than the secondary system.

There can be no changes to the topology of the original tenant database while the move or copy is in progress. In other
words, until the copy or move has been nalized, it is not possible to add services to or remove services from the source
tenant database.

If the source system is con gured for host auto-failover, the copy or move process will fail in the event of failover to a
standby host. If this happens, the simple solution is to delete the new tenant database on the target system, which will
interrupt and clean up the copy or move process on the source and target side. Afterwards, the copy or move process
has to be restarted. Alternatively, if restarting the process is not feasible, altering the network settings to make the
standby host accessible through the same IP address as the failed host will resume the copy or move process.

The following components must not be con gured in the source tenant database:

Rserve server

SAP HANA dynamic tiering (extended storage server)

SAP HANA accelerator for SAP ASE (extended transaction service)

SAP HANA streaming analytics (streaming host)

Other Copy and Move Methods

Backup and Recovery

It is possible to use backup and recovery to copy or move tenant databases between two systems. However, we recommend
using SAP HANA system replication as described here. The main advantage of using system replication over backup and
recovery is the absence of downtime. Using backup and recovery, you would have to shut down the original database after
backing it up until the new database is successfully recovered. This is particularly critical if you are moving a tenant database.
System replication is also a more convenient method because you don’t need to move les between the different systems.

To copy or move a tenant database within the same system, we recommend using backup and recovery.

SAP HANA Database Lifecycle Manager (HDBLCM)

To copy or clone an entire system, use the SAP HANA database lifecycle manager (HDBLCM) as described in the SAP HANA
Platform Lifecycle Management section of the SAP HANA Administration Guide .

Related Information
SAP Note 2175664
Security of the Copy and Move Process
Copy and Move Process
Copy or Clone an SAP HANA System
Default Host Names and Virtual Host Names
Host Name Resolution for SQL Client Communication
Con gure Host-Independent Tenant Addresses

This is custom documentation. For more information, please visit the SAP Help Portal 95
12/1/2023
Connections for Tenant Databases
Server-Side Secure Stores
Using the LSS with an External Key Management System

Copy and Move Process

Understand the stages and steps involved in copying and moving a tenant database from a source system to a target system
using SAP HANA system replication.

Overview
The process of copying or moving a tenant database is driven entirely by the target system.

The following gure shows the stages involved, as well as who performs the individual steps in each stage: the system
administrator or the target system. Each step is then described in more detail.

Tenant Move/Copy Process Flow

Prepare

Who? Does What? Where?

System administrator Veri es that TLS/SSL is enabled on internal communication System database of source and
channels target system

This is custom documentation. For more information, please visit the SAP Help Portal 96
12/1/2023

Who? Does What? Where?

Con gures secure connection from target system to source system System database of target
by: system
1. Creating a certi cate collection with the purpose
DATABASE REPLICATION and adding the root certi cate
of the source system to the new collection

This will allow trust to be established between the system

databases of the target and source system for external
communication via SQL.

2. Creating a credential in the target system to enable

authenticated access from the target system to the source
system

Opens communication from the target system to the source system System database of source
by enabling source system services to listen on all network system
interfaces

Creates a credential to enable authenticated access to the source System database of target
system for the purpose of copying or moving a tenant database system

If necessary, obtains a valid key management con guration ID System database of source
(other than DEFAULT) from the key administrator (that is a user system
with system privilege ENCRYPTION ROOT KEY ADMIN).

The key administrator may create a dedicated con guration for the
new database in the source system before the copy or move and
provide the ID of this con guration to the system administrator.

 Note
This step is only relevant if the local secure store (LSS) is being
used in conjunction with an external key management system
(KMS).

System administrator Backs up the source tenant database System database of source
system

For more information, see Preparing to Copy or Move a Tenant Database .

Copy and Move

Who? Does What? Where?

System administrator Triggers the creation of the tenant database as a replica of the System database of target
source tenant database by executing the SQL statement CREATE system
DATABASE AS REPLICA

System database of target Establishes a secure connection to the system database using the From target system to source
system stored credentials created above system
For subsequent secure communication between the systems, a set
of public and private key pairs and public-key certi cates is
generated in the source system database. These will be used to
secure communication from the target system database to the
source system database, and from the target tenant database to
the source tenant database.

The generated key pairs and certi cates are imported into two
newly created certi cate collections in the target system database.

This is custom documentation. For more information, please visit the SAP Help Portal 97
12/1/2023

Who? Does What? Where?

Creates a new tenant database with the same topology as the Target system
tenant database in the source system

Initiates replication of data between the services in the source From source tenant database to
tenant database and the corresponding services in the target target tenant database
database

System administrator Monitors the progress of data replication in system view System database of target
SYS_DATABASES.M_DATABASE_REPLICAS system or source system

Once the replication status is ACTIVE (indicating that all data has System database of the target
been transferred), commits the copy by executing the SQL system
statement ALTER DATABASE FINALIZE REPLICA

In the case of a move, the administrator indicates that the source

tenant database is to be dropped: DROP SOURCE DATABASE.

For more information, see Copy a Tenant Database to Another System and Move a Tenant Database to Another System.

Finalize

Who? Does What? Where?

System database in target Starts the target tenant database Target system
system
If the source tenant database is being moved to the target system, Source system
stops and drops the source tenant database

Performs clean-up operations: Source system and tenant

Deletes any cross-database dependencies to the original database in target system
tenant database in other tenant databases of the source
system (move only)

Deletes any remote identity dependencies of users in the

new tenant database in the target tenant database (copy
and move)

Generates a new root key used for data volume encryption

and re-encrypts data if data volume encryption is enabled
(copy and move)

System administrator Performs manual post-copy or post-move steps: System database of the target
Back up the target tenant database system

This is only necessary after a copy since the new tenant

database does not have a backup history and cannot be
recovered. After a move, the new tenant database has the
backup history of the original tenant database and can be
recovered if data and log backups of the source system are
at a location accessible to the target system.

Reverse preparatory steps required to secure the copy

process

If necessary, recon gure parameters in *.ini les with

tenant-database-speci c values

If necessary, recon gure cross-database access

This is custom documentation. For more information, please visit the SAP Help Portal 98
12/1/2023

Who? Does What? Where?

Key administrator If necessary, changes the key management con guration. System database of the target
system
 Note
This step is only relevant if the local secure store (LSS) is being
used in conjunction with an external key management system
(KMS).

Cancel

Who? Does What? Where?

System administrator Cancels the creation of the tenant database as a replica of the System database of target
source tenant database by executing the SQL statement DROP system
DATABASE <database_name>

System database of target Drops the target tenant database Target system
system
Performs clean-up operations Target system

Related Information
Security of the Copy and Move Process
Preparing to Copy or Move a Tenant Database
Copy a Tenant Database to Another System
Move a Tenant Database to Another System
Create and Manage a Key Management Con guration

Security of the Copy and Move Process

Copying or moving a tenant database from one system to another is a secure end-to-end process.

Secure Network Communication

The copy and move process ensures end-to-end data encryption and host authentication on the basis of X.509 client
certi cates. Dedicated certi cates and trust stores (referred to as certi cate collections) are created as part of the copy or
move process for the purpose of that speci c copy or move. Certi cates and certi cate collections are stored directly in the
system databases as database objects.

 Note
If secure network communication is not required, it can be disabled. As a result, a copy or move of a tenant database can be
initiated without the exchange of certi cates. For more information, see Disable Secure Network Communication.

For more information about in-database certi cate management, see the SAP HANA Security Guide .

Authorization and Authentication

The copy and move process is triggered from the system database of the target system by a system administrator. To be able
to execute the copy or move statements, the administrator user requires the system privilege DATABASE ADMIN.

This is custom documentation. For more information, please visit the SAP Help Portal 99
12/1/2023
To be able to establish a connection to the system database of the source system, the target system must be authenticated on
the source system. This is achieved through the creation of a credential in the secure internal credential store of the system
database of the target system. The required credential must be created manually by an administrator in the system database
of the target system before the copy or move is started. For more information about the secure internal credential store, see
the SAP HANA Security Guide .

Encryption Key Handling

To protect data saved to disk from unauthorized access at operating system level, the SAP HANA database supports data
encryption in the persistence layer for data and log volumes, and data and log backups. An internal data encryption service is
also available to applications requiring data encryption. The instance secure store in the le system (SSFS) or the local secure
store (LSS) is used to protect the root keys for these encryption services.

When a tenant database is copied, all encryption root keys in the tenant database in the target system are different to those in
the tenant database of the source system.

When a tenant database is moved, all encryption root keys in the tenant database in the target system – with the exception of
the root key used for data volume encryption – are the same as those in the source tenant database.

If the source system is using the LSS to protect root keys and the LSS is connected to an external key management system,
then the target system must also use the LSS and the con guration ID of a key management con guration must be provided to
initiate the copy or move process. Only the key administrator in the source system (user with ENCRYPTION ROOT KEY ADMIN
system privilege) can obtain this information from the system view SYS.KEY_MANAGEMENT_CONFIGURATIONS. This key
management con guration is replicated to the target system and is initially used in the copied or moved database. The key
administrator of the source system may prepare a dedicated con guration for the new database before the copy or move, or
the key administrator of the target system can change the replicated con guration after the copy or move.

Cross-Database Dependencies
If cross-database access is enabled in the original tenant database, some con gured dependencies are automatically deleted to
ensure no unauthorized communication paths or user mappings can be exploited in the copied or moved tenant database.

Permitted Communication Paths

Part of the con guration of cross-database access involves specifying which tenant databases may communicate with each
other and in which direction.

After a tenant database is moved to another system, it is deleted in the source system. However, communication paths
referencing it will still exist in one or more of the other tenant databases in the source system. When the move operation is
nalized, all such references to the original database are automatically deleted in other tenant databases of the source
system.

Communication paths con gured in the tenant database in the target system must manually be recon gured after a move or
copy.

User Mappings

Another aspect of cross-database access con guration is the mapping of users in one tenant database to users in another
tenant database using remote identities.

After a tenant database is moved or copied to another system, some of its database users may still be associated as remote
identities for users in other databases in the source system. When the move or copy operation is nalized, all remote identity
information of users in the new tenant database is automatically deleted.

This is custom documentation. For more information, please visit the SAP Help Portal 100
12/1/2023
New user mappings must be manually con gured in the tenant database in the target system.

Related Information
Disable Secure Network Communication
Using the LSS with an External Key Management System

Disable Secure Network Communication

During the copy and move process, data is replicated via a secure (TLS/SSL) network connection by default. If this is not
necessary in your scenario, you can disable this requirement.

Prerequisites
You have the system privilege INIFILE ADMIN.

Neither the source system or target system is con gured for high isolation (the value of the database_isolation in
the [multidb] section of the global.ini le is low) .

The value of parameter ssl in the [communication] section of the global.ini le is set to off.

External communication is not con gured for TLS/SSL in either the source system or target system.

Procedure
Using for example the SAP HANA cockpit or ALTER SYSTEM ALTER CONFIGURATION statement, set the parameter
[multidb]enforce_ssl_database_replication in the global.ini le to false.

Related Information
Con guring SAP HANA System Properties (INI Files)
Modify a System Property in SAP HANA Cockpit

Preparing to Copy or Move a Tenant Database

Before you copy or move a tenant database to another system, you must perform several steps. These are primarily to enable
the systems to communicate with each other securely.

Context

 Note
During the copy and move process, data is replicated via a secure (TLS/SSL) network connection by default. If you do not
require a secure network connection and have disabled this feature, you can skip the rst two steps: Verify TLS/SSL
Con guration of Internal Communication Channels and Set Up Trust Relationship Between Target and Source Systems. For
more information, see Disable Secure Network Communication.

1. Verify TLS/SSL Con guration of Internal Communication Channels

In both the source system and the target system, verify that TLS/SSL is enabled on internal communication channels on
the basis of the system public key infrastructure (system PKI).

2. Set Up Trust Relationship Between Target and Source Systems

This is custom documentation. For more information, please visit the SAP Help Portal 101
12/1/2023
Create a certi cate collection in the system database of the target system and add either the public-key certi cate of
the system database of source system, or the root certi cate of the source system. This certi cate is used to secure
communication between the systems via external SQL connections.

3. Open Communication From Target to Source System

Open communication from the target system to the source system by enabling services in the source system to listen on
all network interfaces.

4. Create Credential for Authenticated Access to Source System

Create a credential to enable authenticated access to the source system for the purpose of copying or moving a tenant
database.

5. Obtain Key Management Con guration ID

In the system database of the source system, obtain the ID of key management con guration to be replicated to the
target system.

6. Back Up Tenant Database

Back up the tenant database that will be copied or moved.

Related Information
Disable Secure Network Communication

Verify TLS/SSL Con guration of Internal Communication

Channels
In both the source system and the target system, verify that TLS/SSL is enabled on internal communication channels on the
basis of the system public key infrastructure (system PKI).

Prerequisites
You have a user in the system database of both systems with the system privilege INIFILE ADMIN.

Context
During the copy and move process, data is replicated via a secure (TLS/SSL) network connection by default. If you do not
require a secure network connection and have disabled this feature, you can skip this step. For more information, see Disable
Secure Network Communication.

Procedure

 Remember
This step must be performed in both the source system and the target system.

1. Verify the SYSTEM layer values of the following parameters in the global.ini le:

[communication] ssl must be set to systempki

[system_replication_communication] enable_ssl must be set to on

You can verify (and change) these settings using the SAP HANA cockpit or alternatively, you can con gure them by
executing the following SQL statements:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ( 'communication', 'ssl') = 'sys
ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ( 'system_replication_communicat

This is custom documentation. For more information, please visit the SAP Help Portal 102
12/1/2023
2. Restart the system.

Task overview: Preparing to Copy or Move a Tenant Database

Next task: Set Up Trust Relationship Between Target and Source Systems

Related Information
TLS/SSL Con guration on the SAP HANA Server
Disable Secure Network Communication
Con guring SAP HANA System Properties (INI Files)
Modify a System Property in SAP HANA Cockpit

Set Up Trust Relationship Between Target and Source Systems

Create a certi cate collection in the system database of the target system and add either the public-key certi cate of the
system database of source system, or the root certi cate of the source system. This certi cate is used to secure
communication between the systems via external SQL connections.

Prerequisites
You have a user in the system database of the target system with the system privileges CERTIFICATE ADMIN, TRUST
ADMIN, and DATABASE ADMIN.

You have a copy of the extract_certificates.py python script. The python script le must be accessible to the
<sid>adm user. You can nd the script attached to SAP Note 2175664.

You have the public-key certi cate of the system database of the source system (or the root certi cate of the source
system) used for external communication.

If this certi cate does not already exist, you can create it using the SAPGENPSE tool or the SAP Web Dispatcher
administration tool, both of which are delivered with SAP HANA. The certi cate must be imported into the source
system.

 Caution
By default, SAP HANA allows encrypted communication for all exposed interfaces leveraging self-signed certi cates.
Although self-signed certi cates allow communication encryption, full communication security can only be reached
leveraging certi cates signed by a Certi cate Authority (CA).

If the certi cate does exist, its location depends on how you manage certi cates in your system. Certi cates stored in
database (recommended) are contained in the certi cate store. The required certi cate is assigned to the collection
with purpose SSL. Certi cates stored in the le system are contained in tenant database-speci c personal security
environments or PSEs (default $SECUDIR/sapsrv.pse).

For more information, see TLS/SSL Con guration on the SAP HANA Server in the SAP HANA Security Guide and
Managing Client Certi cates in the SAP HANA Administration Guide.

Context
During the copy and move process, data is replicated via a secure (TLS/SSL) network connection by default. If you do not
require a secure network connection and have disabled this feature, you can skip this step. For more information, see Disable
Secure Network Communication.

This is custom documentation. For more information, please visit the SAP Help Portal 103
12/1/2023

 Note
If you already have a CA-signed certi cate, you can skip steps 1 through 3.

Procedure
1. Create a personal security environment (PSE) le using the SAPGENPSE tool.

sapgenpse gen_pse -p <path>/<file name>.pse -x "" -noreq "CN=<FQDN of source host>"

 Example
sapgenpse gen_pse -p foo.pse -x "" -noreq "CN=sourcehost.domain"

2. Extract the generated private key and the self-signed certi cate from the PSE le using the
extract_certificates.py script.

python <path to script>/extract_certificates.py -p <file name>.pse

The script will print a list of one or more SQL statements that can be transferred to an SQL console using copy and
paste.

3. In the system database of the source system, create a certi cate collection and set its purpose to SSL. You can choose
any name for the certi cate collection.

You can do this using the Certi cate Collections app of the SAP HANA cockpit or by executing the following SQL
statements:

CREATE PSE <collection name>;

ALTER PSE <collection name> SET OWN CERTIFICATE '<private key and certificate>';
SET PSE <collection name> PURPOSE SSL;

 Tip
You can generate the ALTER PSE SQL statement using the extract_certificates.py script.

4. In the system database of the target system, create a certi cate collection and set its purpose to DATABASE
REPLICATION. You can choose any name for the certi cate collection.

You can do this using the Certi cate Collections app of the SAP HANA cockpit or by executing the following SQL
statements:

CREATE PSE <collection name>;

SET PSE <collection name> PURPOSE DATABASE REPLICATION;

5. If not already in the certi cate store, import the public-key certi cate of the system database of the source system (or
the root certi cate of the source system) into the certi cate store of the target system.

You can do this using the Certi cate Store app of the SAP HANA cockpit or by executing the following SQL statement:

CREATE CERTIFICATE FROM '<certificate content>';

6. Add the system database certi cate (or root certi cate) to the new collection.

You can do this using the Certi cate Collections app of the SAP HANA cockpit or by executing the following SQL
statement:

ALTER PSE <collection name> ADD CERTIFICATE <certificate id>;

 Tip
This is custom documentation. For more information, please visit the SAP Help Portal 104
12/1/2023
You will nd the certi cate ID in the system view SYS.CERTIFICATES.

SELECT * FROM SYS.CERTIFICATES;

Task overview: Preparing to Copy or Move a Tenant Database

Previous task: Verify TLS/SSL Con guration of Internal Communication Channels

Next task: Open Communication From Target to Source System

Related Information
TLS/SSL Con guration on the SAP HANA Server
SAP Note 2175664 - Migration of le system based X.509 certi cate stores to in-database certi cate stores
Disable Secure Network Communication

Open Communication From Target to Source System

Open communication from the target system to the source system by enabling services in the source system to listen on all
network interfaces.

Prerequisites
You have the credentials of operating system administrator <sid>adm for the source system.

Context
Use the SAP HANA database lifecycle manager (HDBLCM) to con gure inter-service communication so that the services of the
target system can listen on all available network interfaces.

 Note
It is only necessary to perform this step in the source system. However, if you later want to be able to monitor the progress
of the copy or move operation from the source system, you can also do it in the target system.

Procedure

 Note
The following procedure describes how to do this using the Web user interface. For more information about using the
command-line interface or graphical user interface of the SAP HANA database lifecycle manager, see the SAP HANA
Administration Guide .

Instead of using the SAP HANA database lifecycle manager (HDBLCM), you can execute the following SQL statement:

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ( 'communication',

'listeninterface') = '.global' WITH RECONFIGURE;

1. Open the SAP HANA database lifecycle manager by entering the following URL in a browser:

https://<host>:1129/lmsl/HDBLCM/<sid>/index.html
This is custom documentation. For more information, please visit the SAP Help Portal 105
12/1/2023
2. Click the tile Con gure Inter-Service Communication.

3. When prompted, enter the password of the <sid>adm user.

4. Select the setting global.

5. Click Run to apply the new setting.

6. Close the application and log out.

7. Restart the SAP HANA database.

Task overview: Preparing to Copy or Move a Tenant Database

Previous task: Set Up Trust Relationship Between Target and Source Systems

Next task: Create Credential for Authenticated Access to Source System

Related Information
Internal Host Name Resolution

Create Credential for Authenticated Access to Source System

Create a credential to enable authenticated access to the source system for the purpose of copying or moving a tenant
database.

Prerequisites
You have a user in the system database of the target system with the system privilege CREDENTIAL ADMIN.

Context
You create a credential in the secure internal credential store of the system database of target system.

The credential store is used in SAP HANA to securely store credentials required for outbound connections. For more
information about the secure internal credential store, see the SAP HANA Security Guide .

Procedure
In the system database of the target system, create a credential by executing the following SQL statement:

CREATE CREDENTIAL FOR COMPONENT 'DATABASE_REPLICATION' PURPOSE '<host:internal_port_of_system_DB_of

TYPE 'PASSWORD' USING 'user="<user_in_system_DB_of_source_system_with_DATABASE_ADMIN>";password="<p

The values required for each parameter are as follows:

Parameter Required Value

COMPONENT DATABASE_REPLICATION

PURPOSE Host name and internal port number of the system database of the
source system

TYPE PASSWORD

This is custom documentation. For more information, please visit the SAP Help Portal 106
12/1/2023

Parameter Required Value

USING User name of a user in the system database of the source system
with the system privilege DATABASE ADMIN

 Sample Code

CREATE CREDENTIAL FOR COMPONENT 'DATABASE_REPLICATION' PURPOSE 'host123456.acme.corp:30001' TYPE

Task overview: Preparing to Copy or Move a Tenant Database

Previous task: Open Communication From Target to Source System

Next task: Obtain Key Management Con guration ID

Related Information
SAP HANA Security Guide

Obtain Key Management Con guration ID

In the system database of the source system, obtain the ID of key management con guration to be replicated to the target
system.

Prerequisites
The source system uses the local secure store (LSS) in conjunction with an external key management system (KMS) to
protect encryption root keys.

You have the system privilege ENCRYPTION ROOT KEY ADMIN.

Context
When moving or copying a tenant database, a key management con guration ID (other than DEFAULT) must be provided if the
source system uses the LSS with a KMS. Since only a key administrator can obtain the key management con guration ID, this
means that the key administrator must permit the transfer of a key management con guration to the target system.

This key management con guration is replicated to the target system and is initially used in the copied or moved database. The
key administrator of the source system may create a dedicated con guration for the new database already before the copy or
move, or the key administrator of the target system can change the replicated con guration after the copy or move.

Procedure
Get the required con guration ID by querying system view SYS.KEY_MANAGEMENT_CONFIGURATIONS.

Task overview: Preparing to Copy or Move a Tenant Database

Previous task: Create Credential for Authenticated Access to Source System

Next task: Back Up Tenant Database

This is custom documentation. For more information, please visit the SAP Help Portal 107
12/1/2023

Related Information
Create and Manage a Key Management Con guration
KEY_MANAGEMENT_CONFIGURATIONS System View

Back Up Tenant Database

Back up the tenant database that will be copied or moved.

Context
You can back up the tenant database from the system database or from the tenant database directly. For more information, see
Creating Backups in the SAP HANA Administration Guide .

Task overview: Preparing to Copy or Move a Tenant Database

Previous task: Obtain Key Management Con guration ID

Related Information
Creating Backups

Copy a Tenant Database to Another System

Copy a tenant database from one SAP HANA system to another. The new copied tenant database runs as a separate,
independent database.

Prerequisites
All general system prerequisites are ful lled. For more information, see Copying and Moving Tenant Databases Between
Systems.

All preparatory steps have been completed. For more information, see Preparing to Copy or Move a Tenant Database .

You have a user in the system database of the target system with the system privilege DATABASE ADMIN and CATALOG
READ.

Procedure
1. Create a tenant database in the target system as a copy of the original tenant database in the source system.

You do this by executing the CREATE DATABASE statement:

 Code Syntax
CREATE DATABASE <target_database_name> [ AT [ LOCATION ] '<target_hostname>[:<port_number_m
{ ADD '<servicetype>' [ AT [ LOCATION ] '<target_hostname>[:<port_number_service> ]@<sourc
{ AS REPLICA OF [ <source_database_name> ] AT [ LOCATION ] '<source_hostname>[:<port_numbe
[ OS USER '<username>' OS GROUP '<groupname>' ]
[ NO START ]
[ <restart_mode> RESTART ]

This is custom documentation. For more information, please visit the SAP Help Portal 108
12/1/2023

 Note
As the location of the source tenant database, you specify the host name and port number for internal
communication of the system database of the source system.

The source and target host names must match the host names speci ed during installation.

If you enabled SSL, the host name must match the common name (CN) speci ed in the public-key certi cate
of the system database of source system.

If you specify a service list, the number and type of services must match the source database.

If your systems are con gured for high isolation, you specify a valid OS user or OS group of the tenant
database.

Fallback snapshots are not copied to the target system.

 Sample Code
CREATE DATABASE TARGET_DATABASE AS REPLICA OF SOURCE_DATABASE AT 'host123456.acme.corp:3000

With the execution of this statement, the system database of the target system does the following:

Establishes a secure connection to the system database of the source system

Creates a tenant database with the same topology as the tenant database in the source system

Starts replicating data between the services in the source tenant database and the corresponding services in the
target database

2. Monitor replication progress of data replication from the original tenant database to the new tenant database.

Use the system view SYS_DATABASES.M_DATABASE_REPLICAS to monitor the status of data replication in the
system database of the target system or SYS.M_DATABASES to monitor directly in the new tenant database.

The current status of replication is shown in the eld REPLICATION_STATUS. The value is aggregated across all
individual services of the system, e.g. the system global status is only ACTIVE, if all individual services have replication
status ACTIVE.

The following replication statuses are possible:

Status Description

UNKNOWN The secondary system did not connect to the primary system since the last restart of the primary
system.

INITIALIZING Data transfer is initialized. In this state, the secondary system cannot be used.

SYNCING The secondary system is syncing again (e.g. after a temporary connection loss or restart of the
secondary system).

ACTIVE Initialization or sync with the primary system is complete and the secondary system is continuously
replicating. If a crash occurs, no data is lost in SYNC mode.

ERROR A connection error occurred (details can be found in REPLICATION_STATUS_DETAILS).

The view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS provides detailed information about the replication

process at the service level.

 Tip
If the replication status is ERROR, use system view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS to
investigate further.

This is custom documentation. For more information, please visit the SAP Help Portal 109
12/1/2023
If you cannot create a replica because the source database is still in status "REPLICATING" even though the target
database is already dropped, execute the statement ALTER DATABASE <database_name> CANCEL REPLICA
on the source system to clean up the system before reattempting replication.

 Note
You can also monitor from the source system if you opened communication between the systems in both directions.
For more information, see Open Communication From Target to Source System.

3. When replication status is ACTIVE (indicating that the new tenant database is in sync with the original tenant
database), stop replication and nalize the copy by executing the following statement in the system database of the
target system:

ALTER DATABASE <new_database_name> FINALIZE REPLICA

With the execution of the above statement, the system database of the target system performs the following actions in
the new tenant database:

Starts the new tenant database

Changes the root key for data volume encryption and re-encrypts data in the new database if data volume
encryption is enabled

Deletes remote identities of database users if the original tenant database was con gured for cross-database
access

Next Steps
Perform the required manual post-move tasks.

Related Information
Copying and Moving Tenant Databases
Preparing to Copy or Move a Tenant Database
Perform Manual Post-Copy/Move Tasks
CREATE DATABASE Statement (Tenant Database Management)
M_DATABASE_REPLICAS System View

Move a Tenant Database to Another System

Move a tenant database in one SAP HANA system to another. After a move, the original tenant database is deleted and the
new tenant database takes over.

Prerequisites
All general system prerequisites are ful lled. For more information, see Copying and Moving Tenant Databases Between
Systems.

All preparatory steps have been completed. For more information, see Preparing to Copy or Move a Tenant Database .

You have a user in the system database of the target system with the system privilege DATABASE ADMIN and CATALOG
READ.

Procedure
1. Create a tenant database in the target system as a copy of the original tenant database in the source system.
This is custom documentation. For more information, please visit the SAP Help Portal 110
12/1/2023
You do this by executing the CREATE DATABASE statement:

 Code Syntax
CREATE DATABASE <target_database_name> [ AT [ LOCATION ] '<target_hostname>[:<port_number_m
{ ADD '<servicetype>' [ AT [ LOCATION ] '<target_hostname>[:<port_number_service> ]@<sourc
{ AS REPLICA OF [ <source_database_name> ] AT [ LOCATION ] '<source_hostname>[:<port_numbe
[ OS USER '<username>' OS GROUP '<groupname>' ]
[ NO START ]
[ <restart_mode> RESTART ]

 Note
As the location of the source tenant database, you specify the host name and port number for internal
communication of the system database of the source system.

The source and target host names must match the host names speci ed during installation.

If you enabled SSL, the host name must match the common name (CN) speci ed in the public-key certi cate
of the system database of source system.

If you specify a service list, the number and type of services must match the source database.

If your systems are con gured for high isolation, you specify a valid OS user or OS group of the tenant
database.

Fallback snapshots are not moved to the target system.

 Sample Code
CREATE DATABASE TARGET_DATABASE AS REPLICA OF SOURCE_DATABASE AT 'host123456.acme.corp:3000

With the execution of this statement, the system database of the target system does the following:

Establishes a secure connection to the system database of the source system

Creates a tenant database with the same topology as the tenant database in the source system

Starts replicating data between the services in the source tenant database and the corresponding services in the
target database

2. Monitor replication progress of data replication from the original tenant database to the new tenant database.

Use the system view SYS_DATABASES.M_DATABASE_REPLICAS to monitor the status of data replication in the
system database of the target system or SYS.M_DATABASES to monitor directly in the new tenant database.

The current status of replication is shown in the eld REPLICATION_STATUS. The value is aggregated across all
individual services of the system, e.g. the system global status is only ACTIVE, if all individual services have replication
status ACTIVE.

The following replication statuses are possible:

Status Description

UNKNOWN The secondary system did not connect to the primary system since the last restart of the primary
system.

INITIALIZING Data transfer is initialized. In this state, the secondary system cannot be used.

SYNCING The secondary system is syncing again (e.g. after a temporary connection loss or restart of the
secondary system).

ACTIVE Initialization or sync with the primary system is complete and the secondary system is continuously
replicating. If a crash occurs, no data is lost in SYNC mode.

This is custom documentation. For more information, please visit the SAP Help Portal 111
12/1/2023

Status Description

ERROR A connection error occurred (details can be found in REPLICATION_STATUS_DETAILS).

The view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS provides detailed information about the replication

process at the service level.

 Tip
If the replication status is ERROR, use system view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS to
investigate further.

If you cannot create a replica because the source database is still in status "REPLICATING" even though the target
database is already dropped, execute the statement ALTER DATABASE <database_name> CANCEL REPLICA
on the source system to clean up the system before reattempting replication.

 Note
You can also monitor from the source system if you opened communication between the systems in both directions.
For more information, see Open Communication From Target to Source System.

3. When replication status is ACTIVE (indicating that the new tenant database is in sync with the original tenant
database), stop replication and nalize the move by executing the following statement in the system database of the
target system:

ALTER DATABASE <new_database_name> FINALIZE REPLICA DROP SOURCE DATABASE

With the execution of the above statement, the system database of the target system performs the following actions:

Starts the new tenant database

Changes the root key for data volume encryption and re-encrypts data in the new database if data volume
encryption is enabled

Drops the original tenant database in the source system

 Note
To ensure that the new tenant database can be recovered to the most recent consistent state after the move,
data backups are not deleted as part of the move process. This is important in the event that a backup is
created in the original tenant database after replication has nished but before the original database is nally
deleted.

Deletes any communication paths con gured for cross-database access that reference the original tenant
database in the other tenant databases of the source system

Next Steps
Perform the required manual post-move tasks.

Related Information
Copying and Moving Tenant Databases
Preparing to Copy or Move a Tenant Database
Perform Manual Post-Copy/Move Tasks
CREATE DATABASE Statement (Tenant Database Management)
M_DATABASE_REPLICAS System View

This is custom documentation. For more information, please visit the SAP Help Portal 112
12/1/2023

Copy a Tenant Database to Another Host within the same

System
Copy a tenant database from one host to another within the same system.

Prerequisites
All general system prerequisites are ful lled. For more information, see Copying and Moving Tenant Databases Between
Systems.

All preparatory steps have been completed. For more information, see Preparing to Copy or Move a Tenant Database .

You have a user in the system database with the system privilege DATABASE ADMIN and CATALOG READ.

Procedure
1. Create a tenant database as a copy of the original tenant database.

You do this by executing the CREATE DATABASE statement:

 Code Syntax
CREATE DATABASE <target_database_name> [ AT [ LOCATION ] '<target_hostname>[:<port_number_m
{ ADD '<servicetype>' [ AT [ LOCATION ] '<target_hostname>[:<port_number_service> ]@<sourc
{ AS REPLICA OF [ <source_database_name> ] AT [ LOCATION ] '<source_hostname>[:<port_numbe
[ OS USER '<username>' OS GROUP '<groupname>' ]
[ NO START ]
[ <restart_mode> RESTART ]

 Note
As the location of the source tenant database, you specify the host name and port number for internal
communication of the system database.

The source and target host names must match the host names speci ed during installation.

If you do not specify a target host name, the host with the lowest number of services will be used.

If you enabled SSL, the host name must match the common name (CN) speci ed in the public-key certi cate
of the system database.

If you specify a service list, the number and type of services must match the source database.

If your systems are con gured for high isolation, you specify a valid OS user or OS group of the tenant
database.

Fallback snapshots are not copied.

 Sample Code
CREATE DATABASE TARGET_DATABASE AS REPLICA OF SOURCE_DATABASE AT 'host123456.acme.corp:3010

With the execution of this statement, the system database does the following:

Creates a tenant database with the same topology as the source tenant database

Starts replicating data between the services in the source tenant database and the corresponding services in the
target database

2. Monitor replication progress of data replication from the original tenant database to the new tenant database.

This is custom documentation. For more information, please visit the SAP Help Portal 113
12/1/2023
Use the system view SYS_DATABASES.M_DATABASE_REPLICAS to monitor the status of data replication in the
system database or SYS.M_DATABASES to monitor directly in the new tenant database.

The current status of replication is shown in the eld REPLICATION_STATUS. The value is aggregated across all
individual services of the system, e.g. the system global status is only ACTIVE, if all individual services have replication
status ACTIVE.

The following replication statuses are possible:

Status Description

UNKNOWN The secondary system did not connect to the primary system since the last restart of the primary
system.

INITIALIZING Data transfer is initialized. In this state, the secondary system cannot be used.

SYNCING The secondary system is syncing again (e.g. after a temporary connection loss or restart of the
secondary system).

ACTIVE Initialization or sync with the primary system is complete and the secondary system is continuously
replicating. If a crash occurs, no data is lost in SYNC mode.

ERROR A connection error occurred (details can be found in REPLICATION_STATUS_DETAILS).

The view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS provides detailed information about the replication

process at the service level.

 Tip
If the replication status is ERROR, use system view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS to
investigate further.

If you cannot create a replica because the source database is still in status "REPLICATING" even though the target
database is already dropped, execute the statement ALTER DATABASE <database_name> CANCEL REPLICA
on the source system to clean up the system before reattempting replication.

3. When replication status is ACTIVE (indicating that the new tenant database is in sync with the original tenant
database), stop replication and nalize the copy by executing the following statement in the system database:

ALTER DATABASE <new_database_name> FINALIZE REPLICA

With the execution of the above statement, the system database performs the following actions in the new tenant
database:

Starts the new tenant database

Changes the root key for data volume encryption and re-encrypts data in the new database if data volume
encryption is enabled

Deletes remote identities of database users if the original tenant database was con gured for cross-database
access

Next Steps
Perform the required manual post-move tasks.

Related Information
Copying and Moving Tenant Databases
Preparing to Copy or Move a Tenant Database

This is custom documentation. For more information, please visit the SAP Help Portal 114
12/1/2023
Perform Manual Post-Copy/Move Tasks
CREATE DATABASE Statement (Tenant Database Management)
M_DATABASE_REPLICAS System View

Create a Copy of a Tenant Database on the Same Host

Create a copy of a tenant database on the same host.

Prerequisites
All general system prerequisites are ful lled. For more information, see Copying and Moving Tenant Databases Between
Systems.

All preparatory steps have been completed. For more information, see Preparing to Copy or Move a Tenant Database .

You have a user in the system database with the system privilege DATABASE ADMIN and CATALOG READ.

Procedure
1. Create a tenant database as a copy of the original tenant database.

You do this by executing the CREATE DATABASE statement:

 Code Syntax
CREATE DATABASE <target_database_name>
{ ADD '<servicetype>' [ AT [ LOCATION ] '<hostname>[:<port_number_service> ]@<hostname>:<p
{ AS REPLICA OF [ <source_database_name> ] KEY MANAGEMENT CONFIGURATION <id> }
[ OS USER '<username>' OS GROUP '<groupname>' ]
[ NO START ]
[ <restart_mode> RESTART ]

 Note
If you enabled SSL, the host name must match the common name (CN) speci ed in the public-key certi cate
of the system database.

If you specify a service list, the number and type of services must match the source database.

If your systems are con gured for high isolation, you specify a valid OS user or OS group of the tenant
database.

Fallback snapshots are not copied.

 Sample Code
CREATE DATABASE TARGET_DATABASE AS REPLICA OF SOURCE_DATABASE;

With the execution of this statement, the system database does the following:

Creates a tenant database with the same topology as the source tenant database

Starts replicating data between the services in the source tenant database and the corresponding services in the
target database

2. Monitor replication progress of data replication from the original tenant database to the new tenant database.

Use the system view SYS_DATABASES.M_DATABASE_REPLICAS to monitor the status of data replication in the
system database or SYS.M_DATABASES to monitor directly in the new tenant database.

This is custom documentation. For more information, please visit the SAP Help Portal 115
12/1/2023
The current status of replication is shown in the eld REPLICATION_STATUS. The value is aggregated across all
individual services of the system, e.g. the system global status is only ACTIVE, if all individual services have replication
status ACTIVE.

The following replication statuses are possible:

Status Description

UNKNOWN The secondary system did not connect to the primary system since the last restart of the primary
system.

INITIALIZING Data transfer is initialized. In this state, the secondary system cannot be used.

SYNCING The secondary system is syncing again (e.g. after a temporary connection loss or restart of the
secondary system).

ACTIVE Initialization or sync with the primary system is complete and the secondary system is continuously
replicating. If a crash occurs, no data is lost in SYNC mode.

ERROR A connection error occurred (details can be found in REPLICATION_STATUS_DETAILS).

The view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS provides detailed information about the replication

process at the service level.

 Tip
If the replication status is ERROR, use system view SYS_DATABASES.M_DATABASE_REPLICA_STATISTICS to
investigate further.

If you cannot create a replica because the source database is still in status "REPLICATING" even though the target
database is already dropped, execute the statement ALTER DATABASE <database_name> CANCEL REPLICA
on the source system to clean up the system before reattempting replication.

3. When replication status is ACTIVE (indicating that the new tenant database is in sync with the original tenant
database), stop replication and nalize the copy by executing the following statement in the system database:

ALTER DATABASE <new_database_name> FINALIZE REPLICA

With the execution of the above statement, the system database performs the following actions in the new tenant
database:

Starts the new tenant database

Changes the root key for data volume encryption and re-encrypts data in the new database if data volume
encryption is enabled

Deletes remote identities of database users if the original tenant database was con gured for cross-database
access

Next Steps
Perform the required manual post-move tasks.

Related Information
Copying and Moving Tenant Databases
Preparing to Copy or Move a Tenant Database
Perform Manual Post-Copy/Move Tasks
CREATE DATABASE Statement (Tenant Database Management)

This is custom documentation. For more information, please visit the SAP Help Portal 116
12/1/2023
M_DATABASE_REPLICAS System View

Perform Manual Post-Copy/Move Tasks

After you have committed the copy or move and the new tenant database is up and running, you must perform several manual
tasks.

Procedure
1. Back up the new root keys to a root key backup le (*.rkb) in a secure location.

 Caution
Store the root key backup le in a safe location. Losing this le may result in the database being unrecoverable.

2. Perform a full data backup of the new tenant database (copy only).

3. Reverse the preparatory steps required to secure the copy or move process:

Close network communication from the target system to the source system. See Open Communication From
Target to Source System.

Delete the credential used by the system database of the target system to access the source system. See Create
Credential for Authenticated Access to Source System.

Delete the certi cate collection with purpose DATA REPLICATION created to secure external communication
between the systems. See Set Up Trust Relationship Between Target and Source Systems.

If you created and signed the certi cate yourself, delete the PSE le from the le system.

4. If necessary, recon gure parameters in *.ini les with tenant-database-speci c values. See Con guration Parameters in
Tenant Database Systems.

5. Recon gure cross-database access, if required. See Enable and Con gure Cross-Database Access.

6. After con guring cross-database access, rebuild or repair cross-database objects, if required. For improved performance,
SAP HANA stores object IDs of remote objects in the catalog persistence. If a tenant database is copied or moved, these
remote object IDs are likely to change and must be rebuilt by executing the CHECK_CATALOG procedure. The following
objects are supported: functions, procedures, synonyms, SQL views, and calculation views.

 Note
Only rebuild and repair cross-database objects if you want the original settings to be fully restored. For security
reasons, you may not want cross-database objects to be restored on a copied or moved system.

 Example
Rebuild all objects with remote dependencies by executing the following procedure:

CALL CHECK_CATALOG ('REBUILD_REMOTE_DEPENDENCY', null, null, null)

Repair all objects in <schema> by executing the following procedure:

CALL CHECK_CATALOG ('REPAIR_REMOTE_DEPENDENCY', '<schema>', null, null)

Repair the object <schema>.<view> by executing the following procedure:

CALL CHECK_CATALOG ('REPAIR_REMOTE_DEPENDENCY', '<schema>', '<view>', null)

Related Information

This is custom documentation. For more information, please visit the SAP Help Portal 117
12/1/2023
Open Communication From Target to Source System
Set Up Trust Relationship Between Target and Source Systems
Create Credential for Authenticated Access to Source System
Enable and Con gure Cross-Database Access
Database-Speci c Con guration Parameters

SAP HANA System Replication with Tenant Databases

The usual SAP HANA system replication principles apply for tenant database systems.

SAP HANA supports system replication for tenant databases on the system level, this means the tenant database system as a
whole including all tenant databases. An SAP HANA system installed in multiple-container mode always has exactly one system
database and any number of tenant databases (including zero).

Before you begin preparing a replication strategy for an SAP HANA system, you should be aware of the following important
points:

SAP HANA systems can only be replicated as the whole system. This means that the system database and all tenant
databases are part of the system replication. A takeover can only be performed as a whole system. A takeover on the
level of a single tenant database is not possible.

Tenant management actions are synchronized over the whole replication topology so that an action (such as create,
drop, start, stop) executed on a tenant on the primary is also performed on the secondary.

If an active tenant database is stopped in a running SAP HANA system replication, it is stopped on the secondary site as
well. If a takeover is done while tenant databases (which were part of the system replication) are stopped, they will be in
the same state after takeover as they were on the primary site when they were stopped. The tenant databases must be
started to complete the takeover.

If a new tenant database is created in a con gured SAP HANA system replication, it must be backed up to participate in
the replication. Afterwards, the initial data shipping is started automatically for this tenant database. If a takeover is
done while the initial data shipping is running and not nished, this new tenant database will not be operational after
takeover and will have to be recovered with backup and recovery (see the SAP HANA Database Backup and Recovery
section of the SAP HANA Administration Guide ).

If SAP HANA system replication runs in replication mode SYNC with the full sync option enabled, and if the connection to
the secondary site is interrupted, no write operations on the primary site are possible. The operation of creating a
tenant database, for example, will wait until the connection to the secondary is reestablished or the SQL statement
times out.

With SAP HANA systems, the services needed are generated automatically in the tenant databases.

For SAP HANA system replication, a port offset value of 10000 is con gured to reserve ports for system replication
communication.

 Note
Values for port ranges do not need to be maintained manually. This can be done automatically by the SAP Host Agent
which includes port reservation functionality and optimizes the relevant Linux kernel parameters. Refer to 'Linux
Kernel Parameters' in the Lifecycle Management section of the SAP HANA Administration Guide and the following
SAP Notes:

401162 - Linux: Avoiding TCP/IP port con icts and start problems, this describes setting up the SAP Host
Agent.

2382421 - Optimizing the Network Con guration on HANA- and OS-Level

For SAP HANA systems running with the HIGH isolation level, the system PKI SSFS data and key le must be copied from
the primary system to the same location on the secondary system(s). For more information, see Increase the System
Isolation Level in the SAP HANA Administration Guide .

For more information on the individual points, see the Availability and Scalability section of the SAP HANA Administration Guide .

This is custom documentation. For more information, please visit the SAP Help Portal 118
12/1/2023

Related Information
Availability and Scalability
SAP HANA Database Backup and Recovery
Copying and Moving Tenant Databases
Increase the System Isolation Level
Linux Kernel Parameters
SAP Note 401162
SAP Note 2382421

Backing Up and Recovering Tenant Databases

Before you begin preparing a backup strategy for an SAP HANA system, you should be aware of some important points
regarding how SAP HANA handles the backup and recovery of tenant databases.

For more information, see the SAP HANA Database Backup and Recovery section of the SAP HANA Administration Guide .

Related Information
Points to Note: SAP HANA Backups
Points to Note: SAP HANA Recovery
SAP HANA Database Backup and Recovery
SAP Note 2096000

Important Disclaimer for Features in SAP HANA

For information about the capabilities available for your license and installation scenario, refer to the Feature Scope Description
for SAP HANA.

This is custom documentation. For more information, please visit the SAP Help Portal 119