Concepts of the Multitenant Architecture

（一）Challenges for a Non-CDB Architecture

Large enterprises may use hundreds or thousands of databases. Often these databases run on different platforms on multiple physical servers.

Because of 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.

To show the problem in reduced scale, Figure 18-4 depicts 11 databases, each with its own application and server. A head DBA oversees a team of four DBAs, each of whom is responsible for two or three databases.

Typical responses include:

1. Use virtual machines (VMs).

In this model, you replicate the operating infrastructure of the physical server—operating system and database—in a virtual machine. 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.

1. Place multiple databases on each server.

Separate databases eliminate operating system replication, but do not share background processes, system and process memory, or Oracle metadata. The databases require individual management.

1. 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.

（二）Benefits of the Multitenant Architecture

1. Database Consolidation

Database consolidation合并 is the process of consolidating data from multiple databases into one database on one computer. The Oracle Multitenant option enables you to consolidate data and code without altering existing schemas or applications.

The following graphic depicts the databases in Figure 18-4 after consolidation onto one computer. The DBA team is reduced from five to three, with one CDB administrator managing the CDB while two PDB administrators split management of the PDBs.

Using the multitenant architecture for database consolidation has the following benefits:

1. 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.

1. 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. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. Manageability

In a CDB, the data dictionary metadata is split between the root and the PDBs. Benefits of data dictionary separation include the following:

1. 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.

1. 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.

1. Protection against data corruption within a PDB

You can flash back a PDB to an SCN or PDB-specific restore point, without affecting other PDBs. This feature is analogous to the Flashback Database feature for a non-CDB.

1. Ability to install, administer, and upgrade application-specific data and metadata in a single place

You can define a set of application-specific PDBs as a single component, called an application container. You can then define one or more applications within this container. Each application is a named, versioned set of common metadata and data shared within this application container.

1. Integration with Oracle Database Resource Manager

In a multitenant environment, one concern is contention for system resources among the PDBs running on the same server. Another concern is limiting resource usage for more consistent, predictable performance.

（三）Components of a CDB

A CDB includes the following components:

1. Root：一个CDB只有一个root，名字叫CDB$ROOT, 用于存储metadata及common users.

The root, named CDB$ROOT, stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages. A common user is a database user known in every container. A CDB has exactly one root.

1. CDB seed：

一个CDB只有一个CDB seed，名字叫PDB$SEED，它是创建PDB的模板，可更改

The CDB seed, named PDB$SEED, is a template that you can use to create new PDBs. You cannot add objects to or modify objects in the CDB seed. A CDB has exactly one CDB seed.

1. PDBs：实际使用的数据库，用于存储实际数据，PDB向后兼容12c之前版本数据库

A PDB appears to users and applications as if it were a non-CDB. For example, a PDB can contain the data and code required to support a specific application. A PDB is fully backward compatible with Oracle Database releases before Oracle Database 12c.

ROOT, CDB SEED, PDB均认为是一个容器，在CDB中有自己的container ID及name.

Each of these components is called a container. Therefore, the root is a container, the CDB seed is a container, and each PDB is a container. Each container has a unique container ID and name within a CDB. Figure 36-1 shows a CDB with several PDBs.

PDB有一个全局的ID(GUID), 用于为PDB的数据文件目录生成名字

Each PDB has a globally unique identifier (GUID). The PDB GUID is primarily used to generate names for directories that store the PDB's files, including both Oracle Managed Files directories and non-Oracle Managed Files directories.

12.2中出了新概念application containers，它由application root及多个application PDBs组成，application root存储了metadata及common data. 手册中注意以下名词理解：

application contianer=application root+application pdbs

Application containers内不能再分层

An application root cannot belong to another application root, and a PDB can belong to either no application roots or to only one application root.

The application seed is optional.

Applications cannot be installed in a CDB root or in a PDB plugged into a CDB root.

In this document, “the root” is a reference to the CDB root (CDB$ROOT). Any reference to an application root uses the term “application root.”