Download Day 3 AND Day 4 Topics Privileges Enhancements Implementing

Day 3 AND Day 4 Topics
Privileges Enhancements
Implementing Separation of Duty for Database Administration Tasks
Using Database Privilege Analysis
Overview of Database Privilege Analysis
Granting the CAPTURE_ADMIN role to enable management of privilege captures
Creating and starting/stopping privilege captures
Viewing privilege profile data
Querying DBA_PRIV_CAPTURES
Using mandatory INHERIT PRIVILEGES privilege to execute invoker's rights procedure
Oracle Data Redaction
Overview of Oracle Data Redaction
Types of Masking Policies
Administering the EXEMPT REDACTION POLICY system privilege to enable a user to view
unmasked values
Managing Masking Policies
Best practices for defining policy expressions
Understanding Masking of Statements Containing Subqueries
Viewing Information About Masking Policies by Querying REDACTION_POLICIES and
REDACTION_COLUMNS
Monitoring DB Operations
Overview
Use cases
Current Tools
Define a DB operation
Monitoring: Bracketing an Operation
Monitoring the Progress of Operations
DB Operation Tuning
DB Operation Active Report
Real-Time ADDM and Compare Period Advisor
Emergency Monitoring
Real time ADDM
Use cases
Goals
Define Workload dimensions
Reported items
Root Causes
Requirements for a report
ADR and Network Enhancements
ADR file types
New File types
New File locations
New commands for ADRCI
Improve performance by Compression
Setup Compression
Privileges Enhancements
Implementing Separation of Duty for Database Administration Tasks
 For better separation of duty, Oracle Database now provides task-specific privileges to
handle standard administration duties for Oracle Recovery Manager (Oracle RMAN), Oracle
Data Guard, and Transparent Data Encryption.
 The new privileges are based on the least privilege principle, in which a user is granted only
the absolutely necessary privileges required to perform a specific function, and no more.
 This feature alleviates the need to unnecessarily grant the SYSDBA administrative privilege
for many tasks.
 Administrative privileges that a user acquired can be retrieved using V$PWFILE_USERS
dynamic view, which lists users in the password file.
 The use of administrative privileges is mandatorily audited.
Grants of Administrative Privileges to Users
 The administrative privileges must be provided to trusted users only.
 The users who have their names in non-ASCII characters cannot be supported using the
granted privilege when the oracle database is shut down but if the database instance is up, then
the authentication is supported.
Administrative Privileges
You must create a password file for the users who acquire the below privilges.
1) SYSDBA and SYSOPER
→ allows to perform variety of standard database operations such as atabase startups and
shutdowns, creating the server parameter file (SPFILE), or altering the database archive log.
2) SYSBACKUP
→ allows you to perform backup and recovery operations from either Oracle Recovery
Manager (RMAN) and or through SQL*Plus as listed below.
STARTUP
SHUTDOWN
ALTER DATABASE
ALTER SYSTEM
ALTER SESSION
ALTER TABLESPACE
CREATE CONTROLFILE
CREATE ANY DIRECTORY
CREATE ANY TABLE
CREATE ANY CLUSTER
CREATE PFILE
CREATE RESTORE POINT (including GUARANTEED restore points)
CREATE SESSION
CREATE SPFILE
DROP DATABASE
DROP TABLESPACE
DROP RESTORE POINT (including GUARANTEED restore points)
FLASHBACK DATABASE
RESUMABLE
UNLIMITED TABLESPACE
SELECT ANY DICTIONARY
SELECT ANY TRANSACTION
SELECT
X$ tables (that is, the fixed tables)
V$ and GV$ views (that is, the dynamic performance views)
APPQOSSYS.WLM_CLASSIFIER_PLAN
SYSTEM.LOGSTDBY$PARAMETERS
DELETE/INSERT
SYS.APPLY$_SOURCE_SCHEMA
SYSTEM.LOGSTDBY$PARAMETERS
EXECUTE
SYS.DBMS_BACKUP_RESTORE
SYS.DBMS_RCVMAN
SYS.DBMS_DATAPUMP
SYS.DBMS_IR
SYS.DBMS_PIPE
SYS.SYS_ERROR
SYS.DBMS_TTS
SYS.DBMS_TDB
SYS.DBMS_PLUGTS
SYS.DBMS_PLUGTSP
SELECT_CATALOG_ROLE
Note: SYSBACKUP privilege enables you to connect to the database even if the database is not
open.
3) SYSDG
→ allows to perform Data Guard operations.
→ use this privilege with either Data Guard Broker or the DGMGRL command-line
interface.
→ The SYSDG privilege enables the following operations:
STARTUP
SHUTDOWN
ALTER DATABASE
ALTER SESSION
ALTER SYSTEM
CREATE RESTORE POINT (including GUARANTEED restore points)
CREATE SESSION
DROP RESTORE POINT (including GUARANTEED restore points)
FLASHBACK DATABASE
SELECT ANY DICTIONARY
SELECT
X$ tables (that is, the fixed tables)
V$ and GV$ views (that is, the dynamic performance views)
APPQOSSYS.WLM_CLASSIFIER_PLAN
DELETE
APPQOSSYS.WLM_CLASSIFIER_PLAN
EXECUTE
SYS.DBMS_DRS
Note: The SYSDG privilege enables you to connect to the database even if it is not open.
5) SYSKM
→ allows to manage Transparent Data Encryption (TDE) wallet operations.
→ The SYSKM administrative privilege enables the following operations:
ADMINISTER KEY MANAGEMENT
CREATE SESSION
SELECT (only when database is open)
SYS.V$ENCRYPTED_TABLESPACES
SYS.V$ENCRYPTION_WALLET
SYS.V$WALLET
SYS.V$ENCRYPTION_KEYS
SYS.V$CLIENT_SECRETS
SYS.DBA_ENCRYPTION_KEY_USAGE
Note: SYSKM privilege enables you to connect to the database even if it is not open.
SQL> select * from v$PWFILE_USERS;
USERNAME
SYSDB SYSOP SYSAS
SYSBA SYSDG SYSKM
------------------------------ ----- ----- ----- ----- ----- ----- ---------SYS
TRUE
TRUE
FALSE
FALSE FALSE FALSE
SYSDG
FALSE FALSE FALSE
FALSE TRUE
FALSE
SYSBACKUP
SYSKM
FALSE FALSE
FALSE FALSE
FALSE
FALSE
TRUE
FALSE
FALSE
FALSE
FALSE
TRUE
CON_ID
0
1
1
1
Database Privilege Analysis
 This feature is used to help you increase the security of your applications and database
operations.
 It performs a dynamic analysis of privileges and roles that a user account or database uses
over time.
 Privilege analysis captures privileges used by database users and applications at runtime.
You then can revoke unused grants and other changes to better reflect the access a user
requires. This simplifies the work required to implement least privilege practice.
 It helps to reduce the attack surface of applications and increase operational security by
identifying used and unused privileges.
 Privilege analysis support is available from Oracle Enterprise Manager Cloud Control
12c Release 3 Plug-in Update 1 (12.1.0.3).
Overview
 Privilege analysis can be used to capture the privileges that have been exercised on precompiled database objects.
 Examples of these objects are PL/SQL packages, procedures, functions, views, triggers, and
Java classes and data.
Who is authorized to do this?
 DBMS_PRIVILEGE_CAPTURE package, which allows you to track the privileges being used,
making it much simpler to perform privilege analysis, which in turn allows you to revoke
unnecessary privileges and attain a least privilege state.
 CAPTURE_ADMIN role must be granted to use the DBMS_PRIVILEGE_CAPTURE package.
Types of Privilege Analysis
1) Role-based privilege use capture
You must provide a list of roles. If the roles in the list are enabled in the database session, then the
used privileges for the session will be captured.
2) Context-based privilege use capture
You must specify a Boolean expression only with the SYS_CONTEXT function. The used privileges
will be captured if the condition evaluates to TRUE.
3) Role- and context-based privilege use capture
You must provide both a list of roles that are enabled and a SYS_CONTEXT Boolean expression for
the condition. When any of these roles is enabled in a session and the given context condition is satisfied, then
privilege analysis starts capturing the privilege use.
4) Database-wide privilege capture
If you do not specify any type in your privilege analysis policy, then the used privileges in the
database will be captured, except those for the user SYS. (This is also referred to as unconditional analysis,
because it is turned on without any conditions.)
Benefits
 The privileges of the account that accesses a database should only be limited to the
privileges that are strictly required by the application.
 Development of Secure Applications.
Limitations
 You can enable only one privilege analysis policy at a time. The only exception is that you can enable
a database-wide privilege analysis policy at the same time as a non-database-wide privilege analysis
policy, such as a role or context attribute-driven analysis policy.
 You cannot analyze the privileges of the SYS user.
 Privilege analysis shows the grant paths to the privilege but it does not suggest which grant path to
keep.
 If the role, user, or object has been dropped, then the values that reflect the privilege captures for these
in the privilege analysis data dictionary views are dropped as well.
How Does a Multitenant Environment Affect Privilege Analysis?
 You can create and use privilege analysis policies in a multitenant environment.
 If you are using a multitenant environment, then you can create privilege analysis policies in either the
root or in individual PDBs.
 The privilege analysis policy applies only to the container in which it is created, either to the
privileges used within the root or to the privileges used within a PDB.

It cannot be applied globally throughout the multitenant environment.
Different Phases of Database Privilege Analysis






Create a privilege analysis policy. (CREATE_CAPTURE)
Enable it. (ENABLE_CAPTURE)
Wait for the required analysis period.
Disable the privilege analysis policy. (DISABLE_CAPTURE)
Analyze the results. (GENERATE_RESULT and query dictionary views)
Drop the policy if it, and the recorded data, is no longer needed. (DROP_CAPTURE)
Note: In a multitenant environment, the policies are container-specific.
1) CREATE_CAPTURE
The CREATE_CAPTURE procedure allows you to create privilege analysis policies with varying
degrees of granularity.
G_DATABASE
→ Analyzes all privilege usage on the database, except the SYS user. The ROLES and
CONDITION parameters are not needed.
G_ROLE
→ Analyzes all privilege usage by the roles specified in the ROLES parameter. Use the
ROLE_NAME_LIST function to specify the roles.
G_CONTEXT
CONDITION
→ Analyzes all privilege usage when the boolean expression specified in the
parameter evaluates to TRUE. Conditions can include combinations
of calls to the
SYS_CONTEXT.
G_ROLE_AND_CONTEXT
→ Analyzes all privilege usage when both the ROLES and CONDITION criteria are
true.
Examples of CREATE_CATPTURE
-- Connect to a privileged using in a PDB.
CONN / AS SYSDBA
ALTER SESSION SET CONTAINER = pdb1;
-- Whole database (type = G_DATABASE)
BEGIN
DBMS_PRIVILEGE_CAPTURE.create_capture(
name
=> 'db_pol',
type
=> DBMS_PRIVILEGE_CAPTURE.g_database
);
END;
/
-- One or more roles (type = G_ROLE)
BEGIN
DBMS_PRIVILEGE_CAPTURE.create_capture(
name
=> 'role_pol',
type
=> DBMS_PRIVILEGE_CAPTURE.g_role,
roles
=> role_name_list('DBA', 'RESOURCE')
);
END;
/
-- A user defined condition, when user is TEST (type = G_CONTEXT)
BEGIN
DBMS_PRIVILEGE_CAPTURE.create_capture(
name
=> 'cond_pol',
type
=> DBMS_PRIVILEGE_CAPTURE.g_context,
condition => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') = ''TEST'''
);
END;
/
-- Combination of roles and conditions (type = G_ROLE_AND_CONTEXT)
BEGIN
DBMS_PRIVILEGE_CAPTURE.create_capture(
name
=> 'role_cond_pol',
type
=> DBMS_PRIVILEGE_CAPTURE.g_role_and_context,
roles
=> role_name_list('DBA', 'RESOURCE'),
condition => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') IN (''TEST'',''EMP'')'
);
END;
/
Query to display information on the existing privilege capture policies
COLUMN name FORMAT A15
COLUMN roles FORMAT A20
COLUMN context FORMAT A30
SET LINESIZE 100
SELECT name,type,enabled,roles,context
FROM dba_priv_captures
ORDER BY name;
2) ENABLE_CAPTURE
The ENABLE_CAPTURE procedure is used to enable a capture policy. Typically, only one analysis policy
can be enabled at a time.
BEGIN
DBMS_PRIVILEGE_CAPTURE.enable_capture('db_pol');
DBMS_PRIVILEGE_CAPTURE.enable_capture('cond_pol');
END;
/
3) DISABLE_CAPTURE
As soon as you have waited a representative amount of time, the capture can be disabled using the
DISABLE_CAPTURE procedure.
BEGIN
DBMS_PRIVILEGE_CAPTURE.disable_capture('db_pol');
DBMS_PRIVILEGE_CAPTURE.disable_capture('cond_pol');
END;
/
4) GENERATE_RESULTS
Once a capture is complete, the GENERATE_RESULT procedure should be used to push the
captured information to the data dictionary views.
BEGIN
DBMS_PRIVILEGE_CAPTURE.generate_result('db_pol');
END;
/
5) DROP_CAPTURE
Only disabled policies can be dropped.
BEGIN
DBMS_PRIVILEGE_CAPTURE.drop_capture('cond_pol');
DBMS_PRIVILEGE_CAPTURE.drop_capture('db_pol');
DBMS_PRIVILEGE_CAPTURE.drop_capture('role_cond_pol');
DBMS_PRIVILEGE_CAPTURE.drop_capture('role_pol');
END;
/
Privilege Analysis Views
DBA_PRIV_CAPTURES
DBA_USED_OBJPRIVS
DBA_USED_OBJPRIVS_PATH
DBA_USED_PRIVS
DBA_USED_PUBPRIVS
DBA_USED_SYSPRIVS
DBA_USED_SYSPRIVS_PATH
DBA_USED_USERPRIVS
DBA_USED_USERPRIVS_PATH
DBA_UNUSED_OBJPRIVS
DBA_UNUSED_OBJPRIVS_PATH
DBA_UNUSED_PRIVS
DBA_UNUSED_SYSPRIVS
DBA_UNUSED_SYSPRIVS_PATH
DBA_UNUSED_USERPRIVS
DBA_UNUSED_USERPRIVS_PATH
Query to view the privileges used during the capture period
[DBA_USED_PRIVS, DBA_USED_SYSPRIVS or DBA_USED_SYSPRIVS_PATH views]
COLUMN username FORMAT A20
COLUMN sys_priv FORMAT A20
SELECT username, sys_priv
FROM dba_used_sysprivs
WHERE capture = 'dba_res_user_pol'
ORDER BY username, sys_priv;
How were these privileges granted to the user?
COLUMN username FORMAT A20
COLUMN used_role FORMAT A30
COLUMN sys_priv FORMAT A20
COLUMN path FORMAT A50
SET LINESIZE 200
SELECT username, sys_priv, used_role, path
FROM dba_used_sysprivs_path
WHERE capture = 'dba_res_user_pol'
ORDER BY username, sys_priv;
What object privileges were necessary?
COLUMN username FORMAT A20
COLUMN obj_priv FORMAT A8
COLUMN object_owner FORMAT A15
COLUMN object_name FORMAT A20
COLUMN object_type FORMAT A11
SELECT username, obj_priv, object_owner, object_name, object_type
FROM dba_used_objprivs
WHERE capture = 'dba_res_user_pol';
How were these object privileges granted to the user?
COLUMN username FORMAT A20
COLUMN obj_priv FORMAT A8
COLUMN object_owner FORMAT A15
COLUMN object_name FORMAT A20
COLUMN used_role FORMAT A20
COLUMN path FORMAT A30
SET LINESIZE 200
SELECT username, obj_priv, object_owner, object_name, used_role, path
FROM dba_used_objprivs_path
WHERE capture = 'dba_res_user_pol';
Querying DBA_PRIV_CAPTURES
This view lists the information about existing privilege analysis policies in the database.
col name FORMAT A15
col roles FORMAT A20
col context FORMAT A30
SET LINESIZE 100
select name,type,enabled,roles,context from dba_priv_captures order by name;
Enhanced System Privileges
1) SELECT ANY DICTIONARY
→ It does not allow you to query the following objects in the SYS schema now:
DEFAULT_PWD$
ENC$
LINK$
USER$
USER_HISTORY$
XS$VERIFIERS
New System Privileges
1) CREATE SQL TRANSLATION PROFILE
2) CREATE ANY SQL TRANSLATION PROFILE
3) ALTER ANY SQL TRANSLATION PROFILE
4) USE ANY SQL TRANSLATION PROFILE
5) DROP ANY SQL TRANSLATION PROFILE
→ allow you to manage SQL translation profiles.
6) EXEMPT REDACTION POLICY
→ allows you to bypass any existing Oracle Data Redaction policies.
7) INHERIT ANY PRIVILEGES
→ allows you to execute invoker's rights procedures with the privileges of the invoker.
8) KEEP DATE TIME
→ allows the SYSDATE and SYSTIMESTAMP functions to return their original values during
replay for Application Continuity.
9) KEEP SYSGUID
→ allows the SYS_GUID function to return its original value during replay for Application
Continuity.
10) LOGMINING
→ allows you to perform LogMiner operations in a multitenant container database (CDB)
11) PURGE DBA_RECYCLEBIN
→ allows you to remove all objects from the system-wide recycle bin.
12) SYSBACKUP
→ allows you to perform backup and recovery tasks.
13) SYSDG
→ allows you to manage Oracle Data Guard.
14) SYSKM
→ allows you to perform encryption key management.
15) TRANSLATE ANY SQL
→ allows you to translate SQL for any user.
New Object Privileges
1) ALTER
2) USE
→ These privileges authorize operations on SQL translation profiles.
3) INHERIT PRIVILEGES
→ a new type of object privilege that can be granted on a user to users and roles. It allows
invoker's rights procedures owned by the grantee to be executed with the privileges of the invoker when
the invoker is the user on whom this privilege is granted.
4) KEEP SEQUENCE
→ allows the sequence pseudo column NEXTVAL to retain its original value during replay for
Application Continuity.
5) TRANSLATE SQL
→ a new type of object privilege that can be granted on a user to users and roles. It allows the
grantee to translate SQL through the grantee's SQL translation profile for the user on whom this privilege
is granted.
Capture Privilege Usage
 The concept of "least privilege" is a common topic when discussing database security. It revolves
around making sure the minimum level of privileges are granted to a user to allow them to do their job.
Any unnecessary privileges represent a possible security loophole.
Using mandatory INHERIT PRIVILEGES privilege to execute invoker's rights procedure
 INHERIT PRIVILEGES and INHERIT ANY PRIVILEGES privileges are used to secure
invoker’s rights procedures.
 The INHERIT PRIVILEGES and INHERIT ANY PRIVILEGES privileges regulate the
privileges used when a user runs an invoker's rights procedure or queries a BEQUEATH
CURRENT_USER view that references an invoker's rights procedure.
 When a user runs an invoker's rights procedure, Oracle Database checks it to ensure that
the procedure owner has either the INHERIT PRIVILEGES privilege on the invoking user, or
if the owner has been granted the INHERIT ANY PRIVILEGES privilege.
SYNTAX
GRANT INHERIT PRIVILEGES ON USER invoking_user TO procedure_owner
where

invoking_user is the user who runs the invoker's rights procedure. This user must be a database
user account.

procedure_owner is the user who owns the invoker's rights procedure. This value must be a
database user account. As an alternative to granting the INHERIT PRIVILEGES privilege to the
procedure's owner, you can grant the privilege to a role that is in turn granted to the procedure.
Who needs this privilege?


Users or roles who own the invoker's rights procedures
Users or roles who own BEQUEATH CURRENT_USER views
Example
When user jward runs ebrown's invoker's rights procedure, there is an element of trust
involved. He must be assured that ebrown will not use the check_syntax procedure in a
malicious way when it accesses jward's privileges. The INHERIT
PRIVILEGES and INHERIT ANY PRIVILEGES privileges can help user jward control
whether user ebrown's procedure can have access to his (jward's) privileges. Any user can
grant or revoke the INHERIT PRIVILEGES privilege on themselves to the user whose
invoker's rights procedures they want to run. SYS users manage the INHERIT ANY
PRIVILEGES privilege
GRANT INHERIT PRIVILEGES ON USER jward TO ebrown;
This shows how the invoking user jward can grant user ebrown the INHERIT
PRIVILEGES privilege.
REVOKE INHERIT PRIVILEGES ON USER jward FROM ebrown;
This shows how user jward can revoke the use of his privileges from ebrown.
Note: By default, PUBLIC has the INHERIT PRIVILEGE privilege on new and upgraded user
accounts; the SYS user has the INHERIT ANY PRIVILEGES privilege.
Benefits
These two privileges is that they give invoking users control over who can access
their privileges when they run an invoker's rights procedure or query a BEQUEATH
CURRENT_USER view.
Oracle Data Redaction
 Redaction feature uses the DBMS_REDACT package to define redaction policies that give a greater
level of control and protection over sensitive data.
 It enables you to mask (redact) data that is returned from queries issued by applications.
 It is an Advanced Security option
Methods
1) Full redaction
→ You redact all of the contents of the column data. The redacted value returned to the querying
application user depends on the data type of the column. For example, columns of the NUMBER data
type are redacted with a zero (0), and character data types are redacted with a single space.
2) Partial redaction
→ You redact a portion of the column data. For example, you can redact a Social Security
number with asterisks (*), except for the last 4 digits.
3) Regular expressions
→ You can use regular expressions to look for patterns of data to redact. For example, you can
use regular expressions to redact email addresses, which can have varying character lengths. It is designed
for use with character data only.
4) Random redaction
→ The redacted data presented to the querying application user appears as randomly generated
values each time it is displayed, depending on the data type of the column.
5) No redaction
→ The None redaction type option enables you to test the internal operation of your redaction
policies, with no effect on the results of queries against tables with policies defined on them. You can use
this option to test the redaction policy definitions before applying them to a production environment.
Default redaction function_type setting is DBMS_REDACT.FULL.
When to use?
→ when you must disguise sensitive data that your applications and application users must access.
→ Oracle Data Redaction is particularly suited for call center applications and other applications that are
read-only.
Example
Oracle Data Redaction is ideal for situations in which you must redact specific characters out of the result
set of queries of Personally Identifiable Information (PII) returned to certain application users. For
example, you may want to present a U.S. Social Security number that ends with the numbers 4320 as *****-4320.
Benefits
 Different styles of redaction can be chosen.
 Data Redaction is well suited to environments in which data is constantly changing.
 Creation of Data Redaction policies can be done in one central location and easily manage them from
there.
 The Data Redaction policies enable you to create a wide variety of function conditions based on
SYS_CONTEXT values, which can be used at runtime to decide when the Data Redaction policies will
apply to the results of the application user's query.
Administering the EXEMPT REDACTION POLICY system privilege to enable a user to view
unmasked values
 You can exempt users from having Oracle Data Redaction policies applied to the data they
access. To do so, grant the users the EXEMPT REDACTION POLICY system privilege. Grant
this privilege to trusted users only.
 In addition to users who were granted this privilege, user SYS is also exempt from all Data
Redaction policies. The person who creates the Data Redaction policy is by default not
exempt from it, unless this person is user SYS or has the EXEMPT REDACTION
POLICY system privilege.
 Users who have the INSERT privilege on a table can insert values into a redacted column, regardless
of whether a Data Redaction policy exists on the table. Data Redaction only affects
SQL SELECT statements (that is, queries) issued by a user, and has no effect on any other SQL issued
by a user, including INSERT, UPDATE, or DELETE statements. (See the next bullet for exceptions to
this rule.)
 Users cannot perform a CREATE TABLE AS SELECT where any of the columns being selected
(source columns) is protected by a Data Redaction policy (and similarly, any DML operation where
the source is a redacted column), unless the user was granted the EXEMPT REDACTION
POLICY system privilege.
 The EXEMPT REDACTION POLICY system privilege is included in the DBA role, but this privilege
must be granted explicitly to users because it is not included in the WITH ADMIN
OPTION for DBA role grants. Users who were granted the DBA role are exempt from redaction policies
because the DBA role contains the EXP_FULL_DATABASE role, which is granted the EXEMPT
REDACTION POLICY system privilege.
 Data redaction is not support on columns of Large Data Types (BLOB, CLOB).
Dictionary Views
REDACTION_POLICIES
REDACTION_COLUMNS
REDACTION_VALUES_FOR_TYPE_FULL
Privilege to use Oracle Data Redaction Policies
Must have the EXECUTE privilege on the DBMS_REDACT PL/SQL package. To find the privileges
that a user has been granted, you can query the DBA_SYS_PRIVS data dictionary view.
Managing Masking Policies
The package used to create protection rules is called DBMS_REDACT. The package includes five procedures to
manage the rules and an additional procedure to change the default value for full redaction policy.
DBMS_REDACT.ALTER_POLICY – allows changes to existing policies.
DBMS_REDACT.DISABLE_POLICY – disables an existing policy.
DBMS_REDACT.DROP_POLICY – drop an existing policy.
DBMS_REDACT.ENABLE_POLICY – enables an existing policy.
DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES – change the default return value for full redaction.
You must restart the database to take effect.
1) Add a new Policy
BEGIN
DBMS_REDACT.add_policy(
object_schema => 'test',
object_name => 'payment_details',
column_name => 'card_no',
policy_name => 'redact_card_info',
function_type => DBMS_REDACT.full,
expression => '1=1'
);
END;
/
2) Alter an Existing Policy
BEGIN
DBMS_REDACT.alter_policy (
object_schema
=> 'test',
object_name
=> 'payment_details',
policy_name
=> 'redact_card_info',
action
=> DBMS_REDACT.modify_column,
column_name
=> 'card_no',
function_type
=> DBMS_REDACT.partial,
function_parameters => '1,1,12'
);
END;
/
3) Drop an Existing Policy
BEGIN
DBMS_REDACT.drop_policy (
object_schema => 'test',
object_name => 'payment_details',
policy_name => 'redact_card_info'
);
END;
/
4) Enabling a Policy
BEGIN
DBMS_REDACT.ENABLE_POLICY (
object_schema => 'mavis',
object_name => 'cust_info',
policy_name => 'redact_cust_user_ids');
END;
/
5) Disabling a Policy
BEGIN
DBMS_REDACT.DISABLE_POLICY (
object_schema => 'mavis',
object_name => 'cust_info',
policy_name => 'redact_cust_user_ids');
END;
/
How Oracle Data Redaction Affects Tables and Views
Create and populate the following table:
CREATE TABLE TABLE1 (TC1 VARCHAR2(20), TN1 NUMBER(10));
INSERT INTO TABLE1 VALUES ('5111-1111-1111-1118', 987654329);
Create the following views, which will constitute the view chain for table table1:
CREATE VIEW view1 (vc1, vn1) AS SELECT tc1, tn1 FROM table1;
CREATE VIEW view2 (vc2, vn2) AS SELECT vc1, vn1 FROM view1;
CREATE VIEW view3 (vc3, vn3) AS SELECT vc2, vn2 FROM view2;
Create the following policy on the table1 table, which changes the display of the tc1 column to random
values.
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema => 'NULL',
object_name => 'table1',
column_name => 'tc1',
policy_name => 't1pol',
function_type => DBMS_REDACT.RANDOM,
expression
=> '1=1');
END;
/
Query table1.tc1, view1.vc1, view2.vc2, and view3.vc3, and you will see that they all produce random
output, based on the t1pol Data Redaction policy.
For example:
SELECT vc3 FROM view3;
VC3
----------------------M,v]3(z+U4~e;0#3]<'
Create the following policy on view2, which changes the output of column vc2 to display no output at
all (that is, a blank space).
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema => 'NULL',
object_name => 'view2',
column_name => 'vc2',
policy_name => 'v2pol',
function_type => DBMS_REDACT.FULL,
expression
=> '1=1');
END;
/
Query views view2 and view3.
SELECT vc2 FROM view2;
SELECT vc3 FROM view3;
Both queries produce the same output (a blank space), which illustrates how for these views, policy v2pol
overrides the base table policy, t1pol.
Query table table1 and view view1.
SELECT tc1 FROM table1;
SELECT vc1 FROM view1;
Because table1 and view1 are lower in the chain, they are not affected by policy v2pol1. The output for
both remains as random values.
Create the following policy on view1, which redacts the first 5 digits of the numeric values in column
vn1 to 9.
BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema
=> 'NULL',
object_name
=> 'view1',
column_name
=> 'vn1',
policy_name
=> 'v1pol',
function_type
=> DBMS_REDACT.PARTIAL,
function_parameters => '9,1,5',
expression
=> '1=1');
END;
/
Query view view1:
SELECT vc1, vn1 FROM view1;
VC1
VN1
------------------------------------- ---------------:'F6`B<dB/N>hJDlJ7V
999994329
Here, view view1 is using two policies. Policy t1pol (on table table1) continues to redact column vc1, and
policy v1pol (on view view1) redacts column vn1.
Query view view2:
SELECT vc2, vn2 FROM view2;
VC2
VN2
------------------------------------- ---------------999994329
View view2 also uses two policies: the blank space for its column vc2 is generated by policy v2pol, and
the partial numeric redaction for vn2 comes from policy v1pol for view view1.
Query view view3:
SELECT vc3, vn3 FROM view3;
VC3
VN3
------------------------------------- ---------------999994329
Because view view3 has no direct policies, it uses the policy settings from both view1 and view2. Hence,
the output is the same as the output for view2.
Other features to make data more secure
1) Virtual Private Database (VPD) - Allows control access on both row and column levels by
dynamically adding a predicate to SQL statements issued against the database.
2) Oracle Label Security – Allows you to add user-defined values to table records combining it with
VPD to allow fine control of who sees what.
3) Database Vault – Data Redaction does not prevent privileged users (such as DBAs) from having
access to the data being protected. To solve this, you can make use of Database Vault.
Monitoring DB Operations
 A database operation is a set of database tasks defined by end users or application
code such as a SQL statement or PL/SQL function, a batch job, or extract, transform,
and load (ETL) processing. You can define, monitor, and report on database operations.
 To explicitly monitor composite operations made up of a variety of SQL statements and
PL/SQL calls containing SQL.
 The DBMS_SQL_MONITOR package provides the API for this functionality, as well as
rehousing some of the subroutines previously found in the DBMS_SQLTUNE package.
 This functionality requires Enterprise Edition and the Diagnostics & Tuning option.
Real-Time SQL Monitoring Updates
In Oracle 12C, the REPORT_SQL_MONITOR, REPORT_SQL_MONITOR_LIST routines
have been moved from the DBMS_SQLTUNE package to the DBMS_SQL_MONITOR
package.
Real-Time SQL Database Operation Monitoring
 To monitor a series of SQL and PL/SQL calls containing SQL and group them together as a
composite database operation.
 Real-Time SQL Monitoring is a feature of the Oracle Database Tuning Pack.
DBMS_SQL_MONITOR package
BEGIN_OPERATION (Attributes)
database
created.
DBOP_NAME : A user-defined name for the composite database operation.
DBOP_EID : An optional unique identifier for the current execution of the composite
operation. If it is NULL, a unique execution identifier is
FORCED_TRACKING : When set to the constant FORCE_TRACKING (Y), the
operation is
tracked. When set to NO_FORCE_TRACKING
(N), the default, the
operation is only tracked if it has
consumed 5 seconds of CPU or I/O
time.
ATTRIBUTE_LIST : An optional comma-separated list of name-value pairs of attributes
to
restrict the calls that are monitored during the operating
period.
END_OPERATION (Attributes)
DBOP_NAME
DBOP_EID → Both are mandatory
Example
DROP TABLE t1 PURGE;
DROP TABLE t2 PURGE;
CREATE TABLE t1 AS
SELECT level AS id,
'Description for ' || level AS description
FROM dual
CONNECT BY level <= 1000000;
CREATE TABLE t2 AS
SELECT level AS id,
'Description for ' || level AS description
FROM dual
CONNECT BY level <= 1000000;
Begin an operation with forced tracking
VARIABLE l_dbop_eid NUMBER;
BEGIN
:l_dbop_eid := DBMS_SQL_MONITOR.begin_operation (
dbop_name
=> 'db_op_1',
dbop_eid
=> :l_dbop_eid,
forced_tracking => DBMS_SQL_MONITOR.force_tracking
);
END;
/
Perform an operation that combines references to T1 and T2
BEGIN
FOR cur_rec IN (SELECT * FROM t1) LOOP
NULL;
END LOOP;
FOR cur_rec IN (SELECT * FROM t2) LOOP
NULL;
END LOOP;
END;
/
End the operation
BEGIN
DBMS_SQL_MONITOR.end_operation (
dbop_name
dbop_eid
);
END;
/
=> 'db_op_1',
=> :l_dbop_eid
To check the operations monitored using V$SQL_MONITOR view.
SET LINESIZE 200
SELECT dbop_name, dbop_exec_id, status
FROM v$sql_monitor
WHERE username = 'TEST';
DBOP_NAME
DBOP_EXEC_ID STATUS
------------------------------ ------------ ------------------db_op_1
3 DONE
db_op_1
2 DONE
db_op_1
1 DONE
Generation of a report using REPORT_SQL_MONITOR routine
SET LONG 1000000
SET LONGCHUNKSIZE 1000000
SET LINESIZE 1000
SET PAGESIZE 0
SET TRIM ON
SET TRIMSPOOL ON
SET ECHO OFF
SET FEEDBACK OFF
SPOOL /host/report_sql_monitor.htm
SELECT DBMS_SQL_MONITOR.report_sql_monitor(
dbop_name => 'db_op_1',
type
=> 'HTML',
report_level => 'ALL') AS report
FROM dual;
SPOOL OFF
REPORT_SQL_MONITOR_LIST
SET LONG 1000000
SET LONGCHUNKSIZE 1000000
SET LINESIZE 1000
SET PAGESIZE 0
SET TRIM ON
SET TRIMSPOOL ON
SET ECHO OFF
SET FEEDBACK OFF
SPOOL /host/report_sql_monitor_list.htm
SELECT DBMS_SQL_MONITOR.report_sql_monitor_list(
type
=> 'HTML',
report_level => 'ALL') AS report
FROM dual;
SPOOL OFF
REPORT_SQL_DETAIL
It is present in DBMS_SQLTUNE package only from oracle 11g.
Views
V$SQL_MONITOR
V$SQL_PLAN_MONITOR
Types of DB Operations
1) Simple
→ Simple SQL monitoring starts monitoring automatically when it runs in parallel or has
consumed at least 5 seconds of CPU or I/O time in a single execution.
2) Complex
→ It is an activity between two defined points in time in a database session.
→ Only one composite database operation at a time can run in a database session.
Why Monitoring?
1) Tracking and reporting
2) Monitoring execution progress
3) Monitoring resource usage
4) Tuning for response time
Enabling Monitoring of Database Operations
 Real-time database operations monitoring is enabled by default when the STATISTICS_LEVEL
initialization parameter is either set to TYPICAL or ALL.
 CONTROL_MANAGEMENT_PACK_ACCESS → DIAGNOSTIC+TUNING (default) enables
monitoring of database operations.
DB Operation Tuning
We can monitor database operations using Enterprise Manager Database Express and tune the
SQL according to the inputs present over there.
Usecases
1) Simple Database Operation Use Cases
 A frequently executed SQL statement is executing more slowly than normal. You must identify the
root cause of this problem.
 A database session is experiencing slow performance.
 A parallel SQL statement is taking a long time. You want to determine how the server processes are
dividing the work.
2) Composite Database Operation Use Cases
 A periodic batch job containing many SQL statements must complete in a certain number of hours,
but took twice as long as expected.
 After a database upgrade, the execution time of an important batch job doubled. To resolve this
problem, you must collect enough relevant statistical data from the batch job before and after the upgrade,
compare the two sets of data, and then identify the changes.
 Packing a SQL tuning set (STS) took far longer than anticipated. To diagnose the problem, you need
to know what was being executed over time. Because this issue cannot be easily reproduced, you need to
monitor the process while it is running.
Advantages of Real Time Database Operation Monitoring
 RTDOM helps you monitor batch jobs and send alerts when the time planned to execute the batch job
is exceeded.
 It helps you find the expensive SQL Statements.
 Diagnose changes by comparing current job execution with the previous executions.
 Monitor and compare executions times after a database upgrade.
Real-Time ADDM and Compare Period Advisor
ADDM
 ADDM analyzes the contents of the Automatic Workload Repository (AWR) to identify
potential performance bottlenecks and attempts to perform root cause analysis of them.
 In addition to the existing ADDM functionality, Oracle Database 12c introduced Real-Time
ADDM, which identifies potential performance problems as they happen, analyzes them and
stores reports, allowing up-to-the-minute diagnosis of performance problems.
 The manageability monitor (MMON) process kicks in every 3 seconds and checks the
performance statistics that are currently in memory. If it notices any potential performance
issues, it triggers a real-time ADDM analysis run, creates a report and stores it in the Automatic
Workload Repository (AWR). The stored reports can be seen in the DBA_HIST_REPORTS
view.
Generation of ADDM reports
 Real-time ADDM reports are generated using the "rtaddmrpt.sql" and "rtaddmrpti.sql" scripts
in the "$ORACLE_HOME/rdbms/admin" directory.
 Inputs required for the report are report_id and report_name. (default duration:60 mins)
Package used for Real Time ADDM
 DBMS_ADDM.REAL_TIME_ADDM_REPORT Function produces a real-time ADDM
report for ADDM-related activity for the last five minutes.
 It doesn't return a formatted real-time ADDM report, just some data in XML format can be
queried using the below.
SET LONG 1000000 LONGCHUNKSIZE 1000000
SET LINESIZE 1000 PAGESIZE 0
SET TRIM ON TRIMSPOOL ON
SET ECHO OFF FEEDBACK OFF
SELECT DBMS_ADDM.real_time_addm_report FROM dual;
COMPARE_DATABASES
 The COMPARE_DATABASES function produced a HTML or XML report comparing two
time periods of the same database or two different databases.
 When comparing two databases, all AWR data must reside locally.
 If the BASE_DBID and COMP_DBID parameters are omitted or set to NULL, the current
database is assumed.
 The REPORT_TYPE parameter determines if the report is in HTML or XML format.
Examples,
SET LONG 1000000 LONGCHUNKSIZE 1000000
SET LINESIZE 1000 PAGESIZE 0
SET TRIM ON TRIMSPOOL ON
SET ECHO OFF FEEDBACK OFF
SPOOL /tmp/addm_compare_db_report.html
SELECT DBMS_ADDM.compare_databases (
base_begin_snap_id => 1962,
base_end_snap_id => 1964,
comp_begin_snap_id => 1970,
comp_end_snap_id => 1972,
report_type
=> 'HTML') AS report
FROM dual;
SPOOL OFF
SPOOL /tmp/addm_compare_db_report.xml
SELECT DBMS_ADDM.compare_databases (
base_begin_snap_id => 1962,
base_end_snap_id => 1964,
comp_begin_snap_id => 1970,
comp_end_snap_id => 1972,
report_type
=> 'XML') AS report
FROM dual;
SPOOL OFF
COMPARE_INSTANCES
 The COMPARE_INSTANCES function produced a HTML or XML report comparing two
time periods of the same instance or two different instances.
 This is especially useful for comparing RAC instances.
 When comparing two instances from different databases, all AWR data must reside locally.
 If the BASE_DBID and COMP_DBID parameters are omitted or set to NULL, the current
database is assumed.
 The BASE_INSTANCE_ID and COMP_INSTANCE_ID parameters specify the instances to
be compared.
 The REPORT_TYPE parameter determines if the report is in HTML or XML format.
Examples,
SET LONG 1000000 LONGCHUNKSIZE 1000000
SET LINESIZE 1000 PAGESIZE 0
SET TRIM ON TRIMSPOOL ON
SET ECHO OFF FEEDBACK OFF
SPOOL /tmp/addm_compare_inst_report.html
SELECT DBMS_ADDM.compare_instances (
base_instance_id => 1,
base_begin_snap_id => 1962,
base_end_snap_id => 1964,
comp_instance_id => 1,
comp_begin_snap_id => 1970,
comp_end_snap_id => 1972,
report_type
=> 'HTML') AS report
FROM dual;
SPOOL OFF
SPOOL /tmp/addm_compare_inst_report.xml
SELECT DBMS_ADDM.compare_instances (
base_instance_id => 1,
base_begin_snap_id => 1962,
base_end_snap_id => 1964,
comp_instance_id => 1,
comp_begin_snap_id => 1970,
comp_end_snap_id => 1972,
report_type
=> 'XML') AS report
FROM dual;
SPOOL OFF
Real Application Testing comparison functions
1) COMPARE_CAPTURE_REPLAY_REPORT
→ Compares the capture to the replay and produces a Compare Period ADDM report,
highlighting the differences between the two.
2) COMPARE_REPLAY_REPLAY_REPORT
→ Compares two replays to each other and produces Compare Period ADDM report,
highlighting the differences between the two.
Emergency Monitoring
 The Emergency Monitoring feature of Enterprise Manager Cloud Control 12c is an evolution
of Memory Access Mode from Grid Control 11g, allowing you to access in-memory statistics.
 The "Emergency Monitoring" menu option is available under the "Performance" section once
you've navigated to the target database in EM 12C.
Views
V$SESS_TIME_MODEL
V$SESSTAT
V$SQLSTATS
V$ACTIVE_SESSION_HISTORY
DBA_BLOCKERS
DBA_WAITERS
DBIO_EXPECTED Parameter
Set the value one time for all subsequent ADDM executions.
For example, if the measured value is 8000 microseconds, then execute the following PL/SQL
code as the SYS user:
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(
'ADDM', 'DBIO_EXPECTED', 8000);
Note: Typical values for hard drives are between 5000 and 20000 microseconds.
Real-Time ADDM Analysis
 Real-Time ADDM helps you to analyze and resolve problems in unresponsive or hung
databases that traditionally require you to restart the database.
 Real-Time ADDM runs through a set of predefined criteria to analyze the current
performance of the database.
 After analyzing the problem, Real-Time ADDM helps you to resolve the identified issues—
such as deadlocks, hangs, shared pool contention, and other exception situations—without
having to restart the database.
Real-Time ADDM Connection Modes
1) Normal Connection
→ In this mode, Real-Time ADDM performs a normal JDBC connection to the database.
This mode is intended to perform extensive performance analysis of the database when some
connectivity is available.
2) Diagnostic connection
→ In this mode, Real-Time ADDM performs a latch-less connection to the database.
This mode is intended for extreme hang situations when a normal JDBC connection is not
possible.
Real-Time ADDM Triggers
Real-Time ADDM proactively detects transient database performance issues and it runs
automatically every 3 seconds and uses in-memory data to diagnose any performance spikes in
the database.
Real-Time ADDM triggers an analysis automatically when a performance problem is detected,
as described in the following steps:
 Every 3 seconds, the manageability monitor process (MMON) performs an action to obtain
performance statistics without lock or latch.
 The MMON process checks these statistics and triggers a Real-Time ADDM analysis if any
of the issues listed in Table 7-1 are detected.

The MMON slave process creates the report and stores it in the AWR.
ADR and Network Enhancements
ADR Enhancements
 ADR is a simple file-based (directory structured) repository that contains diagnostic data generated
from Oracle. It is a collection of items such as trace files, dumps, alert logs, etc. that can be used by
administrators to investigate problems and the health of the database.
 ADR is the new unified directory structure that will hold all diagnostic data from all Oracle products
and components—simplifying the search and correlation of information across all aspects of a single or
multiple database instance.
 ADR will put together all the diagnostic data to particular incident and store this packaged
information in an ADR subdirectory created uniquely for that incident. The process flow for when an
incident occurs is something like this:
1. Entry is made in the alert log
2. Incident is sent to Oracle Enterprise Manager
3. Diagnostic data is gathered about the incident
4. Incident ID is assigned
5. Incident and gathered data is stored in ADR subdirectory
In oracle 12c the Automatic Diagnostic Repository contains a new log directory with 2
subdirectories :
DDL
Debug
DDL log
 When you active the DDL logging in Oracle 12c using enable_ddl_logging=true, Oracle writes all
DDL operations into the specific DDL log instead of writting it to the alert log.
 The parameter enable_ddl_logging is container-specific, so you will need to enable/disable it
independently in the root container and any PDBs.
 The DDL logging feature is part of the Oracle Change Management Pack.
 Data will be logged in the location $ADR_HOME/home/ddl (log.xml)
$ADR_BASE/diag/rdbms/{DB-name}/{SID}/log/ddl_{SID}.log
$ADR_BASE/diag/rdbms/{DB-name}/{SID}/log/ddl/log.xml
Debug Log

The debug log contains unusual events which are not sufficiently critical to be recorded as incidents.
 This information is not destinated directly to the DBA and is mainly created to help the Oracle
Support in case of problem.
New ADRCI Command (SHOW LOG)
 ADRCI is a command line utility that serves as the interface between you the administrator and the
automatic diagnostic repository (ADR).
 The SHOW LOG command has been added to ADRCI to give visibility of the new DDL and debug
logs.
SYNTAX:
SHOW LOG [-l ] [-p ] [-term] [ [-tail [num] [-f]] ]
Where
[-l ] → Output specified log, otherwise all messages from all diagnostic logs under the current
ADR Home are displayed.
[-tail [num] [-f]] → Output last part of the log messages and output latest messages as the log
grows.
If num is not specified,the last 10 messages are displayed.
If "-f" is specified, new data will append at the end as new log messages are generated.This
option requires that a log name be supplied via -l option.
[-term] → Direct results to terminal. If this option is not specified, the results will be open in an
editor.
Network-Related enhancements
Oracle 12C introduces several network parameters used to optimize the network configuration.
Network Compression
If you are licensed for the Advanced Compression Option, you can activate the network compression to
reduce the network bandwidth used by your database.
The advanced compression is setup using the following parameters:
SQLNET.COMPRESSION : can be set to ON or OFF depending if you want to activate the
compression or no.
SQLNET.COMPRESSION_LEVELS : can be set to LOW or HIGH, the first one uses a low
compression but consumes less CPU, the second uses the
maximum compression but requires more CPU.
SQLNET.COMPRESSION_THRESHOLD: this parameter defines the minimum data size needed to
trigger the compression.
SDU Size
 The session data unit (SDU) is the size of data packets sent accross the network, when Oracle send
data accross the network, it first compresses the data into buffers of the size of the SDU.
 In Oracle 12c you can set the DEFAULT_SDU_SIZE in the sqlnet.ora file. You should change the
default SDU size only when your application average requested messages are greater than the default
SDU (8KB)
Sir Questions???
1) How memory can be partitioned in PDBs when it inherits from CDB (Memory Management)
2) Additional areas to look up in CDB or PDB
3) Where the PDB memory parameters are stored?