Introduction to SAP HANA MDC – Part 1

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 2^nd tenant DB will be automatically assigned by 3<nn>43-3<nn>45, the 3^rd 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