I am sure that all of you have heard about Application Containers, but do you really understand what they are, how they work and how they can help you? Today’s post will be a mini-series that teaches you about Application Containers and how you could benefit from them. In my experience, I noticed that if you are not using a feature in your day to day job, the probability of you learning about it is very slim. And let’s face it, not everyone is using Application Containers at work on a daily basis. So here is your chance to learn about this subject, in small bites, so next time, when the opportunity comes, you can propose to have it implemented! Let’s get an understanding of what the Application Container, Application Root and Application PDBs are and then next time I’ll show you some examples.

 

1)What is an Application Container?

The Application Container is an optional CDB component, that is created by the user. The Application Container stores metadata and data for an application. There could be 0 or more application containers in a CDB.

When you create an Application Container, the Application Root is automatically created, just like when you create a container database, the CDB$ROOT is created with it. The application is also referred to as the master application definition, and it includes tables, views, packages and other objects. These objects are also called common objects.

 

To create an Application Container, you use the CREATE PLUGGABLE DATABASE statement with the AS APPLICATION CONTAINER clause. The Application Container and the Application Root are created, but no Application PDBs are created at this point, and no Application SEED PDB is created either.

The name of the Application Container must be unique within the CDB, meaning you cannot have 2 Application Containers with the same name within the CDB. Also the name has to be unique within all the names that are serviced by the same listener, and this is due to the service name. You cannot have 2 services with the same name, registered with the listener, servicing 2 different application containers.

 

You can create Application PDBs that belong to the Application Root. These PDBs would be able to share metadata (table/view/other object definition) and possibly data as well, basically share the application. Usually the application is made up of common users, metadata-linked common objects, data-linked common objects.

Let me explain:

• The common users are created in the Application Root, and also available in the Application PDBs.
• The metadata-linked common objects, ie. tables, are created in the Application Root, and also available in the Application PDBs.
• The data-linked common objects, ie table data, are inserted into the Application Root, and also available in the application PDBs.

 

2) Why would you want to create an Application Container?

 

a) Easy application deployment
You can setup an application in the Application Root, and create multiple Application PDBs that share the application. The tables and the data can be setup in the root, and all the Application PDBs can share the tables and data, OR, the tables are setup in the root, and each PDB can share the table definition, however each PDB has it’s own data in those tables.

 

b) Easy application maintenance
You can make a change to the master application definition (you upgrade the application version), and when you sync up the PDBs, the change gets propagated to the other PDBs.

 

c) The Application Container is like a CDB, as it can have an Application Seed, Application PDBs, and proxy PDBs. You can create an Application PDB from the Application Seed, similar to creating a PDB from the PDB$SEED.

 

d) You can use the CONTAINERS function to perform DML and select statements on the objects from the Application PDBs, at once, connected to the Application Root. Here is an example: if you have a table called CUSTOMERS in all the Application PDBs, then, when connected to the Application Root, using the CONTAINERS function, you can query the table for all the Application PDBs, in one shot, one statement.

 

 

3)Application Root

The Application Container has only one Application Root, just like the container database has one CDB$ROOT. The Application Root is created when the Application Container is created. You cannot convert a regular PDB into an Application Root.

The Application Root belongs to the CDB root container. The Application Root behaves as the CDB$ROOT in some circumstances, as a PDB in others, and has its own specific behavior as well. Let’s see:
Behaves as a CDB$ROOT: The Application Root is the parent container for other Application PDBs that are plugged into it.
Behaves as a PDB: The Application Root is created with the CREATE PLUGGABLE DATABASE statement, and you can open/close, startup/shutdown. You can perform plug/unplug/drop operations. It has it’s own service name, just like the other PDBs
Behaves as an Application Root: It stores user created common objects, aka application common objects, which are only visible and available in the Application Root and other PDBs plugged into the application root. These common objects are not visible outside the Application Container.

 

4)Application PDBs

These are PDBs that are plugged into the Application Container. The Application PDB must belong to only one Application Container. If the PDB doesn’t belong to an Application Container, then the PDB is not an Application PDB.
These PDBs are created with the CREATE PLUGGABLE DATABASE statement, while connected to the the Application Root. You can perform the same actions as with a regular PDB: clone, plug, unplug, drop.

 

5)Application Seed PDB

This is an optional component within the Application Container. The seed helps you create Application PDBs quickly. The name of the seed is always: 

application_container_name$SEED.

It is not mandatory to have an Application Seed PDB in the Application Container.

 

Let’s put it all together in a Mind Map below. Feel free to print it and share it!