SAP Hana Mutli Container Database

An SAP HANA system installed in multiple-container mode can contain several multi-tenant database containers. Otherwise, it is a single-container system. Single-container systems can be converted to multiple-container systems.A multiple-container system always has exactly one system database, used for central system administration, and any number of multi-tenant database containers (including zero),also called tenant databases.An SAP HANA system installed in multiple-container mode is identified by a single system ID (SID). Databases are identified by a SID and a database name.
In a multiple-container system, only the system database runs the name server. The name server contains landscape information about the system as a whole, including which tenant databases exist. It also provides index server functionality for the system database. Unlike the name server in a single-container system, the name server of the system database in a multiple-container system does not own topology information. That is, it does not own information about the location of tables and table partitions in databases. Database-related topology information is stored in the relevant tenant database catalog.Tenant databases only require their own index server. Servers that do not persist data, such as the compile server and the pre-processor server, run on the system database and serve all databases.All the databases in a multiple-container system share the same installation of database system software, the same computing resources, and the same system administration.
MCDBThey have the following features:
  • Shared installation of database system software
  • Tenant databases are identified by name or port.
  • Additive sizing for all tenant database
    •  Strong isolation features, so that each tenant database has the following:
    •  Database administration and end users, database catalog, repository, persistence,backups, traces, and logs
    • Tenants memory sizing and CPU consumption, which can be configured independently
  •  Integration with SAP HANA data center operation procedures, housekeeping, backups, and so on
The system database is created during installation of a multiple-container system. It contains information about the system as a whole and all tenant databases. It is used for central system administration.
If you use a multiple-container system, you have one system database and any number of tenant databases. Multiple applications run in different tenant databases. You can use this deployment option to replace existing MCOS on-premise scenarios.
SYSTEM DB
The system database is created during either installation of a multiple-container system or during the conversion from a single-container system to a multiple-container system. The system database contains information about the system as a whole, as well as all its tenant databases. It is used for central system administration. It contains the data and users for system administration. System administration tools, such as the SAP HANA cockpit or the SAP HANA studio, can connect to this database. The system database stores overall system landscape information, including information on the tenant databases that exist in the system. However, it doesn’t own database-related topology information, that is, information about the location of tables and table partitions in databases. Database-related topology information is stored in the relevant tenant database catalog.
Administration tasks performed in the system database apply to the system as a whole and to all of its databases (for example, system-level configuration settings). Alternatively, it can target specific tenant databases (for example, backup of a tenant database). the following information about the system database:
The system database is not a database with full SQL support.
  • The system database cannot be distributed across multiple hosts: scale-out is not
    possible.
  • If you need a full-featured SAP HANA database in a multiple-container system, then you must create at least one tenant database.
  •  The system database can show monitoring data from tenant databases (views in the
    schema SYS_DATABASES), but it can never show actual content from tenant databases.

Comments

Post a Comment

Popular posts from this blog

SPOOL WORK PROCESS

Spool Process: It is the Only Process that is used to output the documents to a Printer, fax, email etc.. Spool Work Processes are created by using parameter risp/wp_no_spo=1 it is possible to configure more than one spool work process based on available resources. Spool Process Work Flow: User Submits the request to print a Document. The Dialog Process handles the request and print directly or schedules to print in the background.The Print requests are stored in the TemSe(Temporary Sequential Files) Temporary Sequential Files are stored either at File System or at database Level which is defined by parameter rspo/store_location. rspo/store_location=”G” or ‘DB’ G means global directory stores the TEMSE in /usr/sap/SID/SYS/global db mean the Tables TST01 and TST03.(TST01 Contains Print Attributes and TST03 Contains the Spool Data to be Printed) Due to Spool in DB the DB Size Increases, as a Result, the backup time increases and Tapes may not fit with the data for S...
Read more

ENQUEUE WORK PROCESS

It is used to lock and unlock the Objects during an update.These locks are displayed in SM12 and Held for longer hours until the transaction is committed or rollback.These locks are issued from a lock table which resides in the main memory of the instance where enqueue process is created/located. Enque Processes are configured by parameter rdisp/wp_no_enq=1. Generally One Enque Process for instance is sufficient,more then one is required in a massive update system. The Lock table size on the memory ranges between 4mb to 100 MB(200 MB in the Net weaver 7.3 Systems ) It is defined by parameter enque/table_size=4 to 200 MB. For 4mb of enqueue table size, the Number of lock/owners/objects/arguments can be restricted up to 3715. Enqueue Flow: User submits the Request for an Update. The Dialog or Background Process Handles the Request Dia or BTC Processes communicates with Enqueue Process and obtains a lock on the record so that no other user has to write access to that r...
Read more

DIALOG PROCESS

Dialog Process: It is the only process that is used to communicate with end users Interactively using Classic GUI or Through RFC or through Http Protocol. The Average Response Time for each dialog step is 600 ms.it is displayed through ST03n Each Process can execute up to a maximum runtime of 600 seconds.if any process goes beyond this time an additional time of 60 seconds is given and the process is timed out.(ST22)(it is not mandatory to allocate additional 60 seconds Each Process Serves 5-10 users.(Calculated based on ST07) Each Process Requires 75mb to 300 mb Memory Each Process can Handle the requests that are initiated for background, spool & update and update them in temporary tables. Dialog Process is not restricted to a User and Users are not restricted to a process which is referred as process multiplexing Parameters to configure dialog processes is rdisp/wp_no_dia There should be at least minimum two dialog processes and maximum up to 100 processes. The ...
Read more