The Multitenant Architecture

The Multitenant architecture allows a single super container (CDB) to shelter multiple pluggable databases(PDB).  From the server subsystem, there is only one database i.e. the container database, and therefore only one instance ie CDB. Each applications only sees the PDB it connects to. There is no application code change required when connecting to a PDB. But there will be an additional tns file entry for the PDB as each pluggable database will have its own tns entry. Each PDB runs as a service within the CDB but ensures complete security and isolation amongst them. Traditionally an oracle database has an instance ( memory and background processes)  and the file structure.

In multitenant architecture, the oracle instance is common to all PDBs. For the file structure, the multitenant architecture reorganizes the components and categorizes them as “sharable components” and “application components”.

The sharable components are the SPFILE, control file, SYSTEM and SYSAUX tablespaces, redo logs and archived redo logs, UNDO and TEMP tablespaces.

The application components are the datafiles specific to that PDB.

 

Licensing for Multitenant

In the 12.1 and 12.2 release of EE Oracle, only 1 PDB could be created in 1 CDB. But with the purchase of the multitenant license you could create 256 PDBs in a single CDB.

With the release of Oracle Database 19c, Oracle allows 3 PDBs to be created in a single CDB without any additional multitenant licensing.

The non CDB architecture was deprecated from 12.1 and most probably in the 20c release the non CDB architecture will be desupported

Containers in a CDB

Every CDB has the following

Exactly one root CDB

This stores the oracle supplied metadata (oracle supplied packages and v$ tables) and common users.

Exactly one root PDB

The seed PDB is a system-supplied template that the CDB can use to create new PDBs. The seed PDB is named PDB$SEED. You cannot add or modify objects in PDB$SEED.

Zero or more user-created PDBs

User created PDBs are application specific pluggable databases that store the data and code specific to a particular application eg – A sales application PDB, A library catalogue PDB

 

CDB with Two PDBs

 

Benefits

Database consolidation

A single copy of background processes and memory are used for multiple databases.

A single copy of the sharable file structure components are used for multiple databases.

For example, in a non CDB architecture, there may be 10 different servers supporting 10 different databases. This will correspondingly increase the maintenance load on the database and system administrators.

In a CDB architecture, you can have all the databases in a single CDB. It may require a higher end server wrt memory, CPU etc but it will definitely reduce the no of servers drastically.

This makes the tasks of the DBAs and system administrators that much simpler.

Better manageability

Backup can be taken of the entire CDB, while point in time recovery can be done at the PDB level. Upgrade and patch activities can be performed at the container level.

Dataguard can be setup at the container level and each new PDB on the primary site will be auto discovered at the standy site.

Patches and upgrades need to be applied on a single CDB

Cost Reduction

By consolidating multiple databases into 1 single CDB, having a single instance and a single sharable file structure the cost of hardware and maintenance gets reduced considerably.

Easier movement of data and code

The plug and unplug feature eases data and code mobility across containers.

References

https://dbanotes.com/oracle-12c-multitenant-architecture-86aefe634587

https://docs.oracle.com/database/121/CNCPT/cdbovrvw.htm#CNCPT89236 – current