Skip to Content

Since SAP HANA SPS09, there is an introduction of new feature called “SAP HANA multitenant database containers” (MDC). The purpose of SAP HANA MDC is to eliminate the MCOS – Multiple Components One System (Multiple SAP HANA systems on one SAP HANA) or MCOD – Multiple Components One Database (Multiple schemas on one SAP HANA) scenario that is not supported for Production HANA usage. The virtualization (VMware) and supported hardware partition (Lpar, nPartition and etc) for the MCOS is supported for Production HANA usage with some limitation. The SAP HANA MDC is supported on single node HANA, scale-up HANA node and scale-out HANA nodes.

Basically, SAP HANA with MDC enabled containing ONE system DB and at least one tenant DB with a single System number and System ID. When we converted a single HANA DB system to MDC, it will contain a system DB and the tenant DB (tenant count 0). All the tenant DB in a MDC system share the same installation of the HANA database system software (which mean all the tenant DB running with the same SAP HANA revision number) and the same computing resources. For the fresh installation of SAP HANA, it will having an option of “single_container” or “multiple_containers” as in the screen captured 1. If you are selecting the “multiple_containers”, it will only create the SYSTEM DB and you will need to create the first tenant DB (tenant count 1) manually via the SAP HANA DB cockpit. Do differentiate on the tenant count number for the scenario of fresh installation and scenario of single DB system conversion to SAP HANA MDC. The tenant count number is crucial on the port assignment in tenant databases. This blog is based on the scenario of single DB system conversion to SAP HANA MDC.

Screen captured 1: SAP HANA installation option

System DB stored the system-wide landscape information (name server is running on System DB), and provides configuration and monitoring system-wide. Do take note that the name server of the system database in a multiple-container system does not own topology information. Database-related topology information is stored in the relevant tenant database catalogue. Nevertheless, the services that do not persist data such as compile server, pre-processor server will be running on System DB. The SAP Web dispatcher is running as separate service where it is responsible to route the incoming HTTP requests from clients to correct XS server based on virtual host names.

We have the System ID = HBT and System number = 00 running on AWS, the following screen captured 2 showing the services running on SYSTEM DB and the name server is tag with SQL port 30013 (3<nn>13), this port must be allow in the AWS security group for the connection from HANA studio.

Screen captured 2: SYSTEM DB Landscape

Tenant databases consist of its own index server and the XS server is running in the (master) index server of the tenant by default. Of course, we can embedded the XS server into each tenant DB index server and embedded into the name server of the System DB. You will not see the XS server from the landscape of the tenant DB in HANA studio if it is an embedded XS server. The XS services can be added as a separate service if necessary as well. The HANA data and log files for the SYSTEM DB and tenant DB’s are separated with different volume ID and they do not share the same data and log files (screen captured 3, 4 and 5). You may noticed that the different ports number of the index server in each tenant in the below screen captured. The explanation of the ports will details in later section.

The tenant DB is isolated from others tenant DB in term of application data, user’s management, database catalogue, repository, ports, data files and log files.  There is an option to activate the cross database access in SAP HANA MDC system, which mean read-only queries between tenant databases are possible with the database objects like tables and views. Cross-database access between tenants is inactive by default. SAP note 2196359 and SAP HANA administration guide provide more information on cross database access in a SAP HANA MDC system.

Screen captured 3: System DB Volumes

Screen captured 4: Tenant DB count 0 with tenant DB name HBT

Screen captured 5: Tenant DB count 1 with tenant DB name HB2

Dedicated ports and connections for SQL, HTTP- based client communication and internal communication is assigned to each tenant database as in the screen captured 6. Port number range for tenant databases are vary from 3<nn>40 to 3<nn>99 which mean the maximum number of tenant DB created is 20 tenant DB per instance because each of the tenant DB will occupied 3 port numbers for SQL, HTTP and internal communication.

There are few scenarios on the port assignment in the SAP HANA MDC, remember that port assignment of tenant DB is based on automatic port number assignment and the port number is important for the network folks to open the port for incoming request to the SAP HANA server.

Scenario 1:

If you are converting a single-container system to a multiple-container system. These will created a system DB with the port assignment of 3<nn>01, 3<nn>13, 3<nn>14 and one tenant database (count 0). This tenant DB (count 0) will be having the same port number as before the MDC conversion which is 30<instance>03 (internal communication), 3<instance>15 (SQL), 3<instance>08 (HTTP). After that, the subsequent manual creation of tenant DB (count 1) will be automatically assigned to numbers 3<instance>40—42. Then, the additional manual creation of tenant DB (count 2) will be automatically assigned ports the next three available port numbers: 3<instance>43—45. This will be showing more details in another blog “Convert SAP HANA Single DB to MDC”.

Scenario 2:

A fresh SAP HANA installation with the option of multiple_containers will create only a system DB after the installation. After that, you will need to create the first tenant and this tenant will be automatically assigned by 3 ports number, 3<nn>40-3<nn>42. Then the 2nd tenant DB will be automatically assigned by 3<nn>43-3<nn>45, the 3rd tenant DB will be automatically assigned by 3<nn>46-3<nn>48.

The port number 3<nn>13, 3<nn>41 and 3<nn>44, 80<nn>, 43<00> will required to open for the incoming request to the SAP HANA MDC server (let say we have 2 tenant DB’s as per the screen captured 6).

Screen captured 6: Connections for SAP HANA MDC (picture taken from SAP HANA MDC Operation guide)

As you guys familiar with the OS user <sid>adm user in HANA system, every tenant databases in SAP HANA MDC system run under the OS user <sid>adm with low isolation by default. You may create each individual OS user for each tenant databases and configure the high isolation if you need to tighten your SAP HANA MDC security which mean the processes of individual tenant databases will be running under dedicated OS users belonging to dedicated OS groups, instead of all database processes running under <sid>adm.

The database SYSTEM user exists in every tenant database and also exist in system database which mean each of the tenant databases having their own SYSTEM user and password including the system database. SYSTEM user is the database superuser, the SYSTEM user in system database having additional privileges like creating/dropping tenant databases, changing the configuration files of tenant databases, performing databases backup.

The backup of SAP HANA MDC including the SYSTEM database backup and each of the tenant databases backup. You can backup the HANA databases by using SAP HANA DB cockpit, SAP HANA studio, hdbsql command, scripting, backint and SAP DBA cockpit in Netweaver system. The recovery is only supported on tenant database to tenant database recovery which mean the restore from single DB system to tenant DB or vice versa is not supported. The backup/restore will be discuss more details in my other blog “Tenant DB configuration and backup/restore (SAP HANA MDC)”.

For the high availability and disaster recovery on SAP HANA MDC, it just applies to the entire SAP HANA instances which including the system DB and all the tenant databases. You can’t select specific tenant DB for the HANA system replication, it is only supported on “all or nothing” concept.

Conclusion:

In a nutshell, if the business is looking for a cost effective solutions on SAP HANA with non-giant size of traditional DB size (for SAP BW and SAP ERP) that plan to migrate to SAP HANA, they can consider the SAP MDC feature to leverage or optimize the HANA server. For example, customer can always having their SAP ERP on HANA, SAP BW on HANA into a same Production HANA appliance with SAP HANA MDC enable (It will need to have 2 PRD HANA appliance before the SAP HANA MDC). You may refer to SAP Note 1661202, 1826100 and 1681092 for the whitepaper of the application/scenario that running on SAP HANA MDC system.

If you found this blog is interesting, you may follow my next blog on “Convert SAP HANA Single DB to MDC”, for those already with SAP HANA single DB and plan to convert it to SAP HANA MDC.

Convert HANA single DB system to Support MultiTenant Database Containers (MDC) on AWS – Part 2

Tenant DB configuration and backup/restore – Part 3

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Andy Silvey

    Hi Reagan,

    excellent series of blogs.

    I am a big fan of MultiTenancy and we have just gone live with two HANA migrations having Tenant DB’s on the same HANA system.
    .

    Regarding Tenant ports, we are doing something interesting with our MultiTenancy, we are preparing for SAP HANA Tenant Mobilty.

    What is SAP HANA Tenant Mobility ?

    Imagine, you have several  Dev, or QA or Production HANA systems in your landscape, and all with MDC enabled.

    Imagine, as your systems which have Tenant DB’s on HANA system grow, it is possible that the DB’s of different SAP systems grow at different rates, and therefore, it is possible that where at one time, a certain number of HANA Tenant DB’s resided comfortably on a HANA system, it can happen that as the Tenant DB’s grown, a Tenant DB could out grow the capacity of the HANA system and need to be moved to a different HANA system – welcome to SAP HANA Tenant Mobility.

    Basically, with SAP HANA Tenant mobility we implement the possibility to move Tenant DB’s between HANA systems based upon the requirements at a certain time.

    You’ve gone into detail about the Tenant ports and the most important point of this comment, is to advise everybody:

    Assumption 1 – if we implement SAP HANA Tenant Mobility, Tenant DB’s will only ever reside on HANA systems respective to the SAP system’s layer of the landscape. ie, Tenant DB’s from Dev SAP systems will only ever reside on a Dev HANA system, Tenant DB’s from SAP systems in the QA layer of the landscape will only ever reside on HANA systems in the QA layer of the landscape, and Tenant DB’s from Prod SAP systems will only ever reside on Prod HANA systems, ie, Tenants will never move from one layer of the landscape to another

    Assumption 2 – obviously, if we want to make SAP HANA Tenant Mobility possible we have more than one HANA system at every layer of our landscape, more than one Dev HANA system, more than one QA HANA System and more than one Prod HANA system

    considering these assumptions, if we want SAP HANA Tenant Mobility to be possible with the least amount of complication, then…

    when we create a Tenant DB on any HANA System at a certain layer of the landscape (Dev or QA or Prod), there cannot be two Tenant DB’s in any layer of the landscape with the same Tenant ports, otherwise, moving a Tenant from one HANA system to another will be very complicated.

    Therefore, to conclude the comment, when choosing your Tenant DB ports, keep track of every Tenant DB at every layer of your landscape and ensure across all HANA systems at each layer of the landscape you do not have two Tenant DB’s with the same ports.

    Best regards,

    Andy.

    John Appleby

    (0) 

Leave a Reply