Creating a new tenant in an existing multi-tenant database results in the establishment of a new tenant partition for each existing multi-tenant object defined in the database. You can assign a specific storage area for each table, index, or LOB field, or you can use the previously defined default locations.
You can also specify if or when partitions should be allocated, as long as the following criteria exist:
The tenant is a regular tenant. You cannot specify the area assignment or allocation setting for partitions for a default tenant or a super-tenant.
The allocation rule for the tenant is either Set new objects not to allocate space or Set new objects to delay space allocation. If the rule is set to Set new objects to allocate space on tenant creation, partitions are created and allocated at the same time as the tenant is created. You will be unable to change the area assignment for a specific partition when you add a new database object.
You might choose not to allocate space at all when creating a tenant. This can save space if the tenant is not going to be using all of the multi-tenant tables. For example, when a tenant will be using only a subset of the multi-tenant tables, you can delay space allocation for the unused tables. Similarly, you might not be finished making modifications to an object when you create a tenant and prefer not to allocate space now.
For a shared object, you cannot choose not to allocate the object, so its allocation state is immediate. If default allocation is set to immediate, that setting is always applied on new tables (along with the table's indexes and the LOB fields). If the tenant's default allocation is set to delayed or none, then the table's allocation setting applies.
When you set the allocation state for a table, the same state applies to its indexes and LOB fields.