HANA DBintermediate
HANA Multitenant Database Containers (MDC)
Running multiple isolated tenant databases on one shared HANA system infrastructure using Multitenant Database Containers.
One HANA installation can host several independent databases. This has been the standard architecture since HANA 2.0 — not an option you enable.
MDC is like a large apartment building where each unit (tenant database) has its own locked door, its own utilities meter, and its own lease terms, while all units share the same building foundation, plumbing infrastructure, and physical address (the underlying HANA installation) - far more efficient than building a separate standalone house for every tenant, while still keeping each unit's affairs fully private from its neighbors.
Key Concepts
1
The structure.
system database administration only: create tenants, system-wide
configuration. Never holds application data.
tenant database a real database: its own schemas, users, backups.
tenant database another one, isolated from the first.2
Each tenant listens on its own SQL port, so an application connects to it exactly as if it were a separate
HANA system. It cannot see the others.
3
Shared where it is cheap, isolated where it matters. Tenants share the installation, the hosts and the
memory pool. They do not share data, users or backups.
4
That is what makes consolidation viable: development, quality and a couple of small side-by-side
applications can live on one installation without separate hardware for each, and without their data or
user administration touching.
5
Resource governance is the part that makes it safe. Without limits, one tenant loading a large dataset
takes memory the others needed:
6
ALTER SYSTEM ALTER CONFIGURATION ... SET ('memorymanager',
'allocationlimit') = '...'7
Setting a per-tenant allocation limit is how a noisy tenant is prevented from starving its neighbours. Skip
it and consolidation turns one system's bad afternoon into everyone's.
8
Backup and recovery are per tenant, which is a genuine improvement over the older single-container
model. One tenant can be restored to a point in time while the others carry on untouched.
9
That matters in practice: refreshing the quality tenant from production no longer involves the systems
sharing the installation.
10
Worth stating plainly in an interview. Single-container mode is legacy. A new HANA installation is
multitenant even if it has exactly one tenant today — so the question is not whether to use MDC but how
many tenants and with what limits.
11
And the operational caution. Shared infrastructure means shared fate for anything below the database:
the host, the memory, the installation itself. Patching the installation affects every tenant, so a
maintenance window is a window for all of them. That is the trade consolidation makes, and it should be a
deliberate choice rather than a discovery.
12
What the interviewer is probing.1. "What does MDC give you?" Probing: the purpose. Stalls: "Multiple databases." Moves up:
isolated tenants sharing one installation and system resources, each with its own users, data and
backups.
13
2. "What is shared and what is not?" Probing: the boundary. Stalls: "Everything is shared."
Moves up: the installation, kernel version and host resources are shared; data, users and
configuration are per tenant.
14
3. "Can a tenant be moved or copied?" Probing: the operational benefit. Stalls: "No." *Moves
up:* yes — tenant copy and move are supported, which is how system refreshes become faster.
15
4. "What is the risk of consolidating tenants?" Probing: honesty. Stalls: "None." *Moves
up:* resource contention and a single upgrade schedule for all of them, so the tenants must tolerate
the same maintenance window.