Multitenant Database Containers (MDC): SystemDB & Tenant Isolation

Deep architectural exploration of SAP HANA 2.0 Multitenant Database Containers, detailing the administrative separation, resource allocation limits, cross-database communication, and security isolation between SystemDB and Tenants.

IntermediateArchitecture~15 min studyHANA 2.0 (Mandatory MDC)

Core Learning Objectives

1.Understand the structural dichotomy between SystemDB and Tenant Databases.
2.Learn how to create, stop, start, and drop tenant databases via SQL.
3.Configure independent memory and CPU resource limits per tenant container.
4.Master cross-database queries and inter-tenant communication parameters.

Prerequisites:hana-architecture-services-overview

Definition & Architectural Rationale

Technical Definition:

Multitenant Database Containers (MDC) is the native architecture of SAP HANA 2.0 where a single physical HANA instance hosts one SystemDB (for landscape management) and multiple independent Tenant Databases containing user schemas, application data, and dedicated indexserver engines.

Why this component exists:

Prior to MDC, running multiple SAP systems (e.g. ERP, BW, SCM) required either multiple expensive physical servers or multiple HANA instances on the same host (MCOS), which multiplied OS overhead and memory waste. MDC provides logical and operational isolation while sharing common binaries, host agents, and system profiles.

Internal Working & Mechanics

1. SystemDB: - Does NOT hold business tables. - Runs hdbnameserver, managing global topology, license keys, cross-tenant backups, and audit configuration. - Connects on port 3<NR>13 (e.g. 30013 for instance 00). - Only SystemDB users can create, alter, drop, or stop/start tenant databases. 2. Tenant Databases: - Contains its own hdbindexserver process, its own SYS/SYSTEM catalogs, schemas, tables, users, and backup history. - Has dedicated /hana/data/mnt00001/hdb00002... and /hana/log/mnt00001/hdb00002... volume paths. - Assigned an individual SQL communication port: default first tenant uses 3<NR>15 (e.g. 30015), subsequent tenants use dynamic ports like 30041, 30044, etc. 3. Resource Isolation & Guardrails: In multi-tenant production landscapes, one runaway tenant query could crash the entire server. SAP HANA provides parameter isolation in global.ini: - [memorymanager] allocationlimit: Maximum RAM for that tenant. - [execution] max_concurrency: Maximum parallel CPU execution threads for that tenant.

Architecture Flow Diagram

Mermaid DiagramMultitenant Database Containers (MDC): SystemDB & Tenant Isolation

Architectural Flow: SystemDB supervises system topology while Tenant PRD and Tenant BWP operate dedicated indexservers with distinct memory allocation limits, persistence directories, and SQL listener ports.

Production SQL Diagnostics

Query All Tenants, Active Status, and SQL Ports from SystemDBSafe (Read-Only)

Provides complete inventory of all tenant databases, active coordinator states, and SQL communication ports.

SystemDB

Privileges: DATABASE ADMIN or CATALOG READ in SystemDB

Target Engine: HANA 2.0 (All SPS)

SELECT DATABASE_NAME, ACTIVE_STATUS, COORDINATOR_TYPE, SQL_PORT, DETAILS FROM SYS.M_DATABASES;

Key Diagnostic Columns

DATABASE_NAME:Name of the database container (SYSTEMDB, PRD, QAS)

ACTIVE_STATUS:YES (running and accepting queries) or NO (stopped)

SQL_PORT:Port for application connections

Expected Diagnostic Output

DATABASE_NAME | ACTIVE_STATUS | COORDINATOR_TYPE | SQL_PORT | DETAILS
------------------------------------------------------------------------
SYSTEMDB      | YES           | MASTER           | 30013    | master
PRD           | YES           | MASTER           | 30015    | 
QAS           | YES           | MASTER           | 30041    |

DBA Interpretation: SystemDB is active on port 30013, production tenant PRD is active on 30015, and quality tenant QAS is active on 30041.

Next Diagnostic Action: If a tenant ACTIVE_STATUS is NO, start it using ALTER SYSTEM START DATABASE <tenant_name>;

Tenant Lifecycle Operations: Create, Start, Stop, DropModifying (State Change)

Administrative DDL statements to manage tenant lifecycle within SystemDB.

SystemDB

Privileges: DATABASE ADMIN in SystemDB

Target Engine: HANA 2.0 (All SPS)

-- 1. Create a new tenant database CREATE DATABASE DEV SYSTEM USER PASSWORD "InitMaster_2026!"; -- 2. Stop an active tenant (e.g. for maintenance) ALTER SYSTEM STOP DATABASE DEV; -- 3. Start a stopped tenant ALTER SYSTEM START DATABASE DEV; -- 4. Drop a tenant database permanently (destroys data/log volumes) -- CAUTION: Irreversible operation! -- ALTER SYSTEM DROP DATABASE DEV;

DBA Interpretation: These commands run exclusively in SystemDB. CREATE DATABASE initializes indexserver metadata, mounts filesystems, generates cryptographic keys in SSFS, and creates the tenant SYSTEM user.

Production Best Practices & Operational Risks

Mandatory Best Practices

Always configure explicit allocationlimit for each tenant in multi-tenant environments so one tenant cannot starve others.
Never run production (PRD) and non-production (DEV/QAS) in the same physical HANA instance in an enterprise environment, as high CPU/OOM on non-prod impacts production SLAs.

Senior DBA Interview Mastery

3–5 Year Experience Target

Official Documentation & SAP Notes

SAP HANA Administration Guide for SAP HANA Platform - MDC

SAP Note 2096000 - SAP HANA Multitenant Database Containers - FAQ

SAP Note: 2096000