Indexes

Usage of index by COB is affected by the following

 Size of the table
 Amount of data returned by query
 Distribution of data values on indexed columns
(histogram)
 Searching for nulls
 Functions used on indexed columns in where clause

Why do we use indexes?

 To make select queries faster – by avoiding FTS
 What about insert, update, delete?
B-Tree Index

Oracle recommends using B-Tree index when result set returns

less than 5% of rows in a table

When are indexes suppressed

 Where emp_name != ‘Shekhar’  inequaliy

 Where emp_name is null
 Where emp_name is not null
 Where emp_id = ‘1234’  implicit data conversion
  W
h
e
r
e

upper(emp_name) = ‘SHEKHAR’  use of function

What is Binary Level/Binary Height

 It is the depth of the B-Tree. (levels from root node
to lead nodes)

When to rebuild indexes

 BLevel > 4
 Waasted space > 20%

Validate Structure clause will populate INDEX_STATS view,

which can be queried to find out wasted space as follows

How to rebuild index

 Drop and recreate the index from scratch.

 Rebuild the index using the ALTER INDEX … REBUILD
command (exclusive locking of index happens)
 Rebuild the index using the ALTER INDEX … COALESCE
command. (does not need more disk space to rebuild. But
cannot be used to move to another tablespace)

Examples
 Alter index idx_emp rebuild;
 Alter index idx_emp rebuild parallel;
  Alter index idx_emp rebuild nologging
 Alter index idx_emp coalesce;

How to monitor if indexed is being used or not

 ALTER INDEX hr.emp_last_name_idx MONITORING USAGE;
 ALTER INDEX hr.emp_last_name_idx NOMONITORING USAGE;
 Select index_name, used
from v$object_usage
where used= ‘NO’

Data Dictionary Views useful for Indexes

 DBA_INDEXES (index_type, compression, status)
 DBA_COL_INDEXES (columns names that are indexed)
 V$OBJECT_USAGE
 INDEX_STATS

What is compressed B-Tree Index

Saves disk space but used more CPU to uncompress
 Bitmap Index

Where to use Bitmap index

 For columns with very few unique values (low
cardinality, Example: gender, states, statues etc.)
o Columns that have low cardinality are good
candidates (if the cardinality of a column is <=
0.1 %  that the column is ideal candidate,
consider also 0.2% – 1%)
 Tables that have no or little insert/update are good
candidates (static data in warehouse)
 
Structure of BitMap Index
Stream of bits: each bit relates to a column value in a
single row of table
create bitmap index person_region on person (region);

        Row     Region   North   East   West   South

        1       North        1      0      0       0
        2       East         0      1      0       0
        3       West         0      0      1       0
        4       West         0      0      1       0
        5       South        0      0      0       1
        6       North        1      0      0       0

Advantage of Bitmap Indexes

 The advantages of them are that they have a highly
compressed structure, making them fast to read and
their structure makes it possible for the system to
combine multiple indexes together for fast access to
the underlying table.
 Compressed indexes, like bitmap indexes, represent a
trade-off between CPU usage and disk space usage. A
compressed structure is faster to read from disk but
takes additional CPU cycles to decompress for access -
an uncompressed structure imposes a lower CPU load but
requires more bandwidth to read in a short time.
 One belief concerning bitmap indexes is that they are
only suitable for indexing low-cardinality data. This
 is not necessarily true, and bitmap indexes can be used
very successfully for indexing columns with many
thousands of different values.
Disadvantage of Bitmap Indexes
The reason for confining bitmap indexes to data warehouses
is that the overhead on maintaining them is enormous. A
modification to a bitmap index requires a great deal more
work on behalf of the system than a modification to a b-tree
index. In addition, the concurrency for modifications on
bitmap indexes is dreadful.
Initialization parameters

Sort area is extensively used for Bitmap index operations.

So pay special attention to the following parameters
 SORT_AREA_SIZE
 PGA_AGGREGATE_TARGET

Bitmap Indexes and Deadlocks

Bitmap indexes are not appropriate for tables that have lots
of single row DML operations (inserts) and especially
concurrent single row DML operations. Deadlock situations are the result of
concurrent inserts as the following example shows: Open two windows, one for Session 1
and one for Session 2
create table bitmap_index_demo  
(
  value varchar2(20)
);
create bitmap index  
  bitmap_index_demo_idx
  on bitmap_index_demo(value);
insert into bitmap_index_demo  
  values ('M');
1 row created.
  insert into bitmap_index_demo
  values ('F');
1 row created.
insert into bitmap_index_demo  
  values ('F');
...... waiting ......
ERROR at line 1: insert into bitmap_index_demo
ORA-00060: deadlock detected   values ('M');
while waiting for resource ...... waiting ......
Function Based Index

Initialization Parameter
 QUERY_REWRITE_ENABED must be set to true for function
indexes (oracle supposedly rewrites the query for
better performance. Also used for Materialized views)
 OPTIMIZER_MODE=CHOOSE - Must use Cost based optimizer
Reverse Key Index

 The Reverse Key Index (RKI) is a special type of B-Tree

index.
 The RKI is useful when an index is built on a column
that contains sequential numbers
o to avoid contention for a index block (in RAC)
o To avoid deeper levels (binary height) of B-Tree
 Reverse Key Indexes solve this problem by simply
reversing the data in the indexed column by reversing
the bytes of each column key value and then indexing on
the new reversed data, which is generally more evenly
distributed across a range of values than the original
sequential data was.

Example:
 Limitations

 Reverse
Key
indexes
are only
useful
for
equality
and non-
equality

searches. Queries that perform range scans (e.g., using

BETWEEN, >, <) on columns that are Reverse Key indexed
will not be able to use the index and will cause full
table scans.
Index Organized Table (IOT)

Data stored in ordered fashion with index

This results in two performance benefits:

 The table rows are stored in index order. If you access
the table using its primary key, an IOT will return the
rows more quickly than a traditional table.
 The extra I/O experienced by reading the index and then
the table when using B-tree indexes is eliminated.

How to create IOT

 IOT must have a primary key

Mapping table maps the physical rowIDs to logical rowIDs for
maintaining indexes of IOT.

Rows in index-organized tables do not have permanent

physical addresses—they are stored in the index leaves and
can move within the block or to a different block as a
result of insertions. Therefore their row identifiers cannot
be based on physical addresses. Instead, Oracle provides
index-organized tables with logical row identifiers, called
logical rowids, that are based on the table's primary key.
Oracle uses these logical rowids for the construction of
secondary indexes on index-organized tables
What are main steps in SQL execution
 Table Access
o Full Scan
o By ROWID
 Index
o Range Scan
o Unique Scan
o Fast full scan (reads entire index – only leaf
nodes). Used when indexed columns are queried
 Joins
o Nested Loop join
o Merge join
o Hash Join

What are Nested Loop Joins

Select *
From tab1, tab2
Where tab1.col1 = tab2.col2

For I in (select * from tab1)

Loop
For j in (select * from tab2 where col2=i.col1)
Loop
Display results
End Loop
End loop

What are hash Joins

 Build a in-memory hash table on smaller of the two

tables (RW1). Needs more PGA.
 Probe this hash table with hash value for each row
second table (RW2)

For each row RW2 in big (right/probe) table

Loop
Calculate the hash value on RW2 join key
For each row RW1 in hash table
Loop
If RW1 joins with RW2 then Return RW1, RW2
End loop;
End loop;

 Usually for big tables

 Only in equi-joins