1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

The following is intended to outline our general product

direction. It is intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality,
and should not be relied upon in making purchasing
decisions. The development, release, and timing of any
features or functionality described for Oracle's products
remains at the sole discretion of Oracle.

2 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Oracle Database 12c
Multitenant Administration
Name
Title
Organization
 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

4 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

5 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Multitenant Architecture
Components of a Multitenant Container Database (CDB)

PDBs

Root
Pluggable Databases (PDBs)
CDB

6 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Multitenant Architecture

 Multitenant architecture can currently

support up to 252 PDBs
Database  A PDB feels and operates identically to a
Link
non-CDB
 You cannot tell, from the viewpoint of a
connected client, if you’re using a PDB or
a non-CDB

10 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Multitenant Architecture
 A Container Database (CDB) includes the following Containers:
– Root: The root, named CDB$ROOT, stores Oracle-supplied metadata and
common users
– Seed (PDB$SEED): The seed, named PDB$SEED, is a template that you can
use to create new PDBs
– PDBs: A PDB appears to users and applications as if it were a non-CDB
 Every CDB contains exactly one root, exactly one seed PDB and zero or
more user-created PDBs

11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Container Database Architecture

12 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Files in PDBs
 Each PDB has its own set of tablespaces
including SYSTEM and SYSAUX
 PDBs share UNDO, REDO and control
files
 By default the CDB has a single TEMP
tablespace but PDBs may create their
own

13 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

14 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Services in a CDB
 Clients must connect to PDBs using services
 The “current” container is the container a user is connected with
 When a CDB is created, a service with the name of the CDB gets
automatically created
– Also gets registered with the listener
 When a PDB is created, a service with the PDB name automatically gets
created and started inside the CDB
– Configures the listener to listen for this service
– This service cannot be managed by the user/administrator

15 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Services in a CDB

16 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Why Use Services?
In a Single Instance environment the default service may be enough
 The default service of the CDB is started when
sqlplus <user>/<pwd>@MySCAN/crmsvc the CDB is started. This is an admin-service.
 The default service of the PDB is available
for connectivity as soon as PDB is mounted
with the startup of the CDB.
 If an application uses the default service for
connectivity, it can connect to this service as
soon as it is registered with the listener.

cdb1

HR PDB HRg1wc CRMSVC

rudolph
CRM PDB Default service

17 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Why Use Services?
Using the default service is not enough when moving PDBs around
 PDBs provide location independency (plug /
unplug / clone), but exist within an environment
 Moving PDBs between environments
may require changing names of PDBs.
 Use services to provide a “dial in number” for
your application. If the PDB moves to another
location, you can keep the number.
– This requires uniqueness of service names

cdb1 cdb1

HR PDB CRMSVC
rudolph cupid NewHR
CRM PDB HRg1wc
PDB

18 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Services in a CDB
 Do not use the default PDB service for applications
– As a best practice, create a new, user-defined service
 You may create, modify, or remove a service with a PDB property in the
following ways:
– If a single-instance database is being managed by Oracle Restart or Oracle
RAC database is being managed by Oracle Clusterware
 Use Server Control (SRVCTL) utility
– Else, use DBMS_SERVICE
 Each database service name must be unique in a CDB
– Also, in all CDBs that are reached through a specific listener

19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Connecting to CDBs and PDBs
 Connect to the CDB Root container (CDB$ROOT) using:
– Service Name (Easy Connect Naming method or TNS Names alias)
 Easy Connect: @<host>:<port>/<service>
– E.g. sqlplus SYS/oracle@localhost:1521/cdb1 AS SYSDBA
– OS Authentication
 E.g. sqlplus / AS SYSDBA
 Connect to the PDB using:
– Service Name, using Easy Connect or TNS Names alias

20 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Connecting to CDBs and PDBs
 Two new and useful commands to validate the container you are
connected to:
 SHOW CON_ID: Retrieves the Container ID
– 1 for Root (CDB$ROOT)
– 3 or greater for user created PDBs
 SHOW CON_NAME: Retrieves the Container Name
– CDB$ROOT (for Root)

21 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

22 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Common Data Dictionary
Before 12.1: Oracle and user meta data intermingle over time

ta ta ta
r Da y Da Da
se
r r ar
y r ry
U na se n se na
io U io U io
D ic t ic t ic t
D D
ta ta ta
Da Da Da

ta ta ta
Da Da Da
ta ta ta
Me Me Me

Database Created Tables, Code, Data added Mature Database

23 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Oracle Data and User Data

 Multitenant fix:
Horizontally-
partitioned data
dictionary
 Only Oracle system
OBJ$ TAB$ SOURCE$ EMP DEPT
definition remains
 Oracle and customer
… … metadata
intermingled

24 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Horizontally Partitioned Data Dictionary
 Oracle-supplied
OBJ$ TAB$ SOURCE$ EMP DEPT
objects such as
views, PL/SQL, etc.,
… … are shared across
all PDBs using
object links
 PDB uses Metadata
OBJ$ TAB$ SOURCE$
links to access the
metadata about
… dictionary objects
 In-database
virtualization
25 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
 Container Data Objects
 Container Data Objects are table or view containing data pertaining to
multiple containers and possibly the CDB as a whole
 Has mechanisms to restrict data visible to specific common users to one
or more containers
 Examples of container data objects are Oracle-supplied views whose
names begin with V$ and CDB_

26 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Data Dictionary Views
CDB_xxx All objects in the multitenant container database across all PDBs
DBA_xxx All of the objects in a container or pluggable database
ALL_xxx Objects accessible by the current user
USER_xxx Objects owned by the current user

SQL> SELECT view_name FROM dba_views WHERE view_name like 'CDB%';

– CDB_pdbs: All PDBS within CDB

– CDB_tablespaces: All tablespaces within CDB
– CDB_users: All users within CDB (common and local)
 DBA dictionary views providing information within PDB:
SQL> SELECT table_name FROM dict WHERE table_name like 'DBA%';

27 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Performance Views
 When queried from a PDB, queries against v$ views will show only
information pertaining to the PDB or the CDB as a whole
 When queried from ROOT, v$ views and CDB_ views can return rows for
more than one container
– Rows returned by these views have an additional con_id column
– These views are known as container_data views
– The container_data setting for the common user issuing the query will
determine what rows are aggregated and made visible

28 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Performance Views
 The following views behave differently from other V$ views:
– V$SYSSTAT
– V$SYS_TIME_MODEL
– V$SYSTEM_EVENT
– V$SYSTEM_WAIT_CLASS
 When queried from the root, these views return instance-wide data, with 0
in the CON_ID column
– Returns the same data when queries from other containers as well
 The following views can return specific data for each container in a CDB:
V$CON_SYSSTAT, V$CON_SYS_TIME_MODEL,
V$CON_SYSTEM_EVENT, and V$CON_SYSTEM_WAIT_CLASS

29 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

30 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Users  Local users are the successors for
customer-created users in a non-CDB
 A local user is defined only in a PDB
 A local user can administer a PDB
 A common user is defined in the root
and is represented in every PDB
 A common user can log into any PDB
where it has “Create Session” and can
therefore administer a PDB
 The Oracle system is owned by
common users

31 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Common Users and Privileges
Authorization is checked in the same way as in pre-12.1
 A common user can be granted privileges locally in a PDB (or root)
and therefore differently in each container
 A common user can, alternatively, be granted a system privilege
commonly – the grant is made in root and every PDB, present and future
 Authorization is checked in the container where the SQL is attempted
considering only the privileges that the user has in that container

32 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Common Users and Privileges

 All user-created common user names must begin with c## or C##
– Oracle-supplied common users like SYS and SYSTEM are exempted
 Every common user is uniquely named across all containers
 The schemas for a common user can differ in each container
 Best practice: Don’t create objects in common user’s schema

33 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Common Roles

 Each container in a CDB holds common and local roles

– The common roles are created from the root
– Automatically replicated in each PDB except the seed PDB
– The name assigned to a common role must start with C##
 Common roles can be granted commonly
– The grant operation is replicated in each PDB except the seed PDB
 Common roles can be granted locally
– The grant operation is performed in the container where the operation takes
place

34 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Local Roles

 Local roles are created in a PDB they need to exist in

 Local roles can only be granted locally in the PDB where they were
created
– They are not visible to the other PDBs of the same CDB

35 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Roles and Privileges
 Common and local privileges can be granted to common and local users
and roles
 The privileges are not common or local
– They become common or local privileges based on the way they are granted
– Using the clause CONTAINER=ALL makes it a privilege common

36 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Agenda

 Multitenant Architecture
 Services and Connections
 Data Dictionary Architecture
 Security in CDB
 Managing a CDB

37 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Startup/Shutdown the Container Database
 Similar to shutting down a non-CDB instance
– All PDBs will automatically be closed
– The CDB instance must be MOUNTED or OPEN
 The CDB startup operation is similar to a non-CDB startup
– By default, PDBs will NOT automatically start
 The user must have appropriate privileges
– A common user connected with SYSDBA, SYSOPER, SYSBACKUP, or
SYSDG privileges

38 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 OPEN/CLOSE a PDB
 Modify the open mode of a PDB by:
– ALTER PLUGGABLE DATABASE [OPEN|CLOSE]
– STARTUP & SHUTDOWN (when run within the PDB)
 You may run ALTER PLUGGABLE DATABASE [OPEN|CLOSE] from the
root or the PDB
– Requires a PDB Name, or ALL or ALL EXCEPT when run from the root
– When open mode is not specified for OPEN:
 READ WRITE is the default
 If PDB is a physical standby, READ ONLY is the default

39 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 OPEN/CLOSE Modes in V$PDBS
 V$PDBS displays information about the PDBs (name, open mode, etc.)
– Displays all PDBs when accessed from root using a common user
– Contains OPEN_MODE column

40 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 STARTUP Trigger
 The default behavior when a CDB is started is that all user-defined PDBs
are in MOUNTED state i.e. closed.
 This behavior can be changed by a database AFTER STARTUP trigger
– AFTER STARTUP trigger is a database event trigger
– The user creating the trigger should have ADMINISTER DATABASE
TRIGGER system privilege
– The trigger will only fire after the startup event on the database
CREATE OR REPLACE TRIGGER AFTER_STARTUP
AFTER STARTUP ON DATABASE
BEGIN
EXECUTE IMMEDIATE 'ALTER PLUGGABLE DATABASE ALL OPEN';
END AFTER_STARTUP;

41 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Managing CDB Services
 Stopping a PDB service does not change the open mode of the PDB
 When you unplug or drop a PDB, the services of the unplugged or
dropped PDB are not removed automatically
– You can remove these services manually
 You cannot modify the PDB property of a service with the
DBMS_SERVICE package
– However, you can remove and add

42 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Considerations for Tablespaces in CDB
 When a tablespace is created in a container, the tablespace gets
associated with that container
 A CDB has one active undo tablespace
– or one active for each RAC instance
 There is one default temporary tablespace for an entire CDB
– The root and the PDBs can use this temporary tablespace
– You may create additional TEMP tablespaces in root or PDB
 A permanent tablespace can be associated with only one container
– Each container in a CDB must have its own default permanent tablespace

43 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Using ALTER DATABASE Statement
 ALTER DATABASE statement works the same in a CDB and a non-CDB
– Most ALTER DATABASE statements affect the entire CDB
 ALTER DATABASE can be run
– At the whole CDB level
– At Root level
– At PDB level (using ALTER PLUGGABLE DATABASE)

44 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Using ALTER SYSTEM Statement
 ALTER SYSTEM SET statement can be used at the container level
 A CDB uses an inheritance model for initialization parameters
– PDBs inherit initialization parameter values from the root
– The inheritance property for such parameters is either true or false
– When set to false, the PDB does not inherit the root's value
– You can change the inheritance property to FALSE by running the ALTER
SYSTEM SET statement when ISPDB_MODIFIABLE is TRUE for the
parameter in the V$SYSTEM_PARAMETER view
 When run from the root, use the CONTAINER clause to specify the
PDB(s) inheriting the parameter

45 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

46 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
47 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.