Oracle 19c Multitenant Architecture CDB, PDB- Benefits

    Oracle introduced the multitenant architecture in 2013 with Oracle Database 12c version release.  It consists of CDB(Container Database) and PDB (Pluggable Database). Only one user PDB could be created with EE license in 12.1 and 12.2 database version. However, with purchase of the Multitenant license option, you could create up to 252 PDBs within a single CDB with 12c database version.In 12c, the Standard Edition did not have the multitenant option – only one PDB allowed. If you are not licensed for Oracle Multitenant, the container database architecture still can be in use (single-tenant mode) – with one user-created PDB, one user-created application root, and one user-created proxy PDB. There is no change in 18c version as well.

    With release of Oracle Database 19c, Oracle allows you to create three user-created PDBs without any additional multitenant license. Applicable for both Standard Edition (SE2) and Enterprise Edition (EE). Multitenant architecture brings huge administration advantages, especially to minimize patching, upgrade and cloning. This license change will help accelerate the adoption of the Container Database architecture.

    Though the non-CDB architecture was “deprecated” since 12.1, it was available and supported till date. Things are changing. In 20c, the non-CDB architecture is “desupported” and I believe there will not be an option to create non-CDB database.

    Above picture shows about the CDB and PDBs concepts. PDBs are pluggable in nature symbolically represented as pendrive. A CDB includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and non schema objects that appears to an Oracle Net client as a non-CDB.
    CDB Administrator is the super-admin and PDB Administrators are the administrators for each PDB database.

    Benefits of the Multitenant Architecture:

    Challenges for a Non-CDB Architecture :

    • Improvements in hardware technology, especially the increase in the number of CPUs, servers are able to handle heavier workloads than before. A database may use only a fraction of the server hardware capacity. This approach wastes both hardware and human resources.

    • For example, 100 servers may have one database each, with each database using 10% of hardware resources and 10% of an administrator’s time. A team of DBAs must manage the SGA, database files, accounts, security, and so on of each database separately, while system administrators must maintain 100 different computers.

    • A head DBA(maintain CDB) oversees a team of multiple DBAs, each of whom is responsible for two or three PDBs.

    Benefits of the Multitenant Architecture :

    • The Oracle Multitenant option enables you to consolidate data and code without altering existing schemas or applications.

    • The PDB/non-CDB compatibility guarantee means that a PDB behaves the same as a non-CDB as seen from a client connecting with Oracle Net. The installation scheme for an application back end that runs against a non-CDB runs the same against a PDB and produces the same result. Also, the run-time behavior of client code that connects to the PDB containing the application back end is identical to the behavior of client code that connected to the non-CDB containing this back end.

    • Operations that act on an entire non-CDB act in the same way on an entire CDB, for example, when using Oracle Data Guard and database backup and recovery. Thus, the users, administrators, and developers of a non-CDB have substantially the same experience after the database has been consolidated.

    • Cost Reduction: By consolidating hardware and database infrastructure to a single set of background processes, and efficiently sharing computational and memory resources, you reduce costs for hardware and maintenance. For example, 100 PDBs on a single server share one database instance.

    • Easier and more rapid movement of data and code: By design, you can 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 manage the environment as an aggregate by executing a single operation, such as patching or performing an RMAN backup, for all hosted tenants and the CDB root. 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, a PDB administrator can flush the shared pool or buffer cache in the context of a PDB without affecting other PDBs in the CDB.

    • 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 any shared resource environment, administrators must manage system resources to provide a predictable environment for users and address unexpected or transient resource contention. To address these issues, and to provide resource usage monitoring, 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.

    • Easier migration of data and code: For example, instead of upgrading a CDB from one database release to another, you can unplug a PDB from the existing CDB, and then plug it into a newly created CDB from a higher release.

    • Easier testing of applications: You can develop an application on a test PDB and, when it is ready for deployment, plug this PDB into the production CDB.

    Recent Articles


    Related Stories

    Leave A Reply

    Please enter your comment!
    Please enter your name here

    Stay on op - Ge the daily news in your inbox