The Oracle database is constantly evolving. The release 12.1 of the database brought the container database architecture, the biggest change in the architecture of the Oracle database since Oracle 6. Oracle Database 12c Release 2 makes the principles of container databases, sharing of database objects and “manage many as one” available for applications. Oracle calls this feature “Application Containers”. It extends the container databases, which are a perfect foundation for Database as a Service (DBaaS), to become a platform for Software as a Service (SaaS).
There are basically two major aspects of the container database architecture: splitting the data dictionary of the Oracle database into two parts: the definition of the data dictionary objects is stored in the so called root container (CDB) and the content, i.e. the definition of application tables, users etc., is stored in the pluggable databases (PDBs). Oracle calls this feature “Sharing”. Second, the whole database can be administered from the root container.
In Oracle 12.1, these techniques were restricted to Oracle internal objects. Oracle 12.2 opens these feature for application objects: Application Containers are containers within a CDB.
Figure one: Appllication Container Architecture
The architecture of an application container is comparable to a container database: there is a special pluggable database, which is called the “application root”, as seen in Figure 1. You create your application objects in this application and you can manage the application container from there. For example, you can backup your whole application container from the application root with a single RMAN command.
When defining your application objects, you have to decide on the sharing mode. This is one of the most important steps when moving from the classical object definitions to the database object definitions for the SaaS-concept of Application containers. A table with ZIP codes, for example, is the perfect candidate for “data sharing”: you define the table in the application root, you insert data there – and it available in read only mode for all your application tenants. This ensures data quality and reduces the required storage, because you have one location of the data which is the ApplicationRoot. At the other end of the sharing options, there is the so called “metadata sharing” – you create the table in the application root and the data is stored independently in each application PDB.
Overall, the following modes for “sharing” are available:
Definition is stored in
Data is stored in
Data is read-only for the application PDBs
EXTENDED DATA SHARING
Data from Application Root is read-only for the application PDBs
The sharing method is defined when you create an object:
In all cases, you have a centralized definition of your data model in your application root. In short, the definitions are synced to the application PDBs when an application is installed in an application PDB. Additionally, you can provide an application seed database as a template for your application PDBs.
But what happens if you have to patch or upgrade the data model of your application? How does it affect your application tenants when you change the data model? Oracle has implemented a version management for applications in these application containers. You can have multiple versions of an application in your application containers and your SaaS-customers can switch to a new version when they like.
Another use case for application containers is the possibility of “Partitioning by Application PDB”, which is a variant of “Sharding” within a Container Database. Sharding means horizontal partitioning of data in different databases. For example, there is a partition respectively a separate database for each state in the US. In Application Containers, there can be an Application PDB for each state. Regional users connect to their specific application PDB. They can modify data or run reports. On the other hand, if you want nationwide reports, you can connect to the Application Root and gather information from all Application PDBs using the CONTAINERS-clause, which was introduced in Oracle 184.108.40.206 for querying PDBs from the root container of a CDB. And it works the other way round, too. When connected to the Application Root, you can be redirected to an application PDB, depending on a mapping table, the so-called “container map”. So you do not have to change the entry point of your application. All users connect to the application root, run the application, but the data is stored in different application PDBs.
So there are many use cases of this new feature: Software as a Service for the cloud, partitioning of application data among various application PDBs. Or providing individual (application) databases with a shared data model for your application developers. It’s a release 1.0 of a new feature, but it is one of the biggest feature with Oracle Multitenant with Oracle 12.2 – a great step towards Software as a Service for Oracle database applications.
Session 1223 “Application Containers – Multitenancy for Applications”, Wednesday, Apr 25, 2018 (08:30 AM - 09:30 AM) : Palm B
He is a Senior Consultant at Trivadis/Germany. Trivadis is an Oracle Platinum Partner based in Switzerland. Markus has been working with Oracle software for more than 20 years. He started as a developer for Oracle Forms and Reports, but later became a DBA. At Trivadis he specialized on Oracle Real Application Cluster and database migration projects.
He is a teacher for the Trivadis trainings on Oracle RAC and Oracle Database 12c New Features. He likes sharing his experience in his blog and on national and international conferences.
Released: March 19, 2018, 10:36 am