Showing posts with label Function/Procedure. Show all posts
Showing posts with label Function/Procedure. Show all posts

Wednesday, July 10, 2024

Column Level Audit in Oracle 23ai

Oracle Database support auditing at column level and Audit actions at column level introduced in Oracle 23ai Database. Using this feature, you can Audit column level for tables and views.

Before Oracle 21c and before you can audit at table level. Oracle deprecated traditional auditing in Oracle 21c, and it is desupported from Oracle 23ai.

In Oracle 23ai user can perform audit actions at individual column level by creating audit policies. You can audit action on a Tableau or view column using “CREATE AUDIT POLICY” Statement

For example,
  • Audit all actions on a table
    SQL> CREATE AUDIT POLICY aud_all_act_emp ACTIONS ALL ON SCOTT.EMP;

When using ACTIONS ALL user should be cautious. Because enabling on an online transaction processing (OLTP) workload. Will lead large number of audit records.
  • Audit action on a column
    SQL> CREATE AUDIT POLICY aud_col_bon_act_emp ACTIONS SELECT (BONOUS) ON                SCOTT.EMP;

Users can query UNIFIED_AUDIT_TRAIL dictionary view to view audit events information

SQL> SELECT OBJECT_NAME,SQL_TEXT FROM UNIFIED_AUDIT_TRAIL WHERE OBJECT_NAME = 'EMP';

OBJECT_NAME     SQL_TEXT
------------------------ ----------------------------------------------------------------
EMP                         SELECT BONUS FROM EMP WHERE EMPNO=123

You can also audit actions on SYS objects using CREATED AUDIT POLICTY statement.

SQL> CREATE AUDIT POLICY aud_col_sys_obje ACTIONS SELECT ON SYS.TABLES;

To audit recursive actions, use ONLY TOPLEVEL clause in the CREATE AUDIT POLICY statement.

User can audit PL/SQL packages, functions, procedures and triggers, pls consider below points
  • You can audit standalone PL/SQL packages, functions and procedures 
  • Auditing a PL/SQL package will audit all functions and procedures within the package. You cannot audit individual producers and functions within the PL/SQL package. 
  • Auditing all executions will enable auditing all triggers, functions and procedures within PL/SQL packages.
  • Auditing EXECUTE operation on a PL/SQL stored procedure or function, will determine the success or failure of the operation auditing purpose.
For a list of Object-level Database action audit options, you can refer Oracle documentation here

Thanks & Regards,
https://oracleracexpert.com

Friday, July 21, 2023

Flashback Data Archive enhancements in Oracle 12c

Flashback feature uses Automatic Undo Management for historical and metadata transactions. Flashback Data archive (FDA) feature introduced in Oracle 11g for undo-based flashback operations, and it is configured using retention time. Flashback data archive supported for multitenant (12.1.0.2 and above versions) as well using local or shared undo configuration.

Oracle 12c (12.1.0.1) has below enhancements in FDA

  • Data Hardening
  • User context tracking
Data Hardening This feature helps to associate set of tables for a specific application, so that you can enable Flashback Data archive for all those tables in a single command. Use DMBS_FLASHBACK_ARCHIVE.REGISTER_APPLICATION to register an application

You can create new application using REGISTER_APPLICATION

SQL> Begin
DBMS_FLASHBACK_ARCHIVE.register_application(
application_name => 'ORACLERACEXPERT',
flashback_archive_name => 'FDA1');
end;
/


You can add tables to the application using ADD_TABLE_TO_APPLICATION procedure

SQL> Begin
DBMS_FLASHBACK_ARCHIVE.ADD_TABLE_TO_APPLICATION (
application_name=> 'ORACLERACEXPERT', 
table_name=> 'EMP' , 
schema_name -> 'USER1');
end;
/


SQL> Begin
DBMS_FLASHBACK_ARCHIVE.ADD_TABLE_TO_APPLICATION (
application_name=> 'ORACLERACEXPERT', 
table_name=> 'DEPT' , 
schema_name -> 'USER1');
end;
/


You can remove the tables using REMOVE_TABLE_FROM_APPLICATION procedure from

The application will not enable automatically, use ENABLE_APPLICATION procedure to enable Flashback Data Archive for all tables in the specified application.

SQL> Begin
DBMS_FLASHBACK_ARCHIVE.enable_application(
application_name => 'ORACLERACEXPERT');
end;
/


To disable the application use disable_application procedure

SQL> Begin
DBMS_FLASHBACK_ARCHIVE.disable_application(
application_name => 'ORACLERACEXPERT');
end;
/


User context tracking - By enabling this feature it is easy to track which user made what changes to the table.

Use DMBS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL procedure to Set the user content level and procedure DMBS_FLASHBACK_ARCHIVE.GET_SYS_CONTEXT procedure To Access the context

There are 3 options depending upon how much user context needs to save
ALL – The entire SYS_CONTEXT is stored
TYPICAL – The user context is stored
NONE- Nothing

For ex: - To set context level to ALL
SQL> DBMS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL ( level=>‘ALL’);

You can get the XID from the archive table

SQL> select XID from SYS_FBA_HIST_93222;
XID
----------------
05000A0B7040000


Now with XID you can get the context information using dbms_flashback_archive.get_sys_context procedure


SQL> begin
dbms_output.put_line(dbms_flashback_archive.get_sys_context ('05000A0B7040000', 'USERENV', 'SESSION_USER'));
dbms_output.put_line(dbms_flashback_archive.get_sys_context ('05000A0B7040000', 'USERENV', 'HOST'));
dbms_output.put_line(dbms_flashback_archive.get_sys_context ('05000A0B7040000', 'USERENV', 'MODULE'));
end;

/
USER1
SRVHOST
SQL*Plus

You can get all Transactions ID using below query

SQL> select empno, empname, VERSIONS_XID
from EMP order by empno;

EMPNO EMPNAME VERSIONS_XID
----------- --------------- ---------------------
1              ORARAC    05000A0B7040000


You can use SYS_FBA_CONTEXT_AUD to get context information for each transaction.

There are many Flashback data archive view available and to get the list of all views run below query

SQL> SET PAGESIZE 1000
SQL> SET LINESIZE 600
SQL> COLUMN owner FORMAT A10
SQL> COLUMN table_name FORMAT A25

SQL> SELECT owner, table_name FROM dba_tables WHERE table_name LIKE '%FBA%';
 
OWNER       TABLE_NAME
--------------  -------------------------
SYS              SYS_FBA_FA
SYS              SYS_FBA_TSFA
SYS              SYS_FBA_TRACKEDTABLES
SYS              SYS_FBA_PARTITIONS
SYS              SYS_FBA_USERS
SYS              SYS_FBA_BARRIERSCN
SYS              SYS_FBA_DL
SYS              SYS_FBA_CONTEXT
SYS              SYS_FBA_CONTEXT_AUD
SYS              SYS_FBA_CONTEXT_LIST
SYS              SYS_FBA_APP
SYS              SYS_FBA_APP_TABLES
SYS              SYS_FBA_COLS
SYS              SYS_FBA_PERIOD
SYS              SYS_MFBA_STAGE_RID
SYS              SYS_MFBA_TRACKED_TXN
SYS              SYS_MFBA_NROW
SYS              SYS_MFBA_NCHANGE
SYS              SYS_MFBA_NTCRV


You can refer below Oracle Doc for best practices

FDA - Flashback Data Archive Usage and Best Practices (Doc ID 2370465.1)

Flashback Data Archive provides many benefits for maintaining historic data against tracked tables. The FDA helps to perform undo-based flashback operations for an extended period and take advantage of this feature.

Monday, January 30, 2023

DBMS_BLOCKCHAIN_TABLE package in Oracle 21c

You can use DBMS_BLOCKCHAIN_TABLE package for maintenance of blockchain table. Using this package you can perform the below tasks.
  • Sing a row that is added into the table
  • Verify the integrity of rows and hash column.
  • Generate signature and signed digest
  • Delete rows in a blockchain table that are beyond retention defined.
Here are the few subprograms (procedures and functions) used with DBMS_BLOCKCHAIN_TABLE package
  • DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS By using this procedure you can verify the integrity of rows and hash column. You can also verify the Signatures as well
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
low_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
high_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
instance_id IN NUMBER DEFAULT NULL,
chain_id IN NUMBER DEFAULT NULL,
number_of_rows_verified OUT NUMBER,
verify_signature IN BOOLEAN DEFAULT TRUE);

For ex:-
DECLARE
Rows_Verify NUMBER;
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS(
schema_name => 'BCUSER',
table_name => 'BLOCKCHAIN_T1',
number_of_rows_verified => Rows_Verify);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(Rows_Verify) || ' rows deleted');
END;
/
  • DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST – By using this procedure you can generate a signature and signed digest.
DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
signed_bytes IN OUT BLOB,
signed_rows_indexes OUT ORABCTAB_ROW_ARRAY_T,
schema_certificate_guid OUT RAW,
signature_algo IN NUMBER default SIGN_ALGO_DEFAULT)
RETURN RAW;
  • DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN - By using this procedure you can verify the integrity of rows created between specified time period X1 and X2
DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN(
signed_bytes_latest IN BLOB,
signed_bytes_previous IN BLOB,
number_of_rows_verified OUT NUMBER);

  • DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS - By using this procedure you can delete rows that are beyond retention period
For ex:-
DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
before_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL,
number_of_rows_deleted OUT NUMBER);

Ex:- The below example deletes the rows beyond the retention period, you can limit the number of rows deletion by using before_timestamp

DECLARE
Del_Rows NUMBER;
DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS(
schema_name => 'BCUSER',
table_name => 'BLOCKCHAIN_T1',
before_timestamp => NULL,
number_of_rows_deleted => Del_Rows);
DBMS_OUTPUT.PUT_LINE(TO_CHAR(Del_Rows) || ' rows deleted');
END;
/
  • DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_SIGNATURE - By using this procedure you can determine the data format for row content to compute the signature.
DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_SIGNATURE(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
instance_id IN NUMBER,
chain_id IN NUMBER,
sequence_id IN NUMBER,
data_format IN NUMBER,
row_data IN OUT BLOB);
  • DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_HASH - By using this procedure you can determine the data format for row content to compute hash value
DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_HASH(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
instance_id IN NUMBER,
chain_id IN NUMBER,
sequence_id IN NUMBER,
data_format IN NUMBER,
row_data IN OUT BLOB);
  • DBMS_BLOCKCHAIN_TABLE.SIGN_ROW – By using this procedure you can add a signature to an existing row.
DBMS_BLOCKCHAIN_TABLE.SIGN_ROW(
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
instance_id IN NUMBER,
chain_id IN NUMBER,
sequence_id IN NUMBER,
hash IN RAW DEFAULT NULL,
signature IN RAW,
certificate_guid IN RAW,
signature_algo IN NUMBER);
  • DBMS_BLOCKCHAIN_TABLE.SIGN_ALGO_RSA_SHA2_512 - – By using this procedure you can validate a signature using specific digital certificate and signature algorithm. Note that Blockchain tables support only DER encoding or X.509 certificates
  • Note that DBMS_CRYPTO.HASH function can be used to compute hash value
Blockchain Data byte values:

By using DBMS_TABLE_DATEA package you can get the byte values of row, column
  • DBMS_TABLE_DATA.GET_BYTES_FOR_COLUMN - By using this procedure column data in bytes
  • DBMS_TABLE_DATA.GET_BYTES_FOR_COLUMNS By using this procedure column data in bytes for set of columns
  • DBMS_TABLE_DATA.GET_BYTES_FOR_ROW By using this procedure row data in bytes.
Thanks & Regards
https://oracleracexpert.com, Oracle ACE

Tuesday, September 6, 2022

Automatic Indexing in Oracle 19c & 21c

The DBA’s are responsible for Index management, which includes monitor index, add, change and remove based upon workload and ad-hoc manner. It will be difficult to decide type of index, when to create, change or drop and measure the impact, so there will be both positive and negative effects.

In Oracle 19c, the automatic indexing feature introduced and it automatically creates, rebuilds, and drops indexes to improve the performance based upon application workload and changes. This helps to optimize the database and improve performance without any user intervention.

The DBMS_AUTO_INDEX package is used for managing the automatic indexing and user can find out the current automatic index configuration by querying CDB_AUTO_INDEX_CONFIG view.

  • CONFIGURE Procedure - Configures automatic indexing.
  • DROP_AUTO_INDEXES Procedure - Drop the automatically created indexes manually by overriding the retention parameter.
  • DROP_SECONDARY_INDEXES Procedure -Deletes all the indexes, except the ones used for constraints
  • REPORT_ACTIVITY Function - Generate Report of the automatic indexing operations
  • REPORT_LAST_ACTIVITY Function - Generate Report of the last automatic indexing operation
AUTO_INDEX_MODE : The automatic indexing is controlled using the AUTO_INDEX_MODE property, It defines different modes of operation.

  • REPORT ONLY: Turn on automatic indexing and new indexes are invisible and not available for SQL operations
  • IMPLEMENT: Turn on automatic indexing and new indexes are visible available for SQL operations
  • OFF: Turn OFF automatic indexing but does not disable existing auto indexes.
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','REPORT ONLY');
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','IMPLEMENT');
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','OFF');


AUTO_INDEX_SCHEMA Procedure - When automatic indexing enabled all schemas will be used for auto indexes and you can exclude or include any schemas by using AUTO_INDEX_SCHEMA parameter

The below examples adds the SALES schema to AUTO INDEXES exclusion list

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => 'SALES',
allow => FALSE);
end;


The below examples removes the SALES schema from AUTO INDEXES exclusion list

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => 'SALES',
allow => NULL);
end;


The below example removes all the schemas from AUTO INDEXES exclusion list.

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => NULL,
allow => TRUE);
end;


You can also define retention period that you want auto indexes. The below example sets the retention period of auto indexes to 30 days.

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_RETENTION_FOR_AUTO',
parameter_value => '30');
end;


By default automatic indexes created in default permanent tablespace and you can change this by using AUTO_INDEX_DEFAULT_TABLESPACE

SQL> exec dbms_auto_index.configure('AUTO_INDEX_DEFAULT_TABLESPACE','AUTO_INDEX_TBS');

You can also allocate percentage of the tablespace can be used for auto indexes. In below example you can use 10%

SQL> exec dbms_auto_index.configure(‘AUTO_INDEX_SPACE_BUDGET’, ‘10’);



DROP_AUTO_INDEXES Procedure: Using this procedure you can Drop the automatically created indexes manually by overriding the retention parameter.

The below example will drop a single index in SALES schema and it allow recreate. If you do not want to recreate set the value to FALSE

begin
dbms_auto_index.drop_auto_indexes(
owner => ‘SALES’,
index_name => '”SYS_AI_45rfg54nxvjcty”',
allow_recreate => TRUE);
end;
/

The below example will drop all auto indexes owned by SALES and will not allow recreate as allow_recreate set to FALSE

begin
dbms_auto_index.drop_auto_indexes(
owner => 'SALES',
index_name => NULL
allow_recreate => FALSE);
end;
/

DROP_SECONDARY_INDEXES Procedure – This procedure deletes all the indexes, except the ones used for constraints

The below example deletes all auto indexes except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes;
end;

The below example deletes all auto indexes from the REGION table in the SALES schema except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes('SALES', 'REGION');
end;


The below example deletes all auto indexes in the SALES schema except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes('SALES');
end;

REPORT_ACTIVITY Function – By using this function you can generate Report of the automatic indexing operations

The below example generates automatic indexing operations report executed in the last 24 hours.

declare
act_report clob := null;
begin
act_report := dbms_auto_index.report_activity();
end;

or

SQL> select dbms_auto_index.report_activity() from dual;


The below example generates HTML automatic indexing operations report executed in the last 6 hours activity.

SQL> select dbms_auto_index.report_activity(activity_start => systimestamp-0.25, activity_end => systimestamp-1, type => 'HTML') from dual;

REPORT_LAST_ACTIVITY Function -The below example generates report of the last automatic indexing executed in a database.

declare
act_report clob := null;
begin
act_report := dbms_auto_index.report_last_activity();
end;

or

SQL>  select dbms_auto_index.report_last_activity() from dual;


The Oracle 21c comes with an enhancement in Automatic indexing, which helps to reduce the over head of the cursor invalidations during automatic index creation and also added new enhancements to improve query performance.

Thanks & Regards
http://oracleracexpert.com, Oracle ACE

Wednesday, September 8, 2021

ORA-14552: Cannot Perform a DDL Commit or Rollback inside a query or DML

You will receive this error when you use COMMIT or ROLLBACK and make sure you don’t use DML in a function to avoid this error.

In case if you need to use COMMIT or ROLLBACK then change your function as autonomous transaction by using “PRAGMA AUTONOMOUS_TRANSACTION" in your function

For Ex:-
CREATE OR REPLACE FUNCTION Function_Autonomous
return number
as
v_number number;
pragma autonomous_transaction;
BEGIN
…………
END;
/

14552, 00000, "cannot perform a DDL, commit or rollback inside a query or DML "
*Cause: DDL operations like creation tables, views etc. and transaction
control statements such as commit/rollback cannot be performed
inside a query or a DML statement.

*Action: Ensure that the offending operation is not performed or
use autonomous transactions to perform the operation within
the query/DML operation.

Thanks & Regards