FAQ

SAP HANA multitenant database containers

(first released with SPS09)

Maintained by Jörg Hoffmeister and Ron Silberstein, SAP

Last edited: May 19, 2015

Q: Is there a maximum number of tenant DBs besides the hardware limits?

A: There is no fixed limit. The current recommendation is to start with fewer than 25 tenants per
system, because of the initial footprint of each tenant (~12GB).

Q: How do licenses work? Can you have enterprise and runtime licenses running in the same box
with different use cases?

A: Licensing on a per-tenant DB basis is not yet available. The entire SAP HANA system is licensed, in
much the same way that it is with a single DB system. You can have enterprise and runtime licenses
together in the same SAP HANA system.

Q: Can we have SAP Business Suite and SAP BW combined on one SAP HANA system in separate
tenants?

A: It is supported to run SAP Business Suite and SAP BW on the same production SAP HANA system.
An additive sizing approach is needed: perform a sizing estimation for each and then add them
together (and avoid underestimating). For CPU core and memory ratio aspects, the features for
allocating memory and influencing CPU core utilization per tenant can be utilized.

Q: Does each tenant DBs have its own System ID (SID) or do they run under one SID?

A: There is one SID for the entire SAP HANA MDC system.

Q: Is I/O bandwidth also managed per tenant?

A. Functionality for managing I/O throughput per tenant database is not yet available, but is under
consideration for the MDC roadmap. Backup I/O can be controlled by buffer limitation.

Q: Is HA/DR available per tenant DB?

A: HA/DW (e.g. system replication, storage replication) – works with an “all or nothing” approach –
all tenant DBs are subject to failover to other data center. Once HA/DR is setup, any changes to
existing tenant DB configuration or additions/deletions of tenant DBs requires setting up entire
HA/DR scenario all over again

Q: Does each tenant DB have its own file systems/storage per tenant?
1
A: Presently each tenant database has its own data files, log files, and .ini files, but shares file systems
with the other tenant DBs.

Q: Is still the default SAP HANA deployment still available (one SID, one DB), or is MDC
automatically deployed when applying SPS09?
A: With sps09, the default setup stays single DB – converting to an MDC system must be manually
invoked.

Q: Can I move or copy a tenant DB to another SAP HANA system that has a different revision?

A: A tenant DB can be moved or copied to a different MDC system with a higher or equal revision
number. Moving from a newer revision system to an older one is not supported.

Q: Can I use a data backup from a non-MDC system and recover it into a tenant database?

A: No, for the time being this is not possible. The source backup has to be taken from an MDC
system, thus from a tenant database.

Q: Can adjustments of CPU/memory allocation be done automatically?

A: Resource management currently requires manual administrator intervention. Automation is

under consideration for the roadmap.

Q: When making CPU/Memory allocation changes, do we need to shutdown database?

A: No shutdown is necessary for most resource parameter changes, simply add the WITH
RECONFIGURE clause.

Q: Can we over-commit CPU/Memory resources?

A: It is not (yet) supported to over-allocate memory and CPU core resources.

Q: Where can we specify the workload parameters for CPU/Memory?

A: Refer to the documentation regarding the parameters max_concurrency, affinity and

allocation_limit. These parameters can be adjusted in the administration perspective of the SAP
HANA studio, or by issuing SQL statements in the SQL editor.

Q: Can you allow all tenants to share CPU + memory, allowing for possible contention for
resources?

A: Yes.

Q: In order to update to a new SAP HANA revision, must all tenant DB's be stopped?

A: Yes.

Q: Are all SAP HANA hardware types supported by SAP?

A: Yes.

Q: Is native SAP HANA development (e.g. using XS) isolated per tenant DB and secured?

2
A: Yes. Each tenant DB has its own repository, its own users, and is secure.

Q: Is MDC available for both scale-up and scale-out?

A: Yes.

Q: In a scale-out scenario do all tenants DBs needs to be distributed, or can one tenant reside on its
own in a single node?

A: All options for distributing tenant DBs across scale out nodes are supported, including choosing
not to distribute.

Q: Is Smart Data Access supported across tenant databases?

A: SDA is supported across tenant databases; however MDC offers native cross database access
which has significant performance benefits, as connections are made internally/directly between
tenants.

Q: Can different tenants run individual versions of AFL (like PAL)

That is not yet possible. The AFL currently is provided on system level thus there is just one. Each
tenant database can decide about to load it or not.

Q: Can you have dedicated network ports per tenant?

A: Ports will be automatically assigned when a tenant DB is deployed according to a predefined

approach. Refer to the SPS09 what’s new material on SCN for more information. A special technique
is utilized to avoid running out of port numbers. Ports can also be explicitly assigned according to the
port schema policy. (Please refer to documentation)

Q: How can I enable cross-tenant DB queries?

A: Cross-tenant DB access must be explicitly set up and enabled. A mapping of users in the relevant
tenant DBs is required. Refer to the documentation for more information.

Q: Is there workload management for cross-tenant DB queries?

A: Presently there is no means to influence resource utilization on a per-query basis. In general, the
memory and CPU allocation settings are relevant for whichever tenant DB performs the query’s data-
intensive operations.

Q: Can I revert from an MDC system to a single DB system?

A: Currently not, but it is planned to realize it by recovery.

Q: Do the restrictions of the white lists of note 1661202 and 1826100 still apply with an MDC
system?

A: The restrictions of the "White List" do not apply when each application, component, or scenario is
deployed on its own tenant DB in an MDC system. However, with an MDC system, the restrictions of
the White List are relevant when considering which applications, components, and/or scenarios can
be deployed together on the same tenant DB in a manner that is supported by SAP. In other
3
words, with an MDC system it is supported (for example) to run SAP ERP and SAP BW on the same
production SAP HANA system, each one its own tenant DB. However, it is not supported to run SAP
ERP and SAP BW on the same tenant DB due to white list restrictions.

Q: Can MDC be deployed on an SAP HANA system where virtualization (e.g. VMware or others) is
deployed?

A: Yes. It is supported to run MDC on an SAP HANA production system with virtualization.