Database Tutorial

Week 9: Articles

Indexes

Learning Outcomes

• Learn how indexes work.
• Learn how create unique and non-unique indexes.

Lesson Materials

Indexes are separate data structures that provide alternate pathways to finding data. They can and do generally speed up the processing of queries and other DML commands, like the INSERT, UPDATE, MERGE, and DELETE statements. Indexes are also called fast access paths.

The Oracle Database 12c database maintains the integrity of indexes after you create them. The upside of indexes is that they can improve SQL statement performance. The downside is that they impose overhead on every INSERT, UPDATE, MERGE, and DELETE statement because the database maintains them by inserting, updating, or deleting items for each related change in the tables that the indexes support.

Indexes have two key properties—usability and visibility. Indexes are both usable and visible by default. That means they are visible to the Oracle Database 12c cost-based optimizer and usable when statements run against the tables they support.

You have the ability to make any index invisible, in which case queries and DML statements won’t use the index because they won’t see it. However, the cost-based optimizer still sees the index and maintains it with any DML statement change. That means making an index invisible isn’t quite like making the index unusable or like dropping it temporarily. An invisible index becomes overhead and thus is typically a short-term solution to run a resource-intensive statement that behaves better without the index while avoiding the cost of rebuilding it after the statement runs.

It is also possible to make an index unusable, in which case it stops collecting information and becomes obsolete and the database drops its index segment. You rebuild the index when you change it back to a usable index.

Indexes work on the principal of a key. A key is typically a set of columns or expressions on which you can build an index, but it’s possible that a key can be a single column. An index based on a set of columns is a composite, or concatenated, index.

Indexes can be unique or nonunique. You create a unique index anytime you constrain a column by assigning a primary key or unique constraint, but they’re indirect indexes. You create a direct unique index on a single column with the following syntax against two nonunique columns:

CREATE INDEX       common_lookup_nuidx
ON common_lookup ( common_lookup_table );

You could convert this to a nonunique index on two columns by using this syntax:

CREATE INDEX         common_lookup_nuidx
  ON common_lookup ( common_lookup_table, common_lookup_column);

Making the index unique is straightforward; you only need to add a unique keyword to the CREATE INDEX statement, like

CREATE UNIQUE INDEX  common_lookup_nuidx
  ON common_lookup  ( common_lookup_table
                    , common_lookup_column
                    , common_lookup_type );

Most indexes use a B-tree (balanced tree). A B-tree is composed of three types of blocks—a root branch block for searching next-level blocks, branch blocks for searching other branch blocks, and leaf blocks that store pointers to row values. B-trees are balanced because all leaf- blocks are at the same level, which means the length of search is the same to any element in the tree. All branch blocks store the minimum key prefix required to make branching decisions through the B-tree.

There are six schemas for creating B-tree indexes and a couple of schemas for creating bitmap indexes. The B-tree schemas are described first, followed by a description of a single bitmap schema.

Index-Organized Tables

Index-organized tables are stored in a variation of a B-tree index structure. The rows of an index-organized table are stored in an index defined by the primary key for the table. Each index entry in the B-tree also holds the values of non-key columns. Index- organized tables provide faster access to the table rows through the primary key, and the presence of non-key columns of the row foregoes additional data block I/O.

Reverse Key Indexes

A reverse key index is a type of B-tree index that reverses the physical byte order of each index key while keeping columns in sequence. Reversing the key solves contention problems for leaf blocks in the right side of a B-tree index. Moreover, a reversal of the byte order distributes inserts across all leaf keys in the index.

Ascending and Descending Indexes Ascending indexes are the Oracle default, and they store character data by their binary values, store numeric data from smallest to largest number, and store dates from earliest to latest value. A descending index reverses the sort order.

You create a composite nonunique descending index by appending the DESC keyword to the creation statement:

CREATE INDEX       common_lookup_nuidx
ON common_lookup ( common_lookup_table, common_lookup_column ) DESC;

Descending indexes are most useful when queries sort some columns in ascending order and other columns in descending order. The Oracle database searches key values to find and then use the associated ROWID values.

B-tree Cluster Indexes

A B-tree cluster index is a table cluster that uses a cluster key to find data. You must create a cluster before you create the tables. The following shows how to create a cluster:

CREATE CLUSTER sales_records ( cost_center_id NUMBER(4)) SIZE 512;

The syntax to create the index is

CREATE INDEX sales_uidx ON CLUSTER sales_records;

Finally, you’d create the tables like this:

CREATE TABLE eastern_region (<column_list>)
  CLUSTER sales_records (cost_center_id);
 
CREATE TABLE western_region (<column_list>)
  CLUSTER sales_records (cost_center_id);

This type of configuration ensures rows from both tables are written inside the same file block. The database then stores the rows in a heap and locates them with the index.

Function-based Indexes

Function-based indexes are efficient for evaluating statements that contain functions in their WHERE clauses. The Oracle Database 12c database only uses the function-based index when queries use functions in the WHERE clause.

You create a function-based index with the following syntax:

CREATE INDEX   employee_uidx
  ON employee (salary + commission_percent, salary, commission_percent);

The function is triggered when a query includes a like arithmetic expression:

SELECT   employee_id
,        first_name
,        last_name
,       (salary + commission_percent) AS annual_salary
FROM     employee e
WHERE   (salary + commission_percent) > 100000
ORDER BY annual_salary DESC;

The optimizer can use an index range scan on a function-based index for queries with an expression in the WHERE clause. The range scan access path has better benefits when the WHERE clause has low selectivity. Selectivity is calculated by dividing cardinality by the number of records in a table. For example, a column with 75 distinct values and 5,000 records has a 1.5 percent selectivity.

Application Domain Indexes

An application domain index is a customized index designed to support an application. Oracle Database 12c provides extensible indexing to do the following:

• Work with indexes on customized, complex data types such as documents, spatial data, images, video clips, and other unstructured data
• Make use of specialized indexing techniques

You use a cartridge to control the structure and content of a domain index. The database interacts with the application to build, maintain, and search the domain index.

Bitmap Indexes

A bitmap index stores a bit array for each index key. Bitmap indexes are best suited to data warehousing systems where queries are ad hoc, and work against tables with low cardinality. Bitmapped indexes are expensive and ill suited to read-write tables with frequent changes to the data. Bitmaps work best with data that is either read-only or not subject to significant changes.