Shulou(Shulou.com)06/01 Report--

Oracle 12c Multi-tenant Architecture concept 1) Container, CDB, PDB

The multi-tenant architecture allows the Oracle database to run as a multi-tenant container database (CDB).

CDB includes zero, one, or more customer-created pluggable databases (PDBs). PDB is a portable collection of schemas, schema objects, and non-schema objects that, to the Oracle Net client, are non-cdb. All Oracle databases prior to Oracle database 12c are non-cdbs databases.

The container can be either PDB or root. The root container is a collection of schemas, schema objects, and non-schema objects objects that belong to PDBs; each CDB has the following containers:

L has one and only one root container, namely CDB$ROOT

There is one and only one seed PDB, PDB$SEED, which is the template for creating the PDB. Created and maintained by the system, users cannot add or modify objects

L 0 or PDB created by multiple users

Figure 17-1 CDB with Two PDBs

Use this diagram to briefly illustrate the multi-tenant container database; oracle 12c can create either a CDB database or an non-CDB database. Needless to say, the non-CDB database can be used like the previous 11g and 10g databases. The concept of container is added to CDB database, which can be understood that all databases in CDB are containers, and CDB$ROOT, PDB$SEED, PDB (hrpdb, salespdb) are containers.

L CDB$ROOT root container is special, there is one and only one, which stores the metadata and common users of the entire CDB and the source code of the system package; for example, the definition and data of the system performance view are stored in this container, and other PDB is called through metadata link and object link mechanisms.

L PDB$SEED is a template built into the system to create a user PDB. Created and maintained by the system, users cannot add or modify objects

L PDB is a non-cdb database created and migrated by users, which can be created by PDB$SEED, created through other PDB, or created from non-cdb; a database that stores user data separately, can be started and stopped separately, and can be plugged in separately

In addition, there are many differences between database management in CDB and before, mainly in data dictionary, user (common, local), role (common, local), authority and role grant, audit configuration, service (service, connect) and so on. Not understanding and not familiar with these differences will cause a lot of trouble to the daily operation and maintenance. Above, some concepts of the logical layer are briefly introduced. Let's take a look at the data files and tablespaces of the physical layer.

2) tablespaces and data files in CDB

Figure 18-8 Architecture of a CDB

As can be seen in the figure, CDB instances can manage multiple containers, and each container (PDB, CDB$ROOT) has its own system, sysaux, temp and other table spaces; undo table space and online redo log are managed uniformly through CDB$ROOT; each PDB has its own user table space; all container table spaces corresponding to data files, temporary files are stored and managed independently; control files and parameter files are managed by CDB instances

3) the advantages of CDB

Reduce the cost

Hardware and maintenance costs can be reduced by integrating hardware and database infrastructure into a set of background processes and effectively sharing computing and memory resources.

= "

Move data and code more easily and faster

By design, you can insert the PDB into the CDB, pull the PDB out of the CDB, and then insert the PDB into another CDB. As a result, you can easily move the database back end of your application from one server to another.

Easier to manage and monitor physical databases

The CDB administrator can manage the environment as a collection by performing a single action on the user and the CDB root, such as patching or performing RMAN backups.

Separation of data and code

Although it is integrated into a single entity CDB, PDBs mimics the traditional non-cdbs behavior. For example, a PDB administrator can flush a shared pool or buffer cache in a PDB context without affecting other PDBs in the CDB.

Easy performance tuning

CDB collects performance metrics more easily than multiple non-cdbs. Determining the size of one SGA is easier than determining the size of several SGA.

Support for Oracle database explorer

In any shared resource environment, administrators must manage system resources to provide a predictable environment for users and to handle unexpected or temporary resource contention. To resolve these issues and provide resource usage monitoring, you can use Oracle Database Explorer.

Reduce patches and upgrades

It is easier to apply a patch to one CDB than to multiple non-cdbs, and it is easier to upgrade one CDB than to upgrade multiple non-cdbs.

A multi-tenant environment is especially useful when you deploy many non-cdbs on different hardware installed with multiple Oracle databases. These non-cdbs may use only a fraction of the hardware resources, and each may not need to be managed by a full-time database administrator.

By combining these non-cdbs into CDB, you can make better use of hardware resources and database administrator resources. In addition, you can move PDB from one CDB to another without changing applications that depend on PDB.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.