man command formats and displays the on-line manual pages.  If you specify section, man only looks in that  section  of the  manual.  name is normally the name of the manual page, which is typically the name of a command, function, or file. 

$ man whatis
whatis(1)                                                            whatis(1)

NAME
       whatis - search the whatis database for complete words.

SYNOPSIS
       whatis keyword ...

DESCRIPTION
       whatis  searches  a set of database files containing short descriptions
       of system commands for keywords and displays the result on the standard
       output.  Only complete word matches are displayed.

       The  whatis database is created using the command /usr/sbin/makewhatis.

AUTHOR
       John W. Eaton was the  original  author  of  man.   Zeyd  M.  Ben-Halim
       released  man  1.2,  and  Andries Brouwer followed up with versions 1.3
       thru 1.5p.  Federico  Lucifredi    is  the  current
       maintainer.

SEE ALSO
       apropos(1), man(1).

Whatis:

whatis command searches a set of database files containing short descriptions of system commands for keywords and displays the result on the standard output.  Only complete word matches are displayed.

$ whatis whatis
whatis               (1)  - search the whatis database for complete words

Apropos:

apropos command searches a set of database files containing short descriptions of system commands for keywords and displays the result on the standard output. You can think apropos as a wrapper for the “man -k” command, useful for one knows the action but does not rememeber the actual command. Simply put, as shown in the below example, returns the indicated man pages that include the term “whatis“. 

$ apropos whatis
apropos              (1)  - search the whatis database for strings
makewhatis           (8)  - Create the whatis database
man                 (rpm) - A set of documentation tools: man, apropos and whatis.
whatis               (1)  - search the whatis database for complete words

man, whatis, and apropos are closely related commands that provide similar functionality.

• Step1: Source / Destination – You can choose SQL file location, database connection, and DDL options.

• Step 2: Types to Export – You can select the type of objects you want to explore.

• Step 3: Specify Objects – You can select the specific object that you need to export.

• Step 4: Specify Data – You can apply conditions to data by using a select or filter criteria.

• Step 5: Export Summary – At this stage you can review and verify the information list on the summary screen. Once you hit Finish, the SQL script is generated and loaded into SQL Worksheet, ready for you to run on any schema.

Everything looks great, simple and most importantly the tool is free of cost - sample script generated by the wizard is below:

--------------------------------------------------------
--  File created - Friday-February-26-2010
--------------------------------------------------------
--------------------------------------------------------
--  DDL for Table T1
--------------------------------------------------------

  CREATE TABLE "T1"
   (	"ID" NUMBER
   ) ;

---------------------------------------------------
--   DATA FOR TABLE T1
--   FILTER = none used
---------------------------------------------------
REM INSERTING into T1
Insert into T1 (ID) values (1);
Insert into T1 (ID) values (2);
Insert into T1 (ID) values (3);
Insert into T1 (ID) values (4);
Insert into T1 (ID) values (5);
Insert into T1 (ID) values (6);
Insert into T1 (ID) values (7);
Insert into T1 (ID) values (8);
Insert into T1 (ID) values (9);
Insert into T1 (ID) values (10);

---------------------------------------------------
--   END DATA FOR TABLE T1
---------------------------------------------------
--------------------------------------------------------
--  Constraints for Table T1
--------------------------------------------------------

  ALTER TABLE "T1" ADD CONSTRAINT "T1_ID_PK" PRIMARY KEY ("ID") ENABLE;
--------------------------------------------------------
--  DDL for Index T1_ID_PK
--------------------------------------------------------

  CREATE UNIQUE INDEX "T1_ID_PK" ON "T1" ("ID")
  ;

The DDL is not error free, to illustrate the issue, I selected only table T1 to export from my schema. If you run the sample script above as-is, you will receive an error “ORA-00955: name is already used by an existing object”.  It is because, the database wizard (SQL Developer Version 2.1.0.63, Build MAIN-63.73) , simply produces one section of DDL statements for constraints and another set for indexes within the script file.

SQL> --------------------------------------------------------
SQL> --  DDL for Index T1_ID_PK
SQL> --------------------------------------------------------
SQL>
SQL>   CREATE UNIQUE INDEX "T1_ID_PK" ON "T1" ("ID")
  2    ;
  CREATE UNIQUE INDEX "T1_ID_PK" ON "T1" ("ID")
                      *
ERROR at line 1:
ORA-00955: name is already used by an existing object

You will have to do a clean-up to make the script error free.

DELETE (SELECT some_column FROM table_one JOIN table_two USING (join_column));

I would like to show you the caveat of using a DELETE statement with an inline view.  At the outset, one would think that the the removal of row is always perfomed on table_one, but it can be from table_one or table_two, it all depends on the physics of the table.  Let us start building a simple test case to illustrate the issue.

• Create two test tables, t1 and t2 with primary key

SQL> SELECT banner FROM v$version
  2  WHERE rownum = 1;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi                

SQL> SET HEAD OFF
SQL> CREATE TABLE t1 (id NUMBER);

Table created.

SQL> CREATE TABLE t2 (id NUMBER);

Table created.

SQL> ALTER TABLE t1 ADD CONSTRAINT t1_id_pk PRIMARY KEY (id);

Table altered.

SQL> ALTER TABLE t2 ADD CONSTRAINT t2_id_pk PRIMARY KEY (id);

Table altered.

• Explain plan of DELETE statement with two different FROM clause (i.e  one from t1 to t2 and another from t2 to t1).

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t1 JOIN t2 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 4198931308                                                     

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T1       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T2       |
|   4 |    INDEX UNIQUE SCAN| T1_ID_PK |
----------------------------------------                                        

11 rows selected.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t2 JOIN t1 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 988330285                                                      

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T2       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T1       |
|   4 |    INDEX UNIQUE SCAN| T2_ID_PK |
----------------------------------------                                        

11 rows selected.

If you examine the execution plans above,  you see that the delete is performed on the table, which first appears in the FROM clause.  Also, If you force the optimizer to not use both the indexes, it will result in same behaviour.

SQL> EXPLAIN PLAN FOR DELETE
  2  	(SELECT /*+ NO_INDEX (t1 t1_id_pk)  NO_INDEX (t2 t2_id_pk)*/ id
  3  	   FROM t1 JOIN t2 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 3682150560                                                     

------------------------------------
| Id  | Operation           | Name |
------------------------------------
|   0 | DELETE STATEMENT    |      |
|   1 |  DELETE             | T1   |
|   2 |   HASH JOIN         |      |
|   3 |    TABLE ACCESS FULL| T2   |
|   4 |    TABLE ACCESS FULL| T1   |
------------------------------------                                            

11 rows selected.

SQL> EXPLAIN PLAN FOR DELETE
  2  	(SELECT /*+ NO_INDEX (t1 t1_id_pk)  NO_INDEX (t2 t2_id_pk)*/ id
  3  	   FROM t2 JOIN t1 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 4238075461                                                     

------------------------------------
| Id  | Operation           | Name |
------------------------------------
|   0 | DELETE STATEMENT    |      |
|   1 |  DELETE             | T2   |
|   2 |   HASH JOIN         |      |
|   3 |    TABLE ACCESS FULL| T1   |
|   4 |    TABLE ACCESS FULL| T2   |
------------------------------------                                            

11 rows selected.

• Remove T1’s primary key constraint/index and retain T2’s and obtain explain plans

SQL> ALTER TABLE t1 DROP CONSTRAINT t1_id_pk;

Table altered.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t1 JOIN t2 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 2997925617                                                     

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T1       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T1       |
|   4 |    INDEX UNIQUE SCAN| T2_ID_PK |
----------------------------------------                                        

11 rows selected.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t2 JOIN t1 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 2997925617                                                     

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T1       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T1       |
|   4 |    INDEX UNIQUE SCAN| T2_ID_PK |
----------------------------------------                                        

11 rows selected.

After droping the primary constraint/index on T1, the DELETE is performed on T1 no matter whether your FROM clause is T1 to T2,  T2 to T1.

• Remove T2’s primary key constraint/index and add primary key constraint/index to T1 and obtain explain plans

SQL> ALTER TABLE t2 DROP CONSTRAINT t2_id_pk;

Table altered.

SQL> ALTER TABLE t1 ADD CONSTRAINT t1_id_pk PRIMARY KEY (id);

Table altered.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t1 JOIN t2 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 4135363241                                                     

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T2       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T2       |
|   4 |    INDEX UNIQUE SCAN| T1_ID_PK |
----------------------------------------                                        

11 rows selected.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t2 JOIN t1 USING (id));

Explained.

SQL> SELECT * FROM table(dbms_xplan.display(NULL,NULL,'BASIC'));

Plan hash value: 4135363241                                                     

----------------------------------------
| Id  | Operation           | Name     |
----------------------------------------
|   0 | DELETE STATEMENT    |          |
|   1 |  DELETE             | T2       |
|   2 |   NESTED LOOPS      |          |
|   3 |    TABLE ACCESS FULL| T2       |
|   4 |    INDEX UNIQUE SCAN| T1_ID_PK |
----------------------------------------                                        

11 rows selected.

After droping the primary constraint/index on T2 and recreating the primary key primary constraint/index on T1, the DELETE is performed on T2 no matter whether your FROM clause is T1 to T2,  T2 to T1.

If you run the DELETE statement when there is no index on both the tables,  it will result in error ““ORA-01752: cannot delete from view without exactly one key-preserved table.” 

SQL> ALTER TABLE t1 DROP CONSTRAINT t1_id_pk;

Table altered.

SQL> EXPLAIN PLAN FOR DELETE (SELECT id FROM t2 JOIN t1 USING (id));
EXPLAIN PLAN FOR DELETE (SELECT id FROM t2 JOIN t1 USING (id))
                        *
ERROR at line 1:
ORA-01752: cannot delete from view without exactly one key-preserved table

Don’t get excited with the new features or syntaxes, test things thoroughly and cover all possible scenarios before you put in production.

Software Performance and Scalability: A Quantitative Approach (Wiley, May 2009)

Author has divided this book into three parts:  Part 1: The Basics  - This part lays the foundation for understanding the factors that affect the performance and scalability of a software product in general. Part 2: Applying Queuing Theory – Queuing theory is the mathematical study of waiting lines or queues for a system that depends on limited resources to complete certain tasks. Part 3: Applying API Profiling – API profiling provides quantitative information about how a software program is executed internally at the API level. Such information is useful in identifying the most expensive execution paths from performance and scalability perspectives.

You can take advantage of Google Books for the detailed preview of the content. Alternatively, you can also visit the book’s website for updated information.

As you read, you will realize that virtualization environment and its effects on scalability and performance is not covered in this book.  Hope to see this in the future editions.  It is a must read for anyone who is serious about building enterprise level products or applications. I hope you’ll enjoy this book as much as I have had and it is a happy addition to my library.

A join is a query that combines rows from two or more tables. Oracle performs a join whenever multiple tables appear in the FROM clause of the query.  Below is a SQL join statement, legacy syntax and ANSI/ISO syntax (also referred as new join syntax, was first introduced in Oracle 9i release) in a simple pseudo code form.

• ANSI/ISO Syntax:

SELECT * FROM <table one> [join type] JOIN <table two>
USING <join columns> | ON <join conditions>
[WHERE <where clause filters/restrictions>]

• Legacy Syntax:

SELECT * FROM <table one>, <table two>
[WHERE <where clause join conditions>]
[<where clause filters/restrictions>]

Join Conditions

Most of the queries will contain at least one join condition, either in the FROM clause or in the WHERE clause. The join condition compares two columns, each from a different table. To execute a join, Oracle database combines pairs of rows, each containing one row from each table, for which the join condition evaluates to TRUE.

To execute a join of three or more tables, Oracle first joins two of the tables based on the join conditions comparing their columns and then joins the result to another table based on join conditions containing columns of the joined tables and the new table. Oracle continues this process until all tables are joined into the result. The optimizer determines the order in which Oracle joins tables based on the join conditions, indexes on the tables, and, any available statistics for the tables.

Filters (also known as Restrictions)

A WHERE clause can also contain filter conditions that refer to columns of only one table, which can further restrict the rows returned by the join query.

• Let us create some test tables to demonstrate different type of joins

SQL> CREATE TABLE t1
  2  AS
  3  SELECT * FROM
  4  (
  5  SELECT rownum-1 id,
  6  DECODE(rownum-1,0,'Zero',NULL) word,
  7  (rownum-1)*10 t1n,
  8  SUBSTR(DECODE(rownum-1,0,'Zero',TO_CHAR(TO_DATE((rownum-1)*10,'J'),'Jsp')),1,12) t1word,
  9  (rownum-1)*1000 t1value
 10  FROM dual CONNECT BY LEVEL <= 11
 11  )
 12  WHERE ID IN (0,1,3,5,7,10); 

Table created.

SQL> CREATE TABLE t2
  2  AS
  3  SELECT * FROM
  4  (
  5  SELECT rownum-1 id,
  6  DECODE(rownum-1,0,'Zero',NULL) word,
  7  (rownum-1)*100 t2n,
  8  SUBSTR(DECODE(rownum-1,0,'Zero',TO_CHAR(TO_DATE((rownum-1)*100,'J'),'Jsp')),1,12) t2word,
  9  (rownum-1)*1000 t2value
 10  FROM DUAL CONNECT BY LEVEL <= 11
 11  )
 12  WHERE ID IN (0,1,2,4,6,8,9); 

Table created. 

SQL> CREATE TABLE t3
  2  AS
  3  SELECT 'GRP' || LPAD (ROWNUM, 2, '0') group_id,
  4         ((ROWNUM - 1) * 2000) + 1 low_value, ROWNUM * 2000 high_value
  5  FROM DUAL CONNECT BY LEVEL <= 6;

Table created.

SQL> SELECT * FROM t1;

        ID WORD        T1N T1WORD          T1VALUE
---------- ---- ---------- ------------ ----------
         0 Zero          0 Zero                  0
         1              10 Ten                1000
         3              30 Thirty             3000
         5              50 Fifty              5000
         7              70 Seventy            7000
        10             100 One Hundred       10000

6 rows selected.

SQL> SELECT * FROM t2;

        ID WORD        T2N T2WORD          T2VALUE
---------- ---- ---------- ------------ ----------
         0 Zero          0 Zero                  0
         1             100 One Hundred        1000
         2             200 Two Hundred        2000
         4             400 Four Hundred       4000
         6             600 Six Hundred        6000
         8             800 Eight Hundre       8000
         9             900 Nine Hundred       9000

7 rows selected.

SQL> SELECT * FROM t3;

GROUP  LOW_VALUE HIGH_VALUE
----- ---------- ----------
GRP01          1       2000
GRP02       2001       4000
GRP03       4001       6000
GRP04       6001       8000
GRP05       8001      10000
GRP06      10001      12000

6 rows selected.

Join Types

• Cross Joins: If two tables in a join query have no join condition, then Oracle Database returns their Cartesian product. Oracle combines each row of one table with each row of the other. 

ANSI/ISO Syntax

SQL> SELECT t1n, t2word, t2n, t2word
  2  FROM t1 CROSS JOIN t2;

       T1N T2WORD              T2N T2WORD
---------- ------------ ---------- ------------
         0 Zero                  0 Zero
...
       100 Nine Hundred        900 Nine Hundred

42 rows selected.

Legacy Syntax

SQL> SELECT t1n, t2word, t2n, t2word
  2  FROM t1, t2;

       T1N T2WORD              T2N T2WORD
---------- ------------ ---------- ------------
         0 Zero                  0 Zero
...
        100 Nine Hundred        900 Nine Hundred

42 rows selected.

• Equi Joins (also known as Natural Joins): An equijoin is a join with a join condition containing an equality operator. An equijoin combines rows that have equivalent values for the specified columns.

// Using Clause //

 ANSI/ISO Syntax

SQL> SELECT id, t1.word, t2.word,t1n, t1word, t2n, t2word
  2  FROM t1 JOIN t2 USING(id);

        ID WORD WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---- ---------- ------------ ---------- ------------
         0 Zero Zero          0 Zero                  0 Zero
         1                   10 Ten                 100 One Hundred

Legacy Syntax

SQL> SELECT t1.id, t1.word, t2.word,t1n, t1word, t2n, t2word
  2  FROM t1, t2
  3  WHERE t1.id = t2.id;

        ID WORD WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---- ---------- ------------ ---------- ------------
         0 Zero Zero          0 Zero                  0 Zero
         1                   10 Ten                 100 One Hundred

// Natural Join Clause – performs a join on all columns with the matching names in T1 and T2//

ANSI/ISO Syntax

SQL> SELECT id, word, t1n, t1word, t2n, t2word
  2  FROM t1 NATURAL JOIN t2;

        ID WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---------- ------------ ---------- ------------
         0 Zero          0 Zero                  0 Zero

Legacy Syntax

SQL> SELECT t1.id, t2.word, t1n, t1word, t2n, t2word
  2  FROM t1, t2
  3  WHERE t1.id = t2.id
  4    AND t1.word = t2.word;

        ID WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---------- ------------ ---------- ------------
         0 Zero          0 Zero                  0 Zero

// ON Clause //

ANSI/ISO Syntax

SQL> SELECT t1.id, t1.word, t1n, t1word, t2n, t2word
  2  FROM t1 JOIN t2 ON (t1.t1n = t2.t2n);

        ID WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---------- ------------ ---------- ------------
         0 Zero          0 Zero                  0 Zero
        10             100 One Hundred         100 One Hundred

Legacy Syntax

SQL> SELECT t1.id, t1.word, t1n, t1word, t2n, t2word
  2  FROM t1, t2
  3  WHERE t1.t1n = t2.t2n;

        ID WORD        T1N T1WORD              T2N T2WORD
---------- ---- ---------- ------------ ---------- ------------
         0 Zero          0 Zero                  0 Zero
        10             100 One Hundred         100 One Hundred

• Theta Joins (also known as Inner Joins): Theta join is technically, nothing but a cross join with a join condition. Simply put, instead of returning all the rows of a cartesian product, only rows matching the join condition are returned.

ANSI/ISO Syntax

SQL> -- Without Inner Keyword
SQL> SELECT t1.id,t1.word,t1.t1value,t3.group_id
  2  FROM t1 JOIN t3 ON t1.t1value
  3  BETWEEN t3.low_value AND t3.high_value;

        ID WORD    T1VALUE GROUP
---------- ---- ---------- -----
        10           10000 GRP05
         7            7000 GRP04
         5            5000 GRP03
         3            3000 GRP02
         1            1000 GRP01

SQL> -- With Inner Keyword
SQL> SELECT t1.id,t1.word,t1.t1value,t3.group_id
  2  FROM t1 INNER JOIN t3 ON t1.t1value
  3  BETWEEN t3.low_value AND t3.high_value;

        ID WORD    T1VALUE GROUP
---------- ---- ---------- -----
        10           10000 GRP05
         7            7000 GRP04
         5            5000 GRP03
         3            3000 GRP02
         1            1000 GRP01

Legacy Syntax

SQL> SELECT t1.id,t1.word,t1.t1value,t3.group_id
  2  FROM t1, t3
  3  WHERE t1.t1value
  4  BETWEEN t3.low_value AND t3.high_value;

        ID WORD    T1VALUE GROUP
---------- ---- ---------- -----
        10           10000 GRP05
         7            7000 GRP04
         5            5000 GRP03
         3            3000 GRP02
         1            1000 GRP01

• Outer Joins: An outer join extends the result of a simple join. An outer join returns all rows that satisfy the join condition and also returns some or all of those rows from one table for which no rows from the other satisfy the join condition.

// To write a query that performs an outer join of tables T1 and T2 and returns all rows from T1 (a left outer join)

ANSI/ISO Syntax (Use the LEFT [OUTER] JOIN syntax in the FROM clause)

SQL> SELECT t1.id, t2.word, t2.id, t2.word
  2  FROM t1 LEFT OUTER JOIN t2 ON (t1.id = t2.id);

        ID WORD         ID WORD
---------- ---- ---------- ----
         0 Zero          0 Zero
         1               1
         7
         5
         3
        10

6 rows selected.

Legacy Syntax (Apply the outer join operator (+) to all columns of T2 in the join condition in the WHERE clause)

SQL> SELECT t1.id, t2.word, t2.id, t2.word
  2  FROM t1, t2
  3  WHERE t1.id = t2.id(+);

        ID WORD         ID WORD
---------- ---- ---------- ----
         0 Zero          0 Zero
         1               1
         7
         5
         3
        10

6 rows selected.

// To write a query that performs an outer join of tables T1 and T2 and returns all rows from T2 (a right outer join)

ANSI/ISO Syntax (Use the RIGHT [OUTER] JOIN syntax in the FROM clause)

SQL> SELECT t1.id, t2.word, t2.id, t2.word
  2  FROM t1 RIGHT OUTER JOIN t2 ON (t1.id = t2.id);

        ID WORD         ID WORD
---------- ---- ---------- ----
         0 Zero          0 Zero
         1               1
                         8
                         2
                         6
                         4
                         9

7 rows selected.

Legacy Syntax (Apply the outer join operator (+) to all columns of T1 in the join condition in the WHERE clause)

SQL> SELECT t1.id, t2.word, t2.id, t2.word
  2  FROM t1, t2
  3  WHERE t1.id (+)= t2.id;

        ID WORD         ID WORD
---------- ---- ---------- ----
         0 Zero          0 Zero
         1               1
                         8
                         2
                         6
                         4
                         9

7 rows selected.

// To write a query that performs an outer join and returns all rows from T1  and T2, extended with nulls if they do not satisfy the join condition (a full outer join), use the FULL [OUTER] JOIN syntax in the FROM clause.

ANSI/ISO Syntax

SQL> SELECT t1.id, t2.word, t2.id, t2.word
  2  FROM t1 FULL OUTER JOIN t2 ON (t1.id = t2.id);

        ID WORD         ID WORD
---------- ---- ---------- ----
         0 Zero          0 Zero
         1               1
         7
         5
         3
        10
                         8
                         2
                         6
                         4
                         9

11 rows selected.

Legacy Syntax (Not available)

• Self Joins: A self join is a join of a table to itself. This table appears twice in the FROM clause and is followed by table aliases that qualify column names in the join condition. To perform a self join, Oracle Database combines and returns rows of the table that satisfy the join condition.

ANSI/ISO Syntax

SQL> SELECT a.id, a.word, a.t1n, b.id, b.word, b.t1n
  2  FROM t1 a JOIN t1 b ON (a.id = b.t1n);

        ID WORD        T1N         ID WORD        T1N
---------- ---- ---------- ---------- ---- ----------
         0 Zero          0          0 Zero          0
        10             100          1              10

Legacy Syntax

SQL> SELECT a.id, a.word, a.t1n, b.id, b.word, b.t1n
  2  FROM t1 a, t1 b
  3  WHERE a.id = b.t1n;

        ID WORD        T1N         ID WORD        T1N
---------- ---- ---------- ---------- ---- ----------
         0 Zero          0          0 Zero          0
        10             100          1              10

• Anti-Joins: An antijoin returns rows from the left side of the predicate for which there are no (NOT IN or NOT EXISTS) corresponding rows on the right side of the predicate. Simply put, where rows from one table with no matching rows from other table are returned.

SQL> SELECT id, t1n, t1word
  2  FROM t1
  3  WHERE id NOT IN (SELECT id FROM t2);

        ID        T1N T1WORD
---------- ---------- ------------
         3         30 Thirty
         5         50 Fifty
         7         70 Seventy
        10        100 One Hundred

SQL> SELECT id, t1n, t1word
  2  FROM t1
  3  WHERE NOT EXISTS
  4  	   (SELECT id FROM t2 WHERE t2.id = t1.id);

        ID        T1N T1WORD
---------- ---------- ------------
         7         70 Seventy
         5         50 Fifty
         3         30 Thirty
        10        100 One Hundred

• Semi-Joins: A semijoin returns rows that match an IN or EXISTS subquery without duplicating rows from the left side of the predicate when multiple rows on the right side satisfy the criteria of the subquery. Simply put, all rows from table on the left are returned for a matching condition on the right.

SQL> SELECT id, t1n, t1word
  2  FROM t1
  3  WHERE id IN (SELECT id FROM t2);

        ID        T1N T1WORD
---------- ---------- ------------
         0          0 Zero
         1         10 Ten

SQL> SELECT id, t1n, t1word
  2  FROM t1
  3  WHERE EXISTS
  4  	   (SELECT id FROM t2 WHERE t2.id = t1.id);

        ID        T1N T1WORD
---------- ---------- ------------
         0          0 Zero
         1         10 Ten

This book is about data accuracy, divided into three parts – Part 1 Understanding Data Accuracy: defines inaccurate data, shows the scope of problems that exists in the real world, and covers how data becomes inaccurate. Part 2 Implementing a Data Quality Assurance Program: covers how data quality assurance program is constructed with the inside-out approach, and covers the methodology used, the skills needed, and the general business cases. Part 3 Data Profiling Technology: focuses on the technology of data profiling. It describes the basic concept of technology and shows how individual parts contribute to overall result.

The author has explained the concepts, techniques, and the framework required to analyze and improve usefulness of the source data. It is a must read, if you are a professional working in the field of data quality, data integration, data architecture, or data warehousing. Many books are out there in the market on the similar subject, but this one is easy to study and does provide a new ground in 300 pages.

You can preview this book at Google Books.

Overall, this is a very good book. I wish I would have read it several years ago!

• Let’s create a test table and populate

SQL> CREATE TABLE t (n CONSTRAINT t_pk PRIMARY KEY, d)
  2  AS
  3  SELECT rownum, mod(rownum,5)
  4  FROM dual CONNECT BY level <= 10000;

Table created.

• As expected, querying the table on primary key column resulted in index unique scan and on non-indexed column resulted in full table scan.

SQL> SET AUTOTRACE TRACEONLY EXPLAIN
SQL> SELECT * FROM t WHERE n = 5;

Execution Plan
----------------------------------------------------------
Plan hash value: 1303508680

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |     1 |    26 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |    26 |     2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | T_PK |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("N"=5)

SQL> SELECT * FROM t WHERE d = 0;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  2000 | 52000 |     6   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  2000 | 52000 |     6   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("D"=0)

Note
-----
   - dynamic sampling used for this statement

We can create a fake index by simply adding NOSEGMENT clause to the CREATE INDEX statement. The NOSEGMENT clause specifies the index is virtual. By setting the hidden parameter _use_nosegment_indexes to TRUE; you are instructing the optimizer to use the index, if it is useful.

SQL> CREATE INDEX t_d_virtual_idx ON t(d) NOSEGMENT;

Index created.

SQL> ALTER SESSION SET "_use_nosegment_indexes" = TRUE;

Session altered.

SQL> SELECT * FROM t WHERE d = 0;

Execution Plan
----------------------------------------------------------
Plan hash value: 3632700478

-----------------------------------------------------------------------------------------------
| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                 |  2000 | 52000 |     5   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T               |  2000 | 52000 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_D_VIRTUAL_IDX |    40 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("D"=0)

Note
-----
   - dynamic sampling used for this statement

The optimizer determined that the virtual index deemed useful; hence, changed the execution plan from full table scan to index range scan. 

Fake index is really useful, if you have a large table and would like to check if the new index will be used by the optimizer. Since there is no storage area associated with these indexes, they do not have any other overhead. Some important characteristics of  fake index are:

• Virtual indexes are reflected in USER_OBJECTS, DBA_OBJECTS but are not reflected in USER_INDEXES, DBA_INDEXES

SQL> SET AUTOTRACE OFF
SQL> SELECT index_name FROM user_indexes WHERE table_name = 'T';

INDEX_NAME
------------------------------
T_PK

SQL> SELECT object_name FROM user_objects WHERE object_name LIKE 'T%' and object_type = 'INDEX'

OBJECT_NAME
------------------------------
T_D_VIRTUAL_IDX
T_PK

• ALTER INDEX command on a fake index will result in ORA-08114 error

SQL> ALTER INDEX t_d_virtual_idx RENAME TO t_d_virtual_idx2;
ALTER INDEX t_d_virtual_idx RENAME TO t_d_virtual_idx2
*
ERROR at line 1:
ORA-08114: can not alter a fake index

• You can not create a fake index on same column list, but can create a conventional (real) index on same column list.

SQL> CREATE INDEX t_d_virtual_idx3 ON t(d) NOSEGMENT;
CREATE INDEX t_d_virtual_idx3 ON t(d) NOSEGMENT
                                   *
ERROR at line 1:
ORA-01408: such column list already indexed

SQL> CREATE INDEX t_d_virtual_idx4 ON t(d);

Index created.

• You can analyze or collect statistics on fake indexes; However, no corresponding statistics will be populated

SQL> EXECUTE DBMS_STATS.gather_index_stats(USER, 't_d_virtual_idx');

PL/SQL procedure successfully completed.

With the goal of closely mimicing the Oracle database, ORION generates a synthetic I/O workload, using the same I/O software stack as Oracle. ORION can be configured to generate a wide range of I/O workloads, including ones that simulate OLTP and data warehouse workloads.

A summary of how to use ORION is also available directly from ORION by invoking the “-help” option.

$ orion -help
ORION: ORacle IO Numbers — Version 11.2.0.1.0

ORION runs IO performance tests that model Oracle RDBMS IO workloads.
It measures the performance of small (2-32K) IOs and large (128K+) IOs at various load levels.

Each Orion data point is a test for a specific mix of small and large IO loads sustained for a duration.
An Orion test consists of multiple data point tests.  These data point tests can be represented as a
two-dimensional matrix.  Each column in the matrix represents data point tests with the same small IO load,
but varying large IO loads. Each row represents data point tests with the same large IO load, but
varying small IO loads.  An Orion test can be for a single point, a single row, a single column, or
the whole matrix.

The ‘run’ parameter is the only mandatory parameter. Defaults are indicated for all other parameters.
For additional information on the user interface, see the Orion User Guide.

...output omitted...

ORION tool for various OS platforms and user guide can be downloaded from  Oracle ORION downloads. Oracle offering this tool as a standalone download with an unsupported note.  I just noticed, Oracle has included this tool in Oracle 11g Release 2; the binary is located under $ORACLE_HOME/bin.

TOAD Explain Plan

Right-clicking on the explain plan and selecting “Adjust Content” from the context menu will bring “Execution Plan Preferences” window, which allows you to control the information displayed in the Explain Plan tab.

Toad Explain Plan > Adjust Content > Execution Plan Preferences

The optimizer chooses the access path based on the following factors:

• The available access paths for the statement
• The estimated cost of executing the statement, using each access path or combination of paths

In Index Scan method, a row is retrieved by traversing the index, using the indexed column values specified by the statement. An index scan retrieves data from an index based on the value of one or more columns in the index. To perform an index scan, Oracle searches the index for the indexed column values accessed by the statement. If the statement accesses only columns of the index, then Oracle reads the indexed column values directly from the index, rather than from the table.

The index contains not only the indexed value, but also the rowids of rows in the table having that value. Therefore, if the statement accesses other columns in addition to the indexed columns, then Oracle can find the rows in the table by using either a table access by rowid or a cluster scan.

ops$rperumal@PDB10> CREATE TABLE t (
  2    pkc NOT NULL,
  3    sv2,
  4    cv20,
  5    sv200,
  6    rsn1,
  7    rsn2,
  8    rsn3,
  9    data,
 10    CONSTRAINT t_pk primary key (pkc)
 11  )
 12  AS
 13  SELECT rownum                  pkc,
 14  	    mod(rownum, 2)+1	sv2,
 15  	    trunc((rownum-1)/500)	cv20,
 16  	    mod(rownum, 200)+1	sv200,
 17  	    rownum		rsn1,
 18  	    rownum		rsn2,
 19  	    rownum		rsn3,
 20  	    lpad(rownum,10,'0') 	data
 21  FROM dual
 22  CONNECT BY LEVEL <= 10000;

Table created.

ops$rperumal@PDB10> CREATE INDEX t_sv2_rsn1 ON t(sv2,rsn1);

Index created.

ops$rperumal@PDB10> CREATE INDEX t_cv20_rsn2 ON t(cv20,rsn2);

Index created.

ops$rperumal@PDB10> CREATE INDEX t_sv200_rsn3 ON t(sv200,rsn3);

Index created.

ops$rperumal@PDB10> CREATE INDEX t_data ON t(data);

Index created.

ops$rperumal@PDB10> EXECUTE DBMS_STATS.gather_table_stats(USER,'T',cascade=>TRUE);

PL/SQL procedure successfully completed.

ops$rperumal@PDB10> SET AUTOTRACE TRACEONLY EXPLAIN

Index Unique Scan

This scan returns, at most, a single rowid. Oracle performs a unique scan if a statement contains a UNIQUE or a PRIMARY KEY constraint that guarantees that only a single row is accessed.  This access path is used when all columns of a unique (B-tree) index or an index created as a result of a primary key constraint are specified with equality conditions.

Execution plan using Index Unique Scan below:

ops$rperumal@PDB10> SELECT * FROM t WHERE pkc = 2000;

Execution Plan
----------------------------------------------------------
Plan hash value: 1303508680

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |     1 |    36 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |    36 |     2   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | T_PK |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PKC"=2000)

Index Range Scan

An index range scan is a common operation for accessing selective data. It can be bounded (bounded on both sides) or unbounded (on one or both sides). Data is returned in the ascending order of index columns. Multiple rows with identical values are sorted in ascending order by rowid. If data must be sorted by order, then use the ORDER BY clause, and do not rely on an index. If an index can be used to satisfy an ORDER BY clause, then the optimizer uses this option and avoids a sort.

The optimizer uses a range scan when it finds one or more leading columns of an index specified in conditions, such as the following:

• col1 = :b1
• col1 < :b1
• col1 > :b1
• AND combination of the preceding conditions for leading columns in the index
• col1 like ‘ASD%’ wild-card searches should not be in a leading position otherwise the condition col1 like ‘%ASD’ does not result in a range scan. Range scans can use unique or non-unique indexes. Range scans avoid sorting when index columns constitute the ORDER BY/GROUP BY clause.

Execution plan usingIindex Range Scan below:

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc < 200;

Execution Plan
----------------------------------------------------------
Plan hash value: 3772518221

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |   199 |  7164 |     4   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |   199 |  7164 |     4   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_PK |   199 |       |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PKC"<200)

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc > 9900;

Execution Plan
----------------------------------------------------------
Plan hash value: 3772518221

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |   100 |  3600 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |   100 |  3600 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_PK |   100 |       |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PKC">9900)

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc BETWEEN 2000 AND 3000;

Execution Plan
----------------------------------------------------------
Plan hash value: 3772518221

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |  1002 | 36072 |    10   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |  1002 | 36072 |    10   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_PK |  1002 |       |     4   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PKC">=2000 AND "PKC"<=3000)

ops$rperumal@PDB10> SELECT * FROM t WHERE data = '0000000001';

Execution Plan
----------------------------------------------------------
Plan hash value: 3782328437

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |     1 |    36 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T      |     1 |    36 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_DATA |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("DATA"='0000000001')

Index Range Scan Descending

An index range scan descending is identical to an index range scan, except that the data is returned in descending order. Indexes, by default, are stored in ascending order. Usually, this scan is used when ordering data in a descending order to return the most recent data first, or when seeking a value less than a specified value. The optimizer uses index range scan descending when an order by descending clause can be satisfied by an index.

Execution plan using Index Range Scans Descending below:

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc BETWEEN 2000 AND 3000 ORDER BY pkc DESC;

Execution Plan
----------------------------------------------------------
Plan hash value: 725076093

-------------------------------------------------------------------------------------
| Id  | Operation                    | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |      |  1002 | 36072 |    10   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID | T    |  1002 | 36072 |    10   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN DESCENDING| T_PK |  1002 |       |     4   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PKC">=2000 AND "PKC"<=3000)

Index Skip Scan

Index skip scan improve index scans by nonprefix columns. Often, scanning index blocks is faster than scanning table data blocks. Skip scanning lets a composite index be split logically into smaller subindexes. In skip scanning, the initial column of the composite index is not specified in the query. In other words, it is skipped.

The number of logical subindexes is determined by the number of distinct values in the initial column. Skip scanning is advantageous if there are few distinct values in the leading column of the composite index and many distinct values in the nonleading key of the index.

Execution plan using Index Skip Scan below:

ops$rperumal@PDB10> SELECT *  FROM t WHERE rsn1 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 2069911305

------------------------------------------------------------------------------------------
| Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |            |     1 |    36 |     4   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T          |     1 |    36 |     4   (0)| 00:00:01 |
|*  2 |   INDEX SKIP SCAN           | T_SV2_RSN1 |     1 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("RSN1"=55)
       filter("RSN1"=55)

ops$rperumal@PDB10> SELECT sv2,rsn1  FROM t WHERE rsn1 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 714504825

-------------------------------------------------------------------------------
| Id  | Operation        | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |            |     1 |     7 |     3   (0)| 00:00:01 |
|*  1 |  INDEX SKIP SCAN | T_SV2_RSN1 |     1 |     7 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("RSN1"=55)
       filter("RSN1"=55)

ops$rperumal@PDB10> SELECT data  FROM t WHERE rsn1 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 2069911305

------------------------------------------------------------------------------------------
| Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |            |     1 |    15 |     4   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T          |     1 |    15 |     4   (0)| 00:00:01 |
|*  2 |   INDEX SKIP SCAN           | T_SV2_RSN1 |     1 |       |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("RSN1"=55)
       filter("RSN1"=55)

Index Full Scan

A full index scan eliminates a sort operation, because the data is ordered by the index key. It reads the blocks singly. A full scan is used in any of the following situations:

• All of the columns in the ORDER BY clause must be in the index: The order of the columns in the ORDER BY clause must match the order of the leading index columns. The ORDER BY clause can contain all of the columns in the index or a subset of the columns in the index.
• The query requires a sort merge join. A full index scan can be done instead of doing a full table scan followed by a sort if the query meets the following requirements: All of the columns referenced in the query must be in the index. The order of the columns referenced in the query must match the order of the leading index columns.
• A GROUP BY clause is present in the query, and the columns in the GROUP BY clause are present in the index. The columns do not need to be in the same order in the index and the GROUP BY clause. The GROUP BY clause can contain all of the columns in the index or a subset of the columns in the index.

Execution plan using Index Full Scan below:

ops$rperumal@PDB10> SELECT * FROM t ORDER BY pkc;

Execution Plan
----------------------------------------------------------
Plan hash value: 1399892806

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      | 10000 |   351K|    80   (2)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    | 10000 |   351K|    80   (2)| 00:00:01 |
|   2 |   INDEX FULL SCAN           | T_PK | 10000 |       |    21   (0)| 00:00:01 |
------------------------------------------------------------------------------------

ops$rperumal@PDB10> SELECT pkc FROM t ORDER BY pkc;

Execution Plan
----------------------------------------------------------
Plan hash value: 2446862604

-------------------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT |      | 10000 | 40000 |    21   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | T_PK | 10000 | 40000 |    21   (0)| 00:00:01 |
-------------------------------------------------------------------------

Index Fast Full Scan

Index fast full scan is an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key.

Execution plan using Index Fast Full Scan below:

ops$rperumal@PDB10> SELECT cv20,rsn2  FROM t WHERE rsn2 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 2742123628

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     1 |     7 |     7   (0)| 00:00:01 |
|*  1 |  INDEX FAST FULL SCAN| T_CV20_RSN2 |     1 |     7 |     7   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("RSN2"=55)

Why Oracle is not using my Index?

There are many reasons that Oracle Optimizer will turn an Index access to Full table access. Some of the most common scenarios are:

Case 1: Index Range Scan to Full Table Scan

The optimizer does FTS if a large perentage of rows are read; usually over 5-20%, but this percentage can vary. Below example shows that an Index Range Scan turned into a Full Table scan upon requesting to retrieve 20% of the rows from a table.

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc < 2000;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1999 | 71964 |    15   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  1999 | 71964 |    15   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("PKC"<2000)

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc > 8000;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  2000 | 72000 |    15   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  2000 | 72000 |    15   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("PKC">8000)

ops$rperumal@PDB10> SELECT *  FROM t WHERE pkc BETWEEN 2000 AND 6000;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  4002 |   140K|    15   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  4002 |   140K|    15   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("PKC"<=6000 AND "PKC">=2000)

ops$rperumal@PDB10> SELECT * FROM t WHERE pkc <> 2000;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  9999 |   351K|    16   (7)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  9999 |   351K|    16   (7)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("PKC"<>2000)

Case 2: Index Skip Scan / Index Fast Full Scan  to Full Table Scan

Optimizer performs a Index Skip Scan only if a leading edge of the index has very few distinct values and the optimizer is aware of that.  SV2 column in the test table has two distinct values, retrieving based on rsn1=55 uses index (T_SV2_RSN1), which results in Index Skip Scan. Whereas, CV2 column in the test table has 20 distinct values, retrieving based on rsn2=55 and selecting column that part of composite index (T_CV20_RSN2) , which results in Index Fast Full Scan. 

• Index Skip Scan will turn into Full Table Scan when the leading edge of the index has many distinct values and you retrieve the data by non-leading index column.
• Index Fast Full Scan will turn into Full Table Scan when you do not refer indexed columns in your query.

ops$rperumal@PDB10> SELECT *  FROM t WHERE rsn2 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    36 |    15   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |    36 |    15   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("RSN2"=55)

ops$rperumal@PDB10> SELECT cv20,rsn2, data  FROM t WHERE rsn2 = 55;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    18 |    15   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |    18 |    15   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("RSN2"=55)

 
Case 3:  Implicit or Explict data type conversion to Number

When you have a indexed character column and the column holds only numeric values,  following may turn index access to a full table scan.

ops$rperumal@PDB10> SELECT * FROM t WHERE data = 1;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    36 |    16   (7)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |    36 |    16   (7)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_NUMBER("DATA")=1)

ops$rperumal@PDB10> SELECT * FROM t WHERE to_number(data)=1;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    36 |    16   (7)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |     1 |    36 |    16   (7)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(TO_NUMBER("DATA")=1)

Case 4: Using function on an indexed column

If you use a function on an indexed column similar to below then index will not be used unless there is a matching function based index.

SELECT * FROM t WHERE your_function(data) = my_value

Case 5: Counting Records

If you issue a query similar below and it has a B*Tree Index then no NULL records will make it into the index; Hence, the optimizer will do a Full Table Scan to get the count of rows.

SELECT COUNT(*) FROM t

Case 6: Missing Statistics

If the optimizer is not aware of the data then it will lead to incorrect cardinality; it could result in full table scans.

You can not say “all full table scans are bad and all indexes are good” – It depends your data and what question thats been asked.