Multitenancy

You can segregate data, storage space, and processing resources for multiple client organizations by creating multiple tenant databases in a single instance of HCL OneDB™.

For example, assume that you want to provide payroll services to small businesses. You sell the use of the payroll application as a service to small business clients. Instead of providing a separate HCL OneDB instance to each client, you can configure a tenant database for each client in a single HCL OneDB instance.

When you configure multitenancy, you segregate the following aspects of a database server:

Data
You create a separate tenant database for each client.
Storage spaces
Each tenant database has dedicated storage spaces to store data. Tables, fragments, and indexes that are created in the tenant database must be created in the dedicated storage spaces. Only the tenant database can use the dedicated storage spaces.

You can limit the amount of permanent storage space that is available to a tenant database to conserve system resources.

Temporary storage spaces can be dedicated to a specific tenant database or shared between databases.

You can encrypt tenant storage spaces if the DlSK_ENCRYPTION configuration parameter is set. Each encrypted storage space has a separate encryption key.

Users
You can set permissions for client users to access each tenant database. You can grant certain users permission to create, modify, or drop tenant databases. By default, only a DBA or user informix can create a tenant database.
Processing resources
You can segregate CPU resources for a tenant database by defining a tenant virtual processor class and creating virtual processors for running the session threads for the tenant database. Otherwise, the session threads for tenant databases have access to all CPU virtual processors.
Session limits
You can set the following limits for tenant sessions:
  • The number of locks a tenant session can acquire.
  • The amount of memory that can be allocated for a session.
  • The amount of temporary storage space that can be allocated for a session.
  • The size of transactions within a session, based on the amount of log space that individual transactions would fill.
  • The amount of time that a transaction is allowed to run within a session.
  • The amount of shared memory for all sessions that are connected to the tenant database.
  • The number of client connections to a tenant database.

The following illustration shows a possible configuration for two clients in the HCL OneDB server instance. Each client has a database and users who are allowed to access the tenant database. Each tenant database has their own storage spaces. Both tenant databases share the default temporary sbspace. Tenant A has a tenant virtual processor class with two virtual processors, while Tenant B has a virtual process class with one virtual processor.

Figure 1: Multiple tenants in the HCL OneDB server instance

This graphic is described in the surrounding text.

Replication and tenant databases

You can replicate tenant databases with Enterprise Replication and high-availability clusters.

You can run the commands to create, modify, or delete tenant databases through an Enterprise Replication grid.

You cannot run the commands to create, modify, or delete tenant databases from an updatable secondary server in a high-availability cluster.

Backup and restore of tenant databases

You can back up tenant databases as part of a database server backup or by specifying the tenant storage spaces in the backup command. You can restore a single tenant database with ON-Bar by specifying the -T option in the onbar -r command.

If storage space encryption is enabled, you can encrypt all storage spaces that are assigned to a tenant during a restore. Whether storage space encryption is enabled or not enabled, you can decrypt all tenant storage spaces during a restore.