About Administering a CDB

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.

1. About the Current Container

2. About Administrative Tasks in a CDB
3. About Using Manageability Features in a CDB
4. About Managing Database Objects in a CDB
5. About Flashing Back a PDB
6. About Restricting PDB Users for Enhanced Security

1. About the Current Container

The data dictionary in each container in a CDB is separate, and the current container is the container whose data
dictionary is used for name resolution and for privilege authorization. The current container can be the CDB
root, an application root, a PDB, or an application PDB. Each session has exactly one current container at any
point in time, but it is possible for a session to switch from one container to another.

2. About Administrative Tasks in a CDB

Common users perform administrative tasks for a CDB.

3. About Using Manageability Features in a CDB

For each of Oracle Database's manageability features in a CDB, it is important to understand the data location
and the data visibility.

4. About Managing Database Objects in a CDB

In a CDB, different containers can contain different database objects.

5. About Flashing Back a PDB

You can use the FLASHBACK PLUGGABLE DATABASE statement to return a PDB to a past time or system
change number (SCN).

6. About Restricting PDB Users for Enhanced Security

There are several ways to restrict PDB users for enhanced security. A PDB lockdown profile restricts the
features and options available to users in a particular PDB. The PDB_OS_CREDENTIAL initialization
parameter can specify a unique operating system user for a PDB to limit operating system access. Also, when
the PATH_PREFIX and CREATE_FILE_DEST clauses are specified during PDB creation, they
limit file system access.

About the Current Container

The data dictionary in each container in a CDB is separate, and the current container is the container whose data
dictionary is used for name resolution and for privilege authorization. The current container can be the CDB
root, an application root, a PDB, or an application PDB. Each session has exactly one current container at any
point in time, but it is possible for a session to switch from one container to another.

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:

SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

You can access a container in various ways in a CDB. For example, you can use the SQL*Plus CONNECT
command, and you can use an ALTER SESSION SET CONTAINER statement to switch the container of the
current session.

The following rules apply to the current container in a CDB:

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

2. About Administrative Tasks in a CDB

Common users perform administrative tasks for a CDB.

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.

1. Starting up a CDB instance

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:

• Grant the CDB_DBA role to CDB administrators.

• Grant the PDB_DBA role to application container administrators and PDB administrators.

5. Monitoring errors and alerts

A CDB has one alert log for the entire CDB. The name of an application container, PDB, or application PDB is included in
records in trace files, when appropriate.

6. Managing diagnostic data

In a CDB, you can use the Oracle Database fault diagnosability infrastructure and the Automatic Diagnostic Repository
(ADR).

7. Managing control files

A CDB has one control file. "Managing Control Files

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.

10. Managing data files and temp files

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:

 You can limit the amount of storage used by the

data files for a container by using the STORAGE clause in a CREATE PLUGGABLE DATABASE or ALTER PLUGGABLE
DATABASE statement.

 There is a default temporary tablespace for the

CDB root and for individual containers.

11. Managing undo

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.

12. Moving data between containers

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

13. Using Oracle Managed Files

Using Oracle Managed files can simplify administration for both a CDB and a non-CDB.

14 Using a standby database

Oracle Data Guard can configure a physical standby or a logical standby of a CDB. Data Guard operates on the entire CDB,
not on individual containers in a CDB

Need to continue from 1630 (41-12) from 41.1.4 About Managing Database Objects in a
CDB

Demo
-----------

About the Current Container

----------------------------------------

SQL> SELECT SYS_CONTEXT ('USERENV', 'CON_NAME') FROM DUAL;

SYS_CONTEXT('USERENV','CON_NAME')
--------------------------------------------------------------------------------
CDB$ROOT

[oracle@vb12m1 admin]$ sqlplus system/oracle123@m1cdb

SQL*Plus: Release 12.1.0.1.0 Production on Sat May 13 19:51:58 2017

Copyright (c) 1982, 2013, Oracle. All rights reserved.

Last Successful login time: Sat May 13 2017 19:51:47 +05:30

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

SQL> select name,open_mode,con_id,cdb from v$database;

NAME OPEN_MODE CON_ID CDB

--------- -------------------- ---------- ---
M1CDB READ WRITE 0 YES

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

SQL> select con_id,name,open_mode from v$containers;

CON_ID NAME OPEN_MODE

---------- ------------------------------ ----------
1 CDB$ROOT READ WRITE
2 PDB$SEED READ ONLY
3 M1PDB1 MOUNTED
4 M1PDB2 MOUNTED
 5 M1PDB3 MOUNTED
6 M1PDB4 MOUNTED
7 M1PDB5 MOUNTED

7 rows selected.

---

select pdb_id,pdb_name,status from dba_pdbs

PDB_ID PDB_NAME STATUS

---------- ---------- -------------
3 M1PDB1 NORMAL
2 PDB$SEED NORMAL
4 M1PDB2 NORMAL
5 M1PDB3 NEW
6 M1PDB4 NEW
7 M1PDB5 NEW

6 rows selected.

---
SQL> alter pluggable database m1pdb3 open;

Pluggable database altered.

SQL> select con_id,name,open_mode from v$containers;

CON_ID NAME OPEN_MODE

---------- ------------------------------ ----------
1 CDB$ROOT READ WRITE
2 PDB$SEED READ ONLY
3 M1PDB1 MOUNTED
4 M1PDB2 MOUNTED
5 M1PDB3 READ WRITE
6 M1PDB4 MOUNTED
7 M1PDB5 MOUNTED

7 rows selected.