Computing Oracle Statistics

The cost-based optimizer is the preferred method of optimization for an Oracle database. The calculation of the cost of a particular execution path is determined by a set of statistics that describe the composition of the tables and indexes in the database. You have two choices as to when you want to gather these all-important statistics.

You can gather statistics on an index while rebuilding the index, as the following example shows:

SQL>alter index hr.emp_emp_id_pk rebuild compute statistics;

Index altered.
You save time by having the database gather statistics while it's rebuilding the index.

When performing a query, Oracle will need to maintain a read-consistent image of the rows queried. If a row is modified by another user, the database will need to retrieve the earlier version of the blocks from the undo segment to see the row as it existed at the time your query began. Application designs that call for queries to frequently access data that others may be changing at the same time force the database to do more work, it has to look in multiple locations for one piece of data. Again, this is a design issue. DBAs may be able to size the undo segment areas to reduce the possibility of queries encountering errors, but correcting the fundamental problem requires a change to the application design.

Oracle's optimizer relies on statistics when it evaluates the thousands of possible paths to take during the execution of a query. How you manage those statistics can significantly impact the performance of your queries.

How often should you gather statistics? With each major change to the data in your tables, you should reanalyze the tables. If you have partitioned the tables, you can analyze them on a partition-by-partition basis. You can use the Automatic Statistics Gathering feature to automate the collection of statistics. By default, that process gathers statistics during a maintenance window from 11 P.M. to 7 A.M. each night and all day on weekends. Since the analysis job is usually a batch operation performed after hours, you can tune it by improving sort and full table scan performance at the session level. The result will be greatly enhanced performance for the sorts and full table scans the analysis performs.

Computing statistics as a part of the creation process for an index incurs very little overhead. If the COMPUTE STATISTICS keywords are not a part of the

CREATE INDEX

statement, no statistics will be created until you explicitly compute them. You can also compute statistics explicitly with the following syntax with the ANALYZE command:

Keep in mind that statistics are always relative. The basic relevance of statistics is to give an approximation of the size and composition of the objects in your database. These statistics are then used to calculate the cost of a particular execution path option. If the composition of your database changes in a relatively small way, the new statistics will probably not change the decision of the cost-based optimizer. Adding 1,000 rows to a table that already contains 100,000 rows will usually not change the outcome of cost-based optimization. However, if those 1,000 rows add 1,000 unique values to a table that currently contains only 100 unique values, the new rows could indeed affect the selection of an execution path. In general, you should compute statistics as a standard part of your maintenance procedures, or whenever an event, such as a large data load, could affect the composition of your database. In the next lesson, you will learn about domain indexing.

Click the Quiz link below to test your knowledge about index enhancements.
Computing Statistics - Quiz