The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c were non-CDBs.
This section contains the following topics:
Components of a CDB
Common Users and Local Users
Separation of Duties in CDB and PDB Administration
A CDB includes the following components:
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.
The 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 seed. A CDB has exactly one seed.
PDBs
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.
Each of these components is called a container. Therefore, the root is a container, the seed is a container, and each PDB is a container. Each container has a unique container ID and name within a CDB. Figure 1 shows a CDB with several PDBs.
Figure 1 CDB with PDBs
You can easily plug a PDB into a CDB and unplug a PDB from a CDB. When you plug in a PDB, you associate the PDB with a CDB. When you unplug a PDB, you disassociate the PDB from a CDB. An unplugged PDB consists of an XML file that describes the PDB and the PDB‘s files (such as the data files and wallet file).
You can unplug a PDB from one CDB and plug it into a different CDB without altering your schemas or applications. A PDB can be plugged into only one CDB at a time.
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.
A CDB supports common users. A common user is a user that has the same identity in the root and in every existing and future PDB. A common user can log in to the root and any PDB in which it has privileges. The operations that a common user can perform depend on the privileges granted to the common user. Some administrative tasks, such as creating a PDB or unplugging a PDB, must be performed by a common user. A CDB also supports local users. A local user is a user that exists in exactly one PDB.
Some database administrators manage the entire CDB. These database administrators connect to the CDB as common users, and they manage attributes of the entire CDB and the root, as well as some attributes of PDBs. For example, these database administrators can create, unplug, plug in, and drop PDBs. They can also specify the temporary tablespace for the entire CDB and the default tablespace for the root, and they can change the open mode of one or more PDBs.
Database administrators can also connect to a specific PDB as a local user and then perform a subset of management tasks on the PDB that a database administrator performs on a non-CDB. The subset of tasks are those required for the PDB to support an application. For example, these can include management of tablespaces and schemas in a PDB, specification of storage parameters for that PDB, and changing the open mode of the current PDB.
A multitenant environment enables the central management of multiple PDBs in a single installation. By using a multitenant environment, you can accomplish the following goals:
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 plug a PDB into a CDB, unplug the PDB from the CDB, and then plug this PDB into a different CDB. Therefore, you can easily move an application‘s database back end from one server to another.
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 CDB, PDBs mimic the behavior of traditional non-CDBs. For example, if a user error causes data loss, then a PDB administrator can use point-in-time recovery to retrieve the lost data without affecting other PDBs.
Ease of performance tuning
It is easier to collect performance metrics for a CDB than for multiple non-CDBs. It is easier to size one SGA than several SGAs.
Support for Oracle Database Resource Manager
In a CDB, 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. To address such resource contention, usage, and monitoring issues, you can use Oracle Database Resource Manager (see Chapter 44, "Using Oracle Resource Manager for PDBs with SQL*Plus").
Fewer patches and upgrades
It is easier to apply a patch to one CDB than to multiple non-CDBs and to upgrade one CDB than to upgrade several non-CDBs.
A multitenant environment is especially useful when you have many non-CDBs deployed on different hardware in multiple Oracle Database installations. These non-CDBs might use only a fraction of the hardware resources dedicated to them, and each one might not require a full-time database administrator to manage it.
By combining these non-CDBs into a CDB, you can make better use of your hardware resources and database administrator resources. In addition, you can move a PDB from one CDB to another without requiring changes to the applications that depend on the PDB.
Below tables contains contant you need to consider while planning for a CDB.
| Action | Considerations for a CDB | Additional Information |
|---|---|---|
|
Plan the tables and indexes for the pluggable databases (PDBs) and estimate the amount of space they will require. |
In a CDB, most user data is in the PDBs. The root contains no user data or minimal user data. Plan for the PDBs that will be part of the CDB. The disk storage space requirement for a CDB is the space required for the Oracle Database installation plus the sum of the space requirements for all of the PDBs that will be part of the CDB. A CDB can contain up to 253 PDBs, including the seed. |
|
|
Plan the layout of the underlying operating system files your CDB will comprise. |
There are separate data files for the root, the seed, and each PDB. There is one redo log for a single-instance CDB, or one redo log for each instance of an Oracle Real Application Clusters (Oracle RAC) CDB. Also, for Oracle RAC, all data files and redo log files must be on shared storage. |
Chapter 17, "Using Oracle Managed Files" Oracle Automatic Storage Management Administrator‘s Guide Oracle Database Performance Tuning Guide Oracle Database Backup and Recovery User‘s Guide Oracle Grid Infrastructure Installation Guide for information about configuring storage for Oracle RAC Your Oracle operating system–specific documentation, including the appropriate Oracle Database installation guide. |
|
Plan for the number of background processes that will be required by the CDB. |
There is one set of background processes shared by the root and all PDBs. |
|
|
Select the global database name, which is the name and location of the CDB within the network structure, and create the global database name for the root by setting both the |
The global database name of the root is the global database name of the CDB. The global database name of a PDB is defined by the PDB name and the |
|
|
Familiarize yourself with the initialization parameters that can be included in an initialization parameter file. Become familiar with the concept and operation of a server parameter file (SPFILE). An SPFILE file lets you store and manage your initialization parameters persistently in a server-side disk file. |
A CDB uses a single SPFILE or a single text initialization parameter file (PFILE). Values of initialization parameters set for the root can be inherited by PDBs. You can set some initialization parameters for a PDB by using the The root must be the current container when you operate on an SPFILE. The user who creates or modifies the SPFILE must be a common user with To create a CDB, the |
"Specifying Initialization Parameters" "Using the ALTER SYSTEM SET Statement in a CDB" "Listing the Initialization Parameters That Are Modifiable in PDBs" |
|
Select the character set. |
All of the PDBs in the CDB use this character set. When selecting the database character set for the CDB, you must consider the current character sets of the databases that you want to consolidate (plug) into this CDB. |
|
|
Consider which time zones your CDB must support. |
You can set the time zones for the entire CDB (including all PDBs). You can also set the time zones individually for each PDB. |
|
|
Select the standard database block size. This is specified at CDB creation by the |
The standard block size applies to the entire CDB. |
|
|
If you plan to store online redo log files on disks with a 4K byte sector size, then determine whether you must manually specify redo log block size. Also, develop a backup and recovery strategy to protect the CDB from failure. |
There is a single redo log and a single control file for an entire CDB. |
"Planning the Block Size of Redo Log Files" Chapter 11, "Managing the Redo Log" Chapter 12, "Managing Archived Redo Log Files" |
|
Determine the appropriate initial sizing for the |
There is a separate |
|
|
Plan to use a default tablespace for non- |
You can specify a separate default tablespace for the root and for each PDB. Also, there is a separate |
|
|
Plan to use one or more default temporary tablespaces. |
There is a default temporary tablespace for the entire CDB. You optionally can create additional temporary tablespaces for use by individual PDBs. |
|
|
Plan to use an undo tablespace to manage your undo data. |
There is one active undo tablespace for a single-instance CDB. For an Oracle RAC CDB, there is one active undo tablespace for each instance. Only a common user who has the appropriate privileges and whose current container is the root can create an undo tablespace. In a CDB, the Undo tablespaces are visible in static data dictionary views and dynamic performance (V$) views when the current container is the root. Undo tablespaces are visible only in dynamic performance views when the current container is a PDB. Oracle Database silently ignores undo tablespace and rollback segment operations when the current container is a PDB. |
|
|
Plan for the database services required to meet the needs of your applications. |
The root and each PDB might require several services. You can create services for the root or for individual PDBs. Therefore, ensure that the planned number of services do not exceed the database service limit. Database services have an optional When you create a PDB, a new default service for the PDB is created automatically. The service has the same name as the PDB. You cannot manage this service with the SRVCTL utility. However, you can create user-defined services and customize them for your applications. |
"Managing Application Workloads with Database Services" "Managing Services Associated with PDBs" "SRVCTL Command Reference for Oracle Restart" for information about using the SRVCTL utility with a single-instance database Oracle Real Application Clusters Administration and Deployment Guide for information about using the SRVCTL utility with an Oracle RAC database |
|
Familiarize yourself with the principles and options of starting up and shutting down an instance and mounting and opening a CDB. |
In a CDB, the root and all of the PDBs share a single instance, or, when using Oracle RAC, multiple concurrent database instances. You start up and shut down an entire CDB, not individual PDBs. However, when the CDB is open, you can change the open mode of an individual PDB by using the |
"Modifying the Open Mode of PDBs" "Modifying a PDB with the ALTER PLUGGABLE DATABASE Statement" |
|
If you plan to use Oracle RAC, then plan for an Oracle RAC environment. |
The Oracle RAC documentation describes special considerations for a CDB in an Oracle RAC environment. |
See your platform-specific Oracle RAC installation guide for information about creating a CDB in an Oracle RAC environment. Oracle Real Application Clusters Administration and Deployment Guide |
|
Avoid unsupported features. |
The Oracle Database Readme includes a list of Oracle Database features that are currently not supported in a CDB. If you must use one or more of these features, then create a non-CDB. |
Chapter 2, "Creating and Configuring an Oracle Database"
|
Oracle Multitenant Environment,布布扣,bubuko.com
Oracle Multitenant Environment
原文：http://www.cnblogs.com/kramer/p/3880317.html