Академический Документы
Профессиональный Документы
Культура Документы
An index is a database object used primarily to improve the performance of SQL queries.
The function of a database index is similar to an index in the back of a book. A book index associates a
topic with a page number. When youre locating information in a book, its usually much faster to inspect
the index first, find the topic of interest, and identify associated page numbers. With this information, you
can navigate directly to specific page numbers in the book. In this situation, the number of pages you
need to inspect
is minimal.
If there were no index, you would have to inspect every page of the book to find information. This results
in a great deal of page turning, especially with large books. This is similar to an Oracle query that does
not use an index and therefore has to scan every used block within a table. For large tables, this results in
a great deal of I/O.
The book indexs usefulness is directly correlated with the uniqueness of a topic within the book. For
example, take this book; it would do no good to create an index on the topic of performance because
every page in this book deals with performance. However, creating an index on the topic of bitmap
indexes would be effective because there are only a few pages within the book that are applicable to this
feature.
Keep in mind that the index isnt free. It consumes space in the back of the book, and if the material in the
book is ever updated (like a second edition), every modification (insert, update, delete) potentially
requires a corresponding change to the index. Its important to keep in mind that indexes consume space
and require resources when updates occur.
Also, the person who creates the index for the book must consider which topics will be frequently looked
up. Topics that are selective and frequently accessed should be included in the book index. If an index in
the back of the book is never looked up by a reader, then it unnecessarily wastes space.
Much like the process of creating an index in the back of the book, there are many factors that must be
considered when creating an Oracle index. Oracle provides a wide assortment of indexing features and
options. These objects are manually created by the DBA or a developer. Therefore, you need to be aware
of the various features and how to utilize them. If you choose the wrong type of index or use a feature
incorrectly, there may be detrimental performance implications. Listed next are aspects to consider before
you create an index:
Type of index
Table column(s) to include
Whether to use a single column or a combination of columns
Special features such as parallelism, turning off logging, compression, invisible
indexes, and so on
Uniqueness
Naming conventions
Tablespace placement
Initial sizing requirements and growth
Impact on performance of SELECT statements (improvement)
Impact on performance of INSERT, UPDATE, and DELETE statements
Global or local index, if the underlying table is partitioned
When you create an index, you should give some thought to every aspect mentioned in the previous list.
One of the first decisions you need to make is the type of index and the columns to include. Oracle
provides a robust variety of index types. For most scenarios, you can use the default B-tree (balanced
tree) index. Other commonly used types are concatenated, bitmap, and function-based indexes. In the
next post I will describe the types of indexes available with Oracle
4. Function-based Index: Good for columns that have SQL functions applied to them.
5. Indexed virtual column Index: Good for columns that have SQL functions applied to them; viable
alternative. to using a function-based index.
6. Reverse-key Index: Useful to balance I/O in an index that has many sequential inserts.
7. Key-compressed Index: Useful for concatenated indexes where the leading column is often
repeated, compresses leaf block entries.
8. Bitmap Index: Useful in data warehouse environments with low-cardinality columns. these indexes
arent appropriate for online transaction processing (OLTP) databases
where rows are heavily updated.
9. Bitmap join: Useful in data warehouse environments for queries that join fact and
dimension tables.
10. Global partitioned: Global index across all partitions in a partitioned table.
11. Local partitioned: Local index based on individual partitions in a partitioned table.
Use the ALTER INDEX...MONITORING USAGE statement to enable basic index monitoring. The
following example enables index monitoring on an index named F_REGS_IDX1:
The first time the index is accessed, Oracle records this; you can view whether an index has been
accessed via the V$OBJECT_USAGE view. To report which indexes are being monitored and have ever
been used, run this query:
If the index has ever been used in a SELECT statement, then the USED column will contain the YES
value. Here is some sample output from the prior query:
Most likely, you wont monitor only one index. Rather, youll want to monitor all indexes for a user. In this
situation, use SQL to generate SQL to create a script you can run to turn on monitoring for all indexes.
Heres such a script:
How It Works
The main advantage to monitoring index usage is to identify indexes not being used. This allows you to
identify indexes that can be dropped. This will free up disk space and improve the performance of DML
statements.
The V$OBJECT_USAGE view shows information only for the currently connected user. You can verify
this behavior by inspecting the TEXT column of DBA_VIEWS for the $OBJECT_USAGE definition:
That line instructs the view to display information only for the currently connected user. If youre logged in
as a DBA privileged user and want to view the status of all indexes that have monitoring enabled
(regardless of the user), execute this query:
The prior query removes the line from the query that restricts output to display information only for the
currently logged-in user. This provides you with a convenient way to view all monitored indexes.