Try OpenEdge Now
skip to main content
Configuring Multi-tenancy
Updating tenant schema : Committing changes to a multi-tenant database

Committing changes to a multi-tenant database

You can upload a data definition file, preview its contents, make storage area modifications, determine when to allocate partition space, and then commit all the changes. As you do so, you can configure one or more tenants and then commit the changes all at once, rather than needing to commit the updates for each tenant individually.
To commit changes to the database:
1. From the data definition file preview page, click Commit in the tenant menu bar (located above the list of tenants). The Confirm commit database definitions dialog appears.
The dialog shows the task name, which is the name given to the transaction you are committing. You can later use the task name to verify that the transaction has been applied once you commit the changes.
If you want, you can modify the task name. By default, the given task name includes the name of the AdminServer and database (nbbedaspauldi.LocalScr), the type of transaction being committed (load database definitions), and the name of the uploaded data definition file (terms8.df).
2. Select from the following options:
*Add new objects online — Allows you to make the following changes while the database is online:
*Add new sequences.
*Add new tables, along with any associated fields, indexes, and database triggers (which must be added within the same transaction).
*Add new fields to an existing table. (Note that you cannot define ASSIGN triggers for new fields while the database is online.)
*Add new inactive indexes to an existing table.
*Add all new multi-tenant tables as shared tables — Informs the load process to ignore any allocation settings for multi-tenant tables. Therefore, if a data definition file contains the MULTI-TENANT or KEEP-DEFAULT-AREA setting for a table, multi-tenancy settings are ignored and all objects become shared objects.
In addition, any modification described in the data definition file that would cause the table to become a multi-tenant table is ignored. (Once you enable multi-tenancy for a table you cannot disable it. You would then need to dump and reload the table.) Note that this does not apply to the addition of indexes and fields for existing tables. If an index or a table is being added to an existing multi-tenant table, the table or index is added as a multi-tenant schema object to that table.
Enabling this option can be useful, for example, if you are loading data definitions to a table that is not enabled for multi-tenancy or if you want to defer storage space allocation, particularly if you have many tenants with immediate allocation selected.
*Force allocation of new partitions that otherwise would not be allocated — Allows you to force allocation of partitions that otherwise would not be allocated when the data definition file is loaded. This option overrides the tenant's default allocation for new partitions, but changes applied to individual partitions will also be allocated if you select this option.
If you select this option, you have an additional choice to make between the following two selections:
*Force allocation of all partitions with an allocation state of Delayed — Forces allocation of partitions for tenants that are created as part of the uploaded data definition file and whosedefault allocation setting is to delay.
*Force allocation of all partitions with an allocation state of Delayed or None — Forces allocation of all partitions created as part of the uploaded data definition file. This includes those whose default allocation setting is to either delay or not allocate space at all.
For example, if a tenant has an object allocation default of no allocation (None) and a new partition for the tenant is changed to delay allocation (Delayed), this partition will be allocated if Force allocation is specified. If a tenant has its default allocation set to delay and a partition is changed to no allocation, the partition will be allocated only if the Force allocation of all partitions option is selected. Note that the forced allocation option also applies to new indexes and LOB fields added to existing multi-tenant tables.
*Add new indexes in deactivated state — Allows you to add in a deactivated state all new indexes that are described in the data definition file. This option applies to indexes on both shared and multi-tenant tables; enabling the option can save processing time if the loaded data definition file adds new indexes to tables that contain a large amount of data.
*Commit changes even when errors are encountered during load — Specifies that the load of definitions should continue, even if some definitions result in errors that prevent those definitions from being applied to the database. Note that selecting this option might leave the database in a corrupt state. If you have selected the Add new objects online option, this option is invalid and, therefore, unavailable.
3. Click Commit to commit the transactions. The data definitions from the data definition file are applied to the database, partition assignments are made, and allocation settings are applied.
The Dashboard page opens and displays a viewlet that allows you to monitor the status of the load data definition file task by either the default name or the name you assigned using the Task name field. For more information, see Monitoring data definition file updates to the database.