Presentation day5 oracle12c

1

ORACLE DATABASE 12C

Connection to cdb and pdb Users, Grants & Role

(Reference – Oracle Documentation )

Check detailed contents on http://dbaboss.com/

2

How to connect CDB database• Connecting to a Container Database (CDB)

• Connecting to the root of a container database is the same as that of any previous database instance. On the database server you can use OS Authentication.

• $ export ORACLE_SID=cdb1• $ sqlplus / as sysdba• SQL*Plus: Release 12.1.0.1.0 Production on Mon Aug 26 15:29:49 2013• Copyright (c) 1982, 2013, Oracle. All rights reserved.• 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• You can connect to other common users in similar way.• SQL> CONN system/password• Connected.


3

• The V$SERVICES views can be used to display available services from the database.

• COLUMN name FORMAT A30• SELECT name, pdb• FROM v$services• ORDER BY name;• NAME PDB• ------------------------------ ------------------------------• SYS$BACKGROUND CDB$ROOT• SYS$USERS CDB$ROOT• cdb1 CDB$ROOT• cdb1XDB CDB$ROOT• pdb1 PDB1• pdb2 PDB2


4

• The lsnrctl utility allows you to display the available services from the command line.• $ lsnrctl service• LSNRCTL for Linux: Version 12.1.0.1.0 - Production on 20-MAY-2014 09:01:34• Copyright (c) 1991, 2013, Oracle. All rights reserved.• Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))• Services Summary...• Service "cdb1" has 1 instance(s).• Instance "cdb1", status READY, has 1 handler(s) for this service...• Handler(s):• "DEDICATED" established:0 refused:0 state:ready• LOCAL SERVER• Service "cdb1XDB" has 1 instance(s).• Instance "cdb1", status READY, has 1 handler(s) for this service...• Handler(s):• "D000" established:0 refused:0 current:0 max:1022 state:ready• DISPATCHER • (ADDRESS=(PROTOCOL=tcp)(HOST=ol6-121.localdomain)(PORT=21196))• Service "pdb1" has 1 instance(s).• Instance "cdb1", status READY, has 1 handler(s) for this service...• Handler(s):• "DEDICATED" established:0 refused:0 state:ready• LOCAL SERVER• Service "pdb2" has 1 instance(s).• Instance "cdb1", status READY, has 1 handler(s) for this service...• Handler(s):• "DEDICATED" established:0 refused:0 state:ready• LOCAL SERVER• The command completed successfully


5

• Connections using services are unchanged from previous versions.

• SQL> -- EZCONNECT• SQL> CONN system/password@//localhost:1521/cdb1• Connected.• SQL>

• SQL> -- tnsnames.ora• SQL> CONN system/password@cdb1• Connected.• SQL>• The connection using a TNS alias requires an entry in the

"$ORACLE_HOME/network/admin/tnsnames.ora" file, such as the one shown below.

• CDB1 =• (DESCRIPTION =• (ADDRESS = (PROTOCOL = TCP)(HOST = your host name )(PORT = 1521))• (CONNECT_DATA =• (SERVER = DEDICATED)• (SERVICE_NAME = cdb1)• )• )


6

• In Oracle Database 12c, we can still find this information from V$INSTANCE. What if I connect to a container database and then issue an ALTER SESSION command to move into a different container, i.e. as PDB? Will I get the name of the PDB that I move into from the V$INSTANCE view or do I essential to look somewhere else? Lets take a look.

• • Connect to the container database as normal and use the

V$INSTANCE view to see where I’m at.• • [oracle@home_1]$ sqlplus / as sysdba SQL> select

instance_name, version, status, con_id from v$instance; INSTANCE_NAME VERSION STATUS CON_ID----------------- ----------------- ------------ ----------ora12cb

12.1.0.1.0 OPEN 0Check detailed contents on

http://dbaboss.com/

7

• Lets transfer into a PDB. I have quite a few PDBs created, lets just use PDB1.• • SQL> alter session set container=PDB1; Session altered. • Look after I actually move containers? How can I tell? As an alternative of

selecting INSTANCE_NAME from V$INSTANCE; we have two new SHOW commands that will provide us the information we are looking for. These command are quite simple (SHOW CON_ID & SHOW CON_NAME).

• • SQL> show con_id • CON_ID------------------------------3• SQL> show con_name CON_NAME-• -----------------------------PDB1 • Now that we are confident that we are in PDB1, lets take a look at the

V$INSTANCE view again. What you will notice is that V$INSTANCE delivers us with information relative to the container database (CDB). It only makes sense that the V$INSTANCE would return CDB information. So, how do we identify items related to the pluggable database (PDB) without the SHOW commands

• New View V$PDB.


8

• Displaying the Current Container

• The SHOW CON_NAME and SHOW CON_ID commands in SQL*Plus display the current container name and ID respectively.

• SQL> SHOW CON_NAME

• CON_NAME• ------------------------------• CDB$ROOT• SQL>

• SQL> SHOW CON_ID

• CON_ID• ------------------------------• 1• SQL>• They can also be retrieved using the SYS_CONTEXT function.

• SELECT SYS_CONTEXT('USERENV', 'CON_NAME')• FROM dual;

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

• SQL>

• SELECT SYS_CONTEXT('USERENV', 'CON_ID')• FROM dual;

• SYS_CONTEXT('USERENV','CON_ID')• --------------------------------------------------------------------------------• 1

• SQL>


9

Connecting to a Pluggable Database (PDB)

• Direct connections to pluggable databases must be made using a service. Each pluggable database automatically registers a service with the listener. This is how any application will connect to a pluggable database, as well as administrative connections.

• SQL> -- EZCONNECT• SQL> CONN system/password@//localhost:1521/pdb1• Connected.• SQL>• SQL> -- tnsnames.ora• SQL> CONN system/password@pdb1• Connected.• SQL>• The connection using a TNS alias requires an entry in the "$ORACLE_HOME/network/admin/tnsnames.ora" file, such as the one

shown below.• PDB1 =• (DESCRIPTION =• (ADDRESS = (PROTOCOL = TCP)(HOST = your host name.localdomain)(PORT = 1521))• (CONNECT_DATA =• (SERVER = DEDICATED)• (SERVICE_NAME = pdb1)• )• )• PDB users with the SYSDBA, SYSOPER, SYSBACKUP, or SYSDG privilege can connect to a closed PDB. All other PDB users can only

connect when the PDB is open. As with regular databases, the PDB users require the CONNECT SESSION privilege to enable connections.


10

• The use of SET CONTAINER avoids the need to create a new connection from scratch.• • If there is an existing connection to a PDB / CDB$root, the same connection can be used to connect to desired PDB / CDB$root.• • – Connect to CDB • [oracle@e12 ~]$ sqlplus system/oracle@cdb1

• CDB$ROOT@CDB1> sho con_name

• CON_NAME• ------------------------------• CDB$ROOT • – Check the PID for the process created on the operating system• [oracle@e12 ~]$ ps -ef |grep LOCAL |grep -v grep

• oracle 23271 1 0 10:23 ? 00:00:00 oraclecdb1 (LOCAL=NO) • – Change the container to PDB1 using Set container• CDB$ROOT@CDB1> alter session set container=pdb1;

• sho con_name

• CON_NAME• ------------------------------• PDB1 • – Check that the operating system PID remains the same as earlier connection is reused and a new connection has not been created• [oracle@em12 ~]$ ps -ef |grep LOCAL |grep -v grep

• oracle 23271 1 0 10:23 ? 00:00:00 oraclecdb1 (LOCAL=NO)


11

• – Switch the container back to cdb$root using connect• CDB$ROOT@CDB1> conn system/oracle@cdb1• sho con_name

• CON_NAME• ------------------------------• CDB$ROOT • – Check that a new operating system PID has been created

as a new connection has been created• [oracle@e12 ~]$ ps -ef |grep LOCAL |grep -v grep

• oracle 23409 1 0 10:29 ? 00:00:00 oraclecdb1 (LOCAL=NO)


12

User and roles


13

• Local User• A user in a non-CDB maps to a local user in a PDB.• • A local user is defined in the PDB’s own data dictionary—and so is not known outside of• that PDB.• • A local user can connect only to the PDB where it is defined.• • A local user is specific to a particular PDB and owns a schema in this PDB.• • According to the privileges granted, a user can work on the application data within the• PDB or with other PDBs’ application using database links. Moreover, there cannot be any• local users defined in the root.

• Common User• • A common user is defined in the root’s data dictionary.• • Only common users can be defined in the root: Creating a common user allows the CDB• administrator to create at once a user that is replicated in each PDB.• • A common user is known, not only where it is defined in the root, but also in every PDB• that belongs to the CDB.• • A common user can perform administrative tasks specific to the root or PDBs, such as• plugging and unplugging PDBs, starting up the CDB, or opening a PDB when granted the• proper privileges


14Check detailed contents on

http://dbaboss.com/

15

• Local Roles• A role in a non-CDB maps to a local role in a PDB. A local role is defined in the PDB’s own• data dictionary—and so it is not known outside of that PDB and can only be used within its• PDB.

• Common Roles• Besides the local role, you can create common roles that are defined in every container. This• way, it is easy to create at once a role that is replicated in all PDBs. It is at the creation time• that you specify the nature of the role: local or common. Common roles as well as common• users can only be created in the root by common users. Moreover, there cannot be any local• roles defined in the root. All Oracle-supplied predefined roles are common roles.

• Local and Common Privileges• The privileges are commonly referred to as local or common privileges, but to be more precise• a privilege is either granted locally with the clause CONTAINER=CURRENT or commonly with the• clause CONTAINER=ALL.• The same rule applies to roles: common roles can be granted commonly or locally to common• users or roles. Common roles may contain privileges that apply across the CDB, that is,• commonly granted for all containers, and can also contain locally granted privileges that apply• only to an individual PDB, whereas local roles do not contain any commonly granted privileges


16

Create Common Users

• When creating a common user the following requirements must all be met.• •You must be connected to a common user with the CREATE USER privilege.• •The current container must be the root container.• •The username for the common user must be prefixed with "C##" or "c##" and contain only ASCII or EBCDIC characters.• •The username must be unique across all containers.• •The DEFAULT TABLESPACE, TEMPORARY TABLESPACE, QUOTA and PROFILE must all reference objects that exist in all

containers.• •You can either specify the CONTAINER=ALL clause, or omit it, as this is the default setting when the current container is the

root.• • The following example shows how to create common users with and without the CONTAINER clause from the root container.

• CONN / AS SYSDBA

• -- Create the common user using the CONTAINER clause.• CREATE USER c##test_user1 IDENTIFIED BY password1 CONTAINER=ALL;• GRANT CREATE SESSION TO c##test_user1 CONTAINER=ALL;

• -- Create the common user using the default CONTAINER setting.• CREATE USER c##test_user2 IDENTIFIED BY password1;• GRANT CREATE SESSION TO c##test_user2;


17

Create Local Users• When creating a local user the following requirements must all be met.• •You must be connected to a user with the CREATE USER privilege.• •The username for the local user must not be prefixed with "C##" or "c##".• •The username must be unique within the PDB.• •You can either specify the CONTAINER=CURRENT clause, or omit it, as this is the default setting when the current

container is a PDB.• • The following example shows how to create local users with and without the CONTAINER clause from the root container.• CONN / AS SYSDBA• -- Switch container while connected to a common user.• ALTER SESSION SET CONTAINER = pdb1;

• -- Create the local user using the CONTAINER clause.• CREATE USER test_user3 IDENTIFIED BY password1 CONTAINER=CURRENT;• GRANT CREATE SESSION TO test_user3 CONTAINER=CURRENT;

• -- Connect to a privileged user in the PDB.• CONN system/password@pdb1

• -- Create the local user using the default CONTAINER setting.• CREATE USER test_user4 IDENTIFIED BY password1;• GRANT CREATE SESSION TO test_user4;• If a local user is to be used as a DBA user, it requires the PDB_DBA role granted locally to it.


18

Create Common Roles• Similar to users described previously, roles can be common or local. All Oracle-supplied roles are common and

therefore available in the root container and all PDBs. Common roles can be created, provided the following conditions are met.

• •You must be connected to a common user with CREATE ROLE and the SET CONTAINER privileges granted commonly.• •The current container must be the root container.• •The role name for the common role must be prefixed with "C##" or "c##" and contain only ASCII or EBCDIC

characters.• •The role name must be unique across all containers.• •The role is created with the CONTAINER=ALL clause• • The following example shows how to create a common role and grant it to a common and local user.


• -- Create the common role.• CREATE ROLE c##test_role1;• GRANT CREATE SESSION TO c##test_role1;

• -- Grant it to a common user.• GRANT c##test_role1 TO c##test_user1 CONTAINER=ALL;

• -- Grant it to a local user.• ALTER SESSION SET CONTAINER = pdb1;• GRANT c##test_role1 TO test_user3;• Only common operations can be granted to common roles. When the common role is granted to a local user, the

privileges are limited to that specific user in that specific PDB.


19

• Create Local Roles

• Local roles are created in a similar manner to pre-12c databases. Each PDB can have roles with matching names, since the scope of a local role is limited to the current PDB. The following conditions must be met.

• •You must be connected to a user with the CREATE ROLE privilege.• •If you are connected to a common user, the container must be set to the local PDB.• •The role name for the local role must not be prefixed with "C##" or "c##".• •The role name must be unique within the PDB.• • The following example shows how to create local a role and grant it to a common user and a local user.


• -- Switch container.• ALTER SESSION SET CONTAINER = pdb1;

• -- Alternatively, connect to a local or common user• -- with the PDB service.• -- CONN system/password@pdb1

• -- Create the common role.• CREATE ROLE test_role1;• GRANT CREATE SESSION TO test_role1;

• -- Grant it to a common user.• GRANT test_role1 TO c##test_user1;

• -- Grant it to a local user.• GRANT test_role1 TO test_user3;• When a local role are granted to common user, the privileges granted via the local role are only valid when the common user has its container set

to the relevant PDB.


20

• Granting Roles and Privileges to Common and Local Users

• The rules for granting privileges and roles can seem a little confusing at first. Just remember, if you connect to a PDB and only deal with local users and roles, everything feels exactly the same as pre-12c databases. It's only when you start to consider the scope of common users and roles that things become complicated.

• The basic difference between a local and common grant is the value used by the CONTAINER clause.

• -- Common grants.• CONN / AS SYSDBA

• GRANT CREATE SESSION TO c##test_user1 CONTAINER=ALL;• GRANT CREATE SESSION TO c##test_role1 CONTAINER=ALL;• GRANT c##test_role1 TO c##test_user1 CONTAINER=ALL;

• -- Local grants.• CONN system/password@pdb1• GRANT CREATE SESSION TO test_user3;• GRANT CREATE SESSION TO test_role1;• GRANT test_role1 TO test_user3;



21

Shared and Non-Shared Objects

22

• In a non-CDB, all objects are local objects. Common objects are being introduced in 12c to

• avoid having to store redundant representations of data and metadata across a CDB and to

• simplify the process of upgrading a CDB. Shared objects exist only in Oracle-supplied

• schemas.• A shared object may be metadata-linked or object-linked.• • Metadata-linked objects store metadata about dictionary objects only in the

root. Each• PDB has a private data copy of an object pointing to a metadata link stored in the

root.• • An object-linked object and its data resides in the root only and is shared by all

PDBs.• Example• The list of audit actions is in SYS.AUDIT_ACTIONS table in the root, thereby

making• AUDIT_ACTIONS accessible in each separate container


23Check detailed contents on http://dbaboss.com/

24

• DBA dictionary views providing information within PDB:

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


25

• For backwards-compatibility, DBA views show the same results in a PDB as in a non-CDB:• DBA_OBJECTS shows the objects that exist in the PDB from which you run the query. This• implies, in turn, that though the PDB and the root have separate data dictionaries, each data• dictionary view in a PDB shows results fetched from both of these data dictionaries. The• DBA_xxx views in the root shows, even in a populated CDB, only the Oracle-supplied system,• as is seen in a freshly-created non-CDB. This is another advantage of the new architecture.• To support the duties of the CDB administrator, a new family of data dictionary views is• supported with names like CDB_xxx. Each DBA_xxx view has a CDB_xxx view counterpart• with an extra column, Con_ID, that shows from which container the listed facts originate.

Query• the CDB_xxx views from the root and from any PDB. The CDB_xxx views are useful when• queried from the root because the results from a particular CDB_xxx view are the union of

the• results from the DBA_xxx view counterpart over the root and all currently open PDBs. When

a• CDB_xxx view is queried from a PDB, it shows only the information that it shows in its• DBA_xxx view counterpart. If you connect to the root and query CDB_USERS, you get the list

of users, common and local, of each container. Now if you query DBA_USERS, you get the list ofcommon users (you know that in the root, only common users exist). Now if you connect to aPDB, and query CDB_USERS or DBA_USERS, you get the same list of users, common and local, of the PDB.

• The same backward-compatibility principle applies also to each of the familiar v$views.• Oracle


26

Impacts• One character set for all PDBs (Unicode recommended)• • PDB initialization parameters but a single SPFILE• • No PDB qualified database object names• – SELECT * FROM HR:apps.tab1• – Use DB Links: SELECT * FROM apps.tab1@HR• • Oracle Data Guard at CDB level• • Oracle Database Vault per PDB only• • One master key per PDB to encrypt PDB data• • Unified audit both at CDB and PDB level• • Oracle Scheduler• • Oracle GoldenGate• • Oracle Streams• • Oracle XStream both at CDB and PDB level


27

• There is only one character set and one single spfile for the CDB. The different parameter values of each PDB are stored in a dictionary table.

• • There is no PDB qualified object name. To access an object in another PDB, use a DB link.

• • Oracle Data Guard works exactly the same in a CDB as it does in non-CDBs. This feature is not to be available on a per-PDB basis. Open of a physical standby CDB will always open the root in READ ONLY mode and this also means that no PDB may be open in a mode other than READ ONLY.

• • In Oracle Database Vault, each PDB has its own Database Vault metadata. DatabaseVault constructs like realms are isolated within a PDB.

• • Each PDB has its own master key used to encrypt data in the PDB. The master key must be transported from the source database wallet to the target database wallet when a PDBis moved from one host to another. For column encryption, each PDB maintains its own

• ENC$ which is not a metadata-linked object.


Data & Analytics

Presentation day5 oracle12c