Why Multitenant?

Databases have been an integral component of most applications for some time. The use of databases has increased tremendously, with the data growing several folds, doubling in just the last 2 years alone.

This has brought about a number of challenges for DBA’s and System admin folks, having to contain operating expenses, being the first on the list.

Reducing Software license costs, eliminating under utilized servers and reducing management labor helps IT departments meet their business goals.

These objectives have traditionally been achieved by consolidating databases and reducing the number of servers to minimize the software license and hardware costs.

This in turn has helped reduce the number of Database Management and System Administration resources required.

Schema Consolidation
Schema migration from smaller servers onto larger servers, has been the modus operandi. This form of database consolidation includes moving less busier schemas onto other less loaded servers, merging them into an existing database.

One of the down-falls with this strategy however is that schemas and objects with similar names in the database cannot co-exist. For this to work, these object names have to be migrated to newer names which results in development costs and additional QA testing efforts.

To start out with lets look at the common options available so far to contain this sprawl.

Server Consolidation
Consolidation by moving the database instance from one server to another is also not uncommon.

Unfortunately while licensing costs are reduced, the databases still have to be allocated dedicated memory for the SGA and the background processes.

DBA’s still have to continue to manage these as individual database instances.

Server Virutalization
Server virtualization is another option that DBA’s have in their toolkit. Databases on different servers are moved from the individual physical hosts, onto larger virtual hosts.

Here too, there are some pitfalls. Most importantly due to the virtualization layer, databases performing large amounts of IO are not suitable for this. Additionally other licenses and training is also required to setup and maintain this environment.

So how does Oracle 12c help eliminate these concerns?

The new MULTITENANT architecture introduced in 12c allows you to consolidate your databases at the DATABASE LEVEL.

Many of the issues mentioned previously are addressed when using this feature.

Let’s first familiarize ourselves with the new Multitenant Database Architecture.

How is Multitenant Architecture different?

The new Oracle Database Architecture consists of a CONTAINER DATABASE (CDB) and PLUGGABLE DATABASES (PDB).

The CDB Database is the main container database which has the SGA, background Processes and the System Data Dictionary.

The PDB Database is that component of the Multitenant architecture which holds the user data. This database can be plugged in and out of a CDB container.

The PDBs use the SGA, background process and other components of the CDB container into which it is plugged into.

Multitenant Databases. What does it solve?

Let’s look at the benefits of Multitenancy in more detail.

Cost Reduction

By consolidating databases onto fewer servers, you can reduce the cost of hardware, storage, maintenance and labor.

Supporting features available allow for rapid cloning, quick PDB database creation and upgrades.

Better Resource Utilization

By consolidating the databases, there is efficient use of the CPU, memory and other resources.

Further the Resource Manager supports this new architecture and can be used to manage the resources, allocating more CPU to the preferred PDB Databases.

Patches and Upgrades

The ease and flexibility of patching and upgrading a PDB is one significant enhancement of the multitenant database.

With this new architecture, patching efforts are significantly reduced because the CDB needs to be upgraded only once. So instead of having to apply a patch on ten different databases, you now only need to patch the CDB only.

The plugged-in PDBs are automatically patched!

Easier Deployments

New database allows rapid provisioning.

If you have a application to deploy, standing up a Database hardly takes a few minutes. Whats’s even more impressive is that only a single command is required to clone this database and provision to the application users.

Efficient Database Management

The physical database management gets a whole a lot easier.

There is now only ONE SET of database files and one instance to manage, instead of a number of different database files sets and multiple instances.

Separation of Data and Code

Although managed as part of the CDB, all PDB databases maintain their own integrity.

Security of the data is maintained for the individual PDBs by using the concept of LOCAL users. These are users created in the individual PDB databases and not available outside it.

Clear Separation of Duties

You can clearly separate the duties of the DBA managing the CDB and the individual PDBs.

A lead DBA can be given the privilege to manage both the Container and also the PDB databases. Individual DBAs can be assigned to manage their project specific PDBs only.

The user or DBA’s access to one PDB can further be secured so that they will not have access to other PDBs or the CDB. Common and local users are used to secure this access.

Easier Performance Tuning

Its a lot easier to track and tune one instance than multiple individual instances.

Many views have the CON_ID (container id) column added to them which refer to the the instance, container, seed and the Pluggable Databases.

Licensing cost?

There is no licensing cost if a single PDB is used. However if additional PDBs are provisioned the additional MULTITENANT OPTION needs to be purchased.

Welcome to the world of Oracle 12c Multitenant databases. This sounds too good too be true. It actually is!