Professional Documents
Culture Documents
About Administering A CDB: About The Current Container
About Administering A CDB: About The Current Container
Administering a CDB is similar to administering a non-CDB, but there are some differences. Most of the
differences are because some administrative tasks apply to the entire CDB, while others apply to the CDB root,
application containers, application roots, and specific pluggable databases (PDBs) and application PDBs.
Each container has a unique ID and name in a CDB. You can use the CON_ID and CON_NAME parameters in
the USERENV namespace to determine the current container ID and name with the SYS_CONTEXT function.
For example, the following query returns the current container name:
The current container can be CDB$ROOT (CDB root) only for common users.
The current container can be a particular PDB for common users and local users.
The current container can be an application root only for common users or for application common
users created in the application root.
The current container can be a particular application PDB for common users, application common
users, and local users.
The current container must be the CDB root or an application root when a SQL statement includes
CONTAINER = ALL.
You can include the CONTAINER clause in several SQL statements, such as the CREATE USER,
ALTER USER, CREATE ROLE, GRANT, REVOKE, and ALTER SYSTEM statements.
When a SQL statement includes CONTAINER = ALL and the current container is the CDB root, the
SQL statement affects all containers in the CDB, including all PDBs, application roots, and application
PDBs.
When a SQL statement includes CONTAINER = ALL and the current container is an application
root, the SQL statement affects all containers in the application container, including the application
root and all of the application PDBs that belong to the application root. The SQL statement does not
affect the CDB root or
any PDBs or application PDBs that do not belong to the current application root.
Only a common user or application common user with the commonly granted
SET CONTAINER privilege can run a SQL statement that includes CONTAINER = ALL.
A common user has a single identity and can log in to the CDB root, any application root, PDB, or application
PDB in which it has privileges. Some tasks, such as starting up a CDB instance, can be performed only by a
common user.
Other administrative tasks are the same for a CDB and a non-CDB. describes some of these tasks and provides
pointers to the relevant documentation.
To start a CDB instance, the current user must be a common user whose current container is the CDB root. When you open a
CDB, the CDB root is opened, but its other containers are mounted. Use the ALTER PLUGGABLE DATABASE statement
to modify the open mode of one or more containers.
2. Managing processes
A CDB has one set of background processes shared by the CDB root and all containers.
3. Managing memory
A CDB has a single system global area (SGA) and a single aggregate program global area (PGA). The memory required by a
CDB is the sum of the memory requirements for all of the containers that will be part of the CDB.
4. Managing security
You can create and drop common users, application common users, and local users in a CDB. You can also grant privileges
to and revoke privileges from these users.
You can also manage the CONTAINER_DATA attributes of common users and application common users. In addition, grant
the following roles to the appropriate users:
8. Managing the online redolog and the archived redo log files
A CDB has one online redo log and one set of archived redo log files.
9. Managing tablespaces
You can create, modify, and drop tablespaces and temporary tablespaces for the CDB root and for individual containers. You
can also specify a default tablespace, default tablespace type, and a default temporary tablespace for the CDB root. The CDB
root has its own set of Oracle-supplied tablespaces, such as the SYSTEM tablespace, and other containers have their own set
of Oracle-supplied tablespaces.
The CDB root has its own data files, and other containers have their own data files. In a CDB, you can manage data files and
temp files in basically the same way you would manage them for a non-CDB. However, the following exceptions apply to
CDBs:
A CDB can run in local undo mode or shared undo mode. Local undo mode means that every container in the CDB uses
local undo. Shared undo mode means that there is one active undo tablespace for a single-instance CDB, or for an Oracle
RAC CDB, there is one active undo tablespace for each instance.
In a CDB, the UNDO_MANAGEMENT initialization parameter must be set to AUTO, and an undo tablespace is required to
manage the undo data.
You can move data between containers using the same methods that you would use to move data between non-CDBs. For
example, you can transport the data or use Data Pump export/import to move the data
Using Oracle Managed files can simplify administration for both a CDB and a non-CDB.
Need to continue from 1630 (41-12) from 41.1.4 About Managing Database Objects in a
CDB
Demo
-----------
SYS_CONTEXT('USERENV','CON_NAME')
--------------------------------------------------------------------------------
CDB$ROOT
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
----
After you create pdb, it is in mounted mode, and its tatus is NEW. You can view the open_mode of a
pdb by querying the open_mode cllumn in the v$pdbs view. you can view the status of pdb by
querying the stats column of the cdb_pdbs or dba_pdbs
7 rows selected.
---
6 rows selected.
---
SQL> alter pluggable database m1pdb3 open;
7 rows selected.