* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Day 3 AND Day 4 Topics Privileges Enhancements Implementing
Survey
Document related concepts
Microsoft Access wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Oracle Database wikipedia , lookup
ContactPoint wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Clusterpoint wikipedia , lookup
Transcript
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?