Oracle Multitenant Application Containers – Part XIV: The Conclusion

I have been exploring Oracle multitenant application containers and sharing my learning by means of a series of articles for about a year now. This is the concluding article in the series, in which I will recapitulate various features of Oracle multitenant application containers along with links to the respective articles.

Oracle Database 12.2 introduces the concept of Multi-tenant Application Containers that enable many PDBs to share application objects such as code, metadata, and data. As a result, application administrators can now efficiently manage many application PDBs as one in a single Application Container while securely isolating their individual customer-specific data. This capability is ideally suited for SaaS, franchise, and other applications that are typically shared across different constituents, but require secure isolation of each constituent’s data.

An application container is a special type of PDB that stores data for one or more user-created applications and shares application metadata and common data among various application PDBs contained within it.  An application container has the following containers:

• Application root: exactly one application-specific root container that houses a master application definition containing common objects for one or more applications
• Application PDBs: zero or more user-created application PDBs plugged into the application root that share the definition(s) of one or more applications stored in application root
• An application seed PDB: an optional application PDB tied to the application root that serves as a user-created template to create new application PDBs rapidly

In order to create an application container within a CDB, we need to

• Create an application root
• Install application(s) in the application root
• Create application PDB(s)
• Create an application seed PDB (optional)
• Sync application PDB(s) with application(s)

Application common objects are user-created database objects in an application container. They are created in the application root and shared with the application PDBs that belong to the application root.

There are three types of application common objects:

• Metadata-linked common objects:  Application PDBs share only the metadata, but contain different sets of data.
• Data-linked common objects:  Application PDBs share a single set of data in the application root. 
• Extended data-linked common objects:  Application PDBs share the data in the application root.  However, each application PDB can store its own specific data as well.

Application Containers: Features

Application Master: With the introduction of application containers, a master application definition can be installed just once in the Application Root in an Application Container. It is visible to all application PDBs within the application container.

Application Maintenance: Since there is only one master copy of the application, maintenance operations (such as applying an application patch) need to be performed in the Application Root once only and a new master definition will propagate to individual tenant PDBs after they have synchronized with the new version. Since individual Application PDBs can choose to synchronize on their own schedule, the impact of application upgrade is restricted merely to the tenants being upgraded and a business-wide upgrade can be performed in a phased manner, leading to a much more agile application development process.

Application Versions: Different applications tagged with distinct application names and application versions can be installed in an application container.

Cross-Container Aggregation: User-created data across many application PDBs can be aggregated from one single place; i.e., the application root, by leveraging the CONTAINERS clause. Use of CONTAINER MAP with a query containing a containers clause causes the pruning away of irrelevant partitions when rows are retrieved from a subset of partitions only.

Cross-container DML: A convenient way for the Application Root administrator to perform DML operations on a table in any application PDB within the application container, without connecting to it or creating a corresponding database link.

A regular PDB can be converted to an application PDB: As a result, the applications already installed in the regular PDB can also take advantage of application containers. 

Proxy PDBs can be used with application containers to:

• Propagate an application definition to another application container in another CDB
• Keep the application synchronized across application containers in various CDBs
• Aggregate application data across multiple application containers

Applications can be load balanced across CDBs using Proxy PDBs by distributing the application PDB(s) across synchronized application containers.

An application container can be moved to a different CDB by unplugging it from the source CDB and plugging into the destination CDB. 

Multiple regular PDBs running the same application can be migrated to an application container, thereby enabling them to share application objects and be administered easily as one.

Common application users created in the application root cannot access the entire CDB environment and are restricted to their own application container.

COMMON_USER_PREFIX parameter in an Application Root defines the common user prefix for application common users in that container and is, by default, an empty string. It can be set in an Application Root to a non-null value; in which case, within that application container

• The name of an application common user should start with that prefix
• A local user created in an application PDB cannot start with that prefix.

Use Cases for Application Containers

Applications with a high density of customers: Similar types of customers using the same application can be are grouped within an application container.

Logical Data Warehouse: Dimension tables can be created in the application root while the fact table is logically partitioned across multiple application PDBs based on some partitioning key (e.g. region). As a result, ETLs can be efficiently performed for every region without any impact on one another. Moreover, a query executed across the application PDBs can effectively prune the partitions, and therefore the application PDBs, based on the key that is passed to it.

Application Container Views

The following views give information about applications. They can be queried from the application root container and in some cases the application container PDBs.

DBA_APPLICATIONS – Provides information about the applications in the current application container.

DBA_APP_PDB_STATUS – Provides information about applications in all the application PDBs in the current application container. This view can be used to show which version of an application has been synced to which application PDBs.

DBA_APP_VERSIONS – Displays information about all application versions installed in an application container.

DBA_APP_ERRORS – Describes all application error messages in the application container.

DBA_APP_PATCHES – Describes all the application patches in the Application Container.

DBA_APP_STATEMENTS – Describes all statements from all the applications in the Application Container.

I hope you find this series of articles on Oracle multitenant application containers useful. Your comments and suggestions are always welcome.