The Oracle database multitenant architecture was introduced in version 12c release 1. This architecture consists of a container database (CDB) that contains one or more pluggable databases (PDB). The CDB acts as a metadata repository for the PDBs and a source of user accounts that are utilized across the PDBs called common users. The CDB and PDB share resources, but not data. A PDB template or “seed” database allows the quick deployment of PDBs out of the CDB. This architecture was created with consolidation in mind and according to the Oracle 12c release 1 documentation, will become the default database architecture as the non-CDB architecture is deprecated (https://docs.oracle.com/database/121/UPGRD/deprecated.htm#BABDBCJI).
My current work has been in non-CDB environments, but given that non-CDB databases are being deprecated, it is in my interest to start working with CDB databases. I plan to share this work with you in a series of posts for (hopefully) mutual benefit.
The multitenant architecture is a separately licensed option from Oracle, but there is an exception. If the CDB contains a single PDB, then no additional licensing is required. This way, you can start converting non-CDB databases to CDB without having to accrue additional licensing cost.
The PDBs can be ‘plugged’ and ‘unplugged’ between container databases within limits. Access to the PDBs within a CDB is handled via SQL*Net. Whenever a PDB is created, a service of the same name is also created to handle the PDB connections and the service is automatically registered with the database listener. It is recommended to change the name of this service for security reasons.
While the CDB and PDB share resources such as memory and processes, each has their own SYS and SYSAUX tablespace with associated objects. There is one common UNDO tablespace at the CDB level (one per instance for RAC) to be shared, but each PDB has its own TEMP tablespace.
There is a laundry list of features in the Oracle Documentation that this new architecture provides involving consolidation:
- Cost reduction: By consolidating hardware and sharing database memory and files, you reduce costs for hardware, storage, availability, and labor. For example, 100 PDBs on a single server share one database instance and one set of database files, thereby requiring less hardware and fewer personnel.
- Easier and more rapid movement of data and code: By design, you can quickly plug a PDB into a CDB, unplug the PDB from the CDB, and then plug this PDB into a different CDB. The implementation technique for plugging and unplugging is similar to the transportable tablespace technique.
- Easier management and monitoring of the physical database: The CDB administrator can attend to one physical database (one set of files and one set of database instances) rather than split attention among dozens or hundreds of non-CDBs. Backup strategies and disaster recovery are simplified.
- Separation of data and code: Although consolidated into a single physical database, PDBs mimic the behavior of non-CDBs. For example, if user error loses critical data, a PDB administrator can use Oracle Flashback or point-in-time recovery to retrieve the lost data without affecting other PDBs.
- Secure separation of administrative duties: A user account is common, which means that it can connect to any container on which it has privileges, or local, which means that it is restricted to a specific PDB. A CDB administrator can use a common user account to manage the CDB. A PDB administrator uses a local account to manage an individual PDB. Because a privilege is contained within the container in which it is granted, a local user on one PDB does not have privileges on other PDBs within the same CDB.
- Ease of performance tuning: It is easier to collect performance metrics for a single database than for multiple databases. It is easier to size one SGA than 100 SGAs.
- Support for Oracle Database Resource Manager: In a multitenant environment, one concern is contention for system resources among the PDBs running on the same computer. Another concern is limiting resource usage for more consistent, predictable performance. To address such resource contention, usage, and monitoring issues, you can use Oracle Database Resource Manager.
- Fewer database patches and upgrades: It is easier to apply a patch to one database than to 100 databases, and to upgrade one database than to upgrade 100 databases.
The previous benefits were from the first release of CDB in Oracle version 12c release 1. Oracle 12c release 2 added the following features, although this is not a complete list:
- CDBs can now support “thousands” of PDBs instead of the previous maximum of 252.
- A PDB can now have a different character set than the CDB
- Point-in-time copies of PDBs possible for development and testing purposes
- PDB flashback now possible by setting up restore points
- PDBs can have their own UNDO tablespaces
- Upgrade a CDB with one or more PDBs in a single operation
Next up in this series – Creating, connecting to, removing, and querying CDBs and PDBs