Reducing the Cost:

Overview of Indexes:

An index is an optional structure, associated with a table or table cluster, that can sometimes speed data
access. By creating an index on one or more columns of a table, you gain the ability in some cases to
retrieve a small set of randomly distributed rows from the table. Indexes are one of many means of
reducing disk I/O.

If a heap-organized table has no indexes, then the database must perform a full table scan to find a
value. For example:-

In general, consider creating an index on a column in any of the following situations:

1. The indexed columns are queried frequently and return a small percentage of the total number of
rows in the table.

2. A referential integrity constraint exists on the indexed column or columns. The index is a means to
avoid a full table lock that would otherwise be required if you update the parent table primary key,
merge into the parent table, or delete from the parent table.

3. A unique key constraint will be placed on the table and you want to manually specify the index and
all index options.

The database automatically maintains and uses indexes after they are created. The database also
automatically reflects changes to data, such as adding, updating, and deleting rows, in all relevant
indexes with no additional actions required by users. Retrieval performance of indexed data remains
almost constant, even as rows are inserted. However, the presence of many indexes on a table degrades
DML performance because the database must also update the indexes.

Indexes have the following properties:

1. Usability

Indexes are usable (default) or unusable. An unusable index is not maintained by DML operations and is
ignored by the optimizer. An unusable index can improve the performance of bulk loads. Instead of
dropping an index and later re-creating it, you can make the index unusable and then rebuild it.
Unusable indexes and index partitions do not consume space. When you make a usable index unusable,
the database drops its index segment.

2. Visibility
Indexes are visible (default) or invisible. An invisible index is maintained by DML operations and is not
used by default by the optimizer. Making an index invisible is an alternative to making it unusable or
dropping it. Invisible indexes are especially useful for testing the removal of an index before dropping it
or using indexes temporarily without affecting the overall application.

Types of indexes in oracle with example

There are 6 different types of indexes in oracle

1) B-Tree

2) Compressed B-Tree

3) Bitmap

4) Function-Based

5) Reverse Key (RKI)

1) B-Tree:

This is Oracle’s default index type. It is a highly flexible index with well-understood performance
characteristics.

The B*-Tree index has a hierarchical tree structure. At the top of the tree is the header block. This block
contains pointers to the appropriate branch block for a given range of key values. The branch block will
usually point to the appropriate leaf block for a more specific range or, for a larger index, point to
another branch block. The leaf block contains a list of key values and pointers (ROWIDS) to the
appropriate rows in the table.

1. B-Tree Indexes (balanced tree) are the most common type of index.

2. B-Tree index stored the ROWID and the index key value in a tree structure.

3. When creating an index, a ROOT block is created, then BRANCH blocks are created and finally LEAF
blocks.

4. Each branch holds the range of data its leaf blocks hold, and each root holds the range of data its
branches hold:

5. B-Tree indexes are most useful on columns that appear in the where clause (SELECT … WHERE
EMPNO=1).

6. The Oracle server, keeps the tree balanced by splitting index blocks, when new data is inserted to the
table.
7. Whenever a DML statement is performed on the index’s table, index activity occurs, making the index
to grow (add leaf and branches).

A b-tree index would work like this:

1. Determine the record (or the page, in this case) we are

looking for. In this case, it is 125 (the page number).
2. Look at the first level of the index to find the range of values
that includes the number 125. The ranges could be broken up
into groups of 100: 1-100, 101-200, 201-300, 301-400.
3. Move to the second level of the index that was identified in
the previous step. In this case it would be the range of 101-
200, because 125 sits in that range.
4. Find the range of values in the second level that covers 125.
This could be in groups of 20: 101-120, 121-140, 141-160, 161-
180, 181-200. In this case it would be the range 121-140.
5. Find the record that has an ID of 125 and return that record.
CREATE INDEX idx_topic_pageno

ON topic(page_no);

Bitmap index example in Oracle

Oracle has what are called bitmap indexes, which are meant to be used on lower cardinality columns. A
low cardinality column just means that the column has relatively few unique values. For example, a
column called Sex which has only “Male” and “Female” as the two possible values is considered low
cardinality because there are only two unique values in the column.

A bitmap index will create separate structures for each unique value of the column(s) – so in our
example, there will be one structure for “Male” and another for “Female”. And each structure will
contain the same number of rows as the table. For each row inside each of those structures there will
be a binary bit of 0 or 1. A 0 means that in that row corresponding to the table the structure value is
not present, but a 1 means that it is present. That is why it’s called a bitmap index.

When dealing with bitmap indexes, the RDBMS will actually use matrix algebra to find the rows that
are being looked up.
Syntax for creating a bit map index in Oracle
Here’s an example of what the syntax would look like to create a bit map index in Oracle – note the
use of the keyword BITMAP in the syntax below:

CREATE BITMAP INDEX IX_PEOPLE_NAME

ON PEOPLE (NAME);

Bitmap indexes can help performance where the tables have a large number of rows, the columns
have a few distinct values, and the WHERE clause contains multiple predicates using these columns.
Do not use bitmap indexes on tables or columns that are frequently updated.

Bitmap indexes are primarily designed for data warehousing or environments in which queries
reference many columns in an adhoc fashion. Situations that may call for a bitmap index include:

 The indexed columns have low cardinality, that is, the number of distinct values is small compared to
the number of table rows.
 The indexed table is either read-only or not subject to significant modification by DML statements

For a data warehouse example, the sh.customers table has a cust_gender column with only two
possible values: M and F. Suppose that queries for the number of customers of a particular gender
are common. In this case, the customers.cust_gender column would be a candidate for a bitmap
index.

What is compressed B-tree Indexes

Compressed B-Tree Indexes are built on large tables, in a data warehouse

environment. In this type of index, duplicate occurrences of the same value are
eliminated, thus reducing the amount of storage space, the index requires. In a
compressed B-Tree index, for each key value, a list of ROWIDs are kept:

Specifying the COMPRESS keyword when creating an index (CREATE INDEX …

COMPRESS) will create a compressed B-Tree index. A regular B-Tree index can be
rebuilt using the COMPRESS keyword to compress it.

CREATE <UNIQUE|NON UNIQUE> INDEX <index_name>

ON <table_name> (<column_name>,<column_name>…)
PCTFREE <integer>

TABLESPACE <tablespace_name>

Compress <column number>

Function Based Indexes

Function-Based Indexes are indexes created on columns that a function is usually

applied on.

When using a function on an indexed column, the index is ignored, therefore a function-
based index is very useful for these operations.

CREATE INDEX <index_name>

ON <table_name> [ Function(<column_name>,<column_name.)]

TABLESPACE <tablespace_name>;

Example

CREATE INDEX EMP_IDX on EMP(UPPER(ENAME));

SELECT *

FROM Emp

WHERE UPPER(Ename) like ‘JOHN`;

What is Reverse-Key Indexes

They are special types of B-Tree indexes and are very useful when created on columns
contain sequential numbers.
When using a regular B-Tree, the index will grow to have many branches and perhaps
several levels, thus causing performance degradation, the RKI solve the problem by
reversing the bytes of each column key and indexing the new data.

This method distributes the data evenly in the index. Creating a RKI is done using the
REVERSE keyword: CREATE INDEX … ON … REVERSE;

CREATE INDEX <index_name>

ON <table_name> (<column_name>)

TABLESPACE <tablespace_name>

REVERSE;

Example

CREATE INDEX emp_idx i ON emp_table (firstname,lastname)

REVERSE;