Oracle 21c — Comparing Explain Plans Using the COMPARE_EXPLAIN Function

By -

 In Oracle 21c, a function named COMPARE_EXPLAIN was added to DBMS_XPLAN, which allows comparing the explain plans of two SQL statements. At the end of the report (in the "Comparison Results" section), the differences between the two plans are shown.

See the example below.

SQL> create table mytbl as select * from dba_objects;

Table created

SQL> create index ind1_object_id on mytbl(object_id);

Index created
SQL> explain plan  set statement_id = ‘Plan1’  for select /*+ full(mytbl) */ * from mytbl where object_id=9;

Explained

SQL> explain plan  set statement_id = ‘Plan2’ for select /*+ index(mytbl) */ * from mytbl where object_id=9;   

Explained
SQL> VARIABLE varvar1 varchar2(9000)

SQL> exec :varvar1 := dbms_xplan.compare_explain(‘Plan1′,’Plan2’);

PL/SQL procedure successfully completed.


SQL> select :varvar1 from dual;

COMPARE PLANS REPORT

———————————————————————————————

  Current user           : USEF

  Total number of plans  : 2

  Number of findings     : 1

———————————————————————————————

COMPARISON DETAILS

———————————————————————————————

 Plan Number            : 1 (Reference Plan)

 Plan Found             : Yes

 Plan Source            : Plan Table

 Plan Table Owner       : USEF

 Plan Table Name        : PLAN_TABLE

 Statement ID           : Plan1

 Plan ID                : 13

 Plan Database Version  : 21.0.0.0

 Parsing Schema         : “USEF”

 SQL Text               : No SQL Text

Plan

—————————–

Plan Hash Value  : 659371492

———————————————————————-

| Id  | Operation           | Name  | Rows | Bytes | Cost | Time     |

———————————————————————-

|   0 | SELECT STATEMENT    |       |    1 |   142 |  428 | 00:00:01 |

| * 1 |   TABLE ACCESS FULL | MYTBL |    1 |   142 |  428 | 00:00:01 |

———————————————————————-

Predicate Information (identified by operation id):

——————————————

* 1 – filter(“OBJECT_ID”=9)

———————————————————————————————

 Plan Number            : 2

 Plan Found             : Yes

 Plan Source            : Plan Table

 Plan Table Owner       : USEF

 Plan Table Name        : PLAN_TABLE

 Statement ID           : Plan2

 Plan ID                : 14

 Plan Database Version  : 21.0.0.0

 Parsing Schema         : “USEF”

 SQL Text               : No SQL Text

Plan

—————————–

Plan Hash Value  : 2344436349

————————————————————————————————-

| Id  | Operation                             | Name           | Rows | Bytes | Cost | Time     |

————————————————————————————————-

|   0 | SELECT STATEMENT                      |                |    1 |   142 |    2 | 00:00:01 |

|   1 |   TABLE ACCESS BY INDEX ROWID BATCHED | MYTBL          |    1 |   142 |    2 | 00:00:01 |

| * 2 |    INDEX RANGE SCAN                   | IND1_OBJECT_ID |    1 |       |    1 | 00:00:01 |

————————————————————————————————-

Predicate Information (identified by operation id):

——————————————

* 2 – access(“OBJECT_ID”=9)

Comparison Results (1):

—————————–

Query block SEL$1, Alias “MYTBL”@”SEL$1”: Access path is different –
    reference plan: FULL (line: 1), current plan: INDEX_RS_ASC (lines: 1, 2).

Comments

Post a Comment

Popular posts from this blog

Oracle 23ai — Speed up IMPDP Using NOVALIDATE Constraints

By -
  When executing the   IMPDP   command, some operations do not support parallel execution. Creating constraints is one such operation. Oracle must validate the current data in the table before creating a constraint, which requires a full table scan for each validation. This process can be very time-consuming. Consider the following constraints: ALTER TABLE VAHID.MYTB ADD CONSTRAINT CHECK1 CHECK (col3 > 50 ); ALTER TABLE VAHID.MYTB ADD CONSTRAINT CHECK2 CHECK (col9 IN ( 5 , 15 )); We drop the  MYTB  table and recreate it using a dump file: SQL > drop table mytb; Table dropped. W -1 Processing object type TABLE_EXPORT / TABLE / TABLE_DATA W -1 . . imported "VAHID"."MYTB" 19 GB 337830912 rows in 83 seconds using external_table W -1 Processing object type TABLE_EXPORT / TABLE / CONSTRAINT / CONSTRAINT W -1 Completed 2 CONSTRAINT objects in 208 seconds As shown, creating the two constraints ta...
Read more

Staging Tables in Oracle 23ai

By -
  As you may know, using   staging tables   is a common practice in   Data Warehouse   environments, primarily during the data loading process into the   Warehouse Database . Typically, raw data received from   source databases   is first loaded into a temporary area, referred to as   staging tables . After cleansing inconsistent and invalid data and transforming it into a standard format, the cleaned data is stored in the final operational tables. In addition to initial data loading,   staging tables   are also used for updates and are often truncated before reuse. In   Oracle 23ai , a new minor feature has been introduced for this purpose, allowing users to create tables specifically designed as   staging tables . This is achieved by adding the   FOR STAGING   clause to the   CREATE TABLE   statement. Creating Staging Tables Using the   FOR STAGING   clause, staging tables can be created as ...
Read more

Oracle 23ai — Track Table and Partition Scan Access

By -
Image
  In Oracle 23ai, a new view named   [dba|all|user]_table_access_stats   has been introduced, enabling users to view the access history of tables and partitions. This view shows how many times each table or partition has been scanned in each instance and the last time a table was accessed. SQL > create table jadval(id number, name varchar2( 100 ), last_name varchar2( 100 )); Table created. SQL > insert into jadval values ( 1 , 'payan' , 'rafat' ); 1 row created. SQL > select TABLE_NAME, PARTITION_NAME, INSTANCE_ID, READ_COUNT, LAST_ACCESSED_TIME from user_table_access_stats; no rows selected SQL > select * from jadval; ID NAME LAST_NA ---------- ------- ------- 1 payan rafat SQL > select TABLE_NAME, PARTITION_NAME, INSTANCE_ID, READ_COUNT, LAST_ACCESSED_TIME from user_table_access_stats; TABLE_NAME PARTITION_NAME INSTANCE_ID READ_COUNT LAST_ACCESSED_TIME ---------- --------------- ----------- --------...
Read more