Why Upgrade to Oracle Database 12c?
Multitenant Architecture – What and Why
It is quite simple, Multiple tenants share same resources on a mutual benefit for different purposes at a very broad level. The same applies to Oracle Database where Multiple Databases share a single instance of resources aiming for different purposes on the same Server. This Oracle Database which is built on Multitenant foundation is called Container Database(CDB), and each container(tenant) residing inside is called Pluggable Database(PDB, Container).
Technology has vastly improved as customers can afford servers with hundreds of CPUs and huge chunk of Physical Memory where the Hardware resources can be distributed and managed dynamically. If applications get hold of this, that would be a huge benefit for Enterprises. That is what exactly Oracle has brought to the table, and this is only a beginning.
The multitenant option represents one of the biggest architectural changes in the history of the Oracle database. The option introduced the concepts of the Container Database (CDB) and Pluggable Database (PDB).
- Container Database (CDB) : On the surface this seems very similar to a conventional Oracle database, as it contains most of the working parts you will be already familiar with (controlfiles, datafiles, undo, tempfiles, redo logs etc.). It also houses the data dictionary for those objects that are owned by the root container and those that are visible to all PDBs.
- Pluggable Database (PDB) : Since the CDB contains most of the working parts for the database, the PDB only needs to contain information specific to itself. It does not need to worry about controlfiles, redo logs and undo etc. Instead it is just made up of datafiles and tempfiles to handle it’s own objects. This includes it’s own data dictionary, containing information about only those objects that are specific to the PDB. From Oracle 12.2 onward a PDB can, and should, have a local undo tablespace.
The following figure shows a CDB with four containers: the root, seed, and two PDBs. Each PDB has its own dedicated application. A different PDB administrator manages each PDB. A common user exists across a CDB with a single identity. In this example, common user SYS can manage the root and every PDB. At the physical level, this CDB has a database instance and database files, just as a non-CDB does.
Benefits of multitenant architecture
- Lower costs: You will need fewer hosts and storage.
- Easy and fast provisioning: You can create new PDBs from seed or from an existing PDB. You can also plug and unplug databases very quickly without any changes on the application site.
- Faster upgrade and patching: Instead of upgrading individual databases, you just need to upgrade your CDB, and all PDBs which are plugged into that CDB will get upgraded automatically. So all databases are patched together. You can also unplug a PDB from a lower version CDB database and plug it in to a higher version CDB to upgrade an individual PDB.
- Reduced administration efforts: As a DBA, you need to take care of only one database with one set of background processes/instances, and one set of data files instead of managing many databases.
- Separation of duties: DBAs can be restricted to connect only to specific PDBs. Only main DBAs can have privileges to connect to a CDB and manage PDBs. Other DBAs can provide access to only the PDBs that they are supposed to manage.
Some More About Multitenant Architecture
It is completely transparent to Application, there is no specific configuration required to connect to a Database in Multitenant Architecture over a network. It works the same way as it works with Non CDBs. Every Container or PDB has its own Service name to allow connections from Clients like JDBC/ODBC/XA/SQPLUS etc…
- A Multitenant Container Database is created using either DBCA or “CREATE DATABASE” Command
- A Multitenant Container Database or shortly a CDB, can be created with an empty container, no Pluggable Databases or shortly PDB(s) associated with it, [or] with one or more containers(More than one PDB)
- Memory configurable is sum of memory required for all PDBs, is distributed on demand across all PDBs
- A CDB can contain 253 PDBs including the SEED Container
- Starting up and Shutting down a CDB is no different than a Non-CDB except we need to manually mount and dismount associated PDBs