Skip to content

Oracle Multitenant DB 2 : Benefits of the Multitenant Architecture

Oracle Multitenant database can provide few good benefits if we plan carefully and specially by having a non-traditional approach. In the starting it may seem intimidating to the seasoned DBAs as this architecture need some learning and practice.  Few of the key benefits which Oracle describes are mentioned below:


CONSOLIDATION:

  • Better and easy to use: You can 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.

Large enterprises may use hundreds or thousands of databases. Often these databases run on different platforms on multiple physical servers. A database  may use only a fraction of the server hardware capacity. This approach wastes both hardware and human resources.  A team of DBAs must manage the SGA, database files, accounts, security, and so on of each database separately, while system administrators must maintain multiple different computers.

  • Better than VM Consolidation :  VMs are agile, but use technical resources inefficiently, and require individual management. Virtual sprawl, which is just as expensive to manage, replaces the existing physical sprawl.
  • Better than having multiple databases: Separate databases eliminate operating system replication, but do not share background processes, system and process memory, or Oracle metadata. The databases require individual management.
  • Better than clubbing your data into separate Schemas: Separate the data logically into schemas or virtual private databases (VPDs). This technique uses technical resources efficiently. You can manage multiple schemas or VPDs as one. However, this model is less agile than its alternatives, requiring more effort to manage, secure, and transport. Also, the logical model typically requires extensive application changes, which discourages adoption.

 


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 RAPID MOVEMENT OF DATA/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.
  • You can also clone PDBs while they remain available.
  • You can plug in a PDB with any character set and access it without character set conversion.
  • If the character set of the CDB is AL32UTF8, then PDBs with different database character sets can exist in the same CDB.

EASIER UPGRADE OF DATA AND CODE

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

 


EASIER MIGRATION BETWEEN SERVERS

  • To perform load balancing or to meet SLAs, you can migrate an application database from an on-premise data center to the cloud, or between two servers in the same environment.

 


EASIER MANAGEMENT AND MONITORING

  • 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, if user error loses critical data, then 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 common user can connect to any container on which it has sufficient privileges, whereas a local user is restricted to a specific PDB. Administrators can divide duties as follows:
    • An administrator uses a common account to manage a CDB or application container. 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.
    • An administrator uses a local account to manage an individual PDB.

 


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.

 

Brijesh Gogia
Leave a Reply