 Cost Based Optimizer (CBO) and Database Statistics

Whenever a valid SQL statement is processed Oracle has to decide

how to retrieve the necessary data. This decision can be made using
one of two methods:
 Rule Based Optimizer (RBO) - This method is used if the server
has no internal statistics relating to the objects referenced by
the statement. This method is no longer favoured by Oracle and
will be desupported in future releases.
 Cost Based Optimizer (CBO) - This method is used if internal
statistics are present. The CBO checks several possible
execution plans and selects the one with the lowest cost, where
cost relates to system resources.

o If new objects are created, or the amount of data in

the database changes the statistics will no longer
represent the real state of the database so the CBO
decision process may be seriously impaired. The
mechanisms and issues relating to maintenance of
internal statistics are explained below:

o Analyze Statement

The ANALYZE statement can be used to gather statistics for a

specific table, index or cluster. The statistics can be computed
exactly, or estimated based on a specific number of rows, or a
percentage of rows:
ANALYZE TABLE employees COMPUTE STATISTICS;
ANALYZE INDEX employees_pk COMPUTE STATISTICS;

ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE

100 ROWS;
ANALYZE TABLE employees ESTIMATE STATISTICS SAMPLE
15 PERCENT;
Automatic Statistics Gathering

The recommended approach to gathering statistics is to allow Oracle to

automatically gather the statistics. Oracle gathers statistics on all database
objects automatically and maintains those statistics in a regularly-scheduled
maintenance job. Automated statistics collection eliminates many of the manual
tasks associated with managing the query optimizer, and significantly reduces
the chances of getting poor execution plans because of missing or stale
statistics.

GATHER_STATS_JOB

Optimizer statistics are automatically gathered with the job  GATHER_STATS_JOB . This job
gathers statistics on all objects in the database which have:

 Missing statistics
 Stale statistics

This job is created automatically at database creation time and is managed by

the Scheduler. The Scheduler runs this job when the maintenance window is
opened. By default, the maintenance window opens every night from 10 P.M. to
6 A.M. and all day on weekends.

The   attribute controls whether the 

stop_on_window_close  continues when the
GATHER_STATS_JOB

maintenance window closes. The default setting for the   attribute is  ,
stop_on_window_close TRUE

causing Scheduler to terminate   when the maintenance window closes.

GATHER_STATS_JOB

The remaining objects are then processed in the next maintenance window.

The GATHER_STATS_JOB job gathers optimizer statistics by calling

the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedur
e. The GATHER_DATABASE_STATS_JOB_PROC procedure collects
statistics on database objects when the object has no previously
gathered statistics or the existing statistics are stale because the
underlying object has been modified significantly (more than 10% of
the
rows).TheDBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC is
an internal procedure, but its operates in a very similar fashion to
the DBMS_STATS.GATHER_DATABASE_STATS procedure using
the GATHER AUTO option. The primary difference is that
the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedur
e prioritizes the database objects that require statistics, so that those
objects which most need updated statistics are processed first. This
ensures that the most-needed statistics are gathered before the
maintenance window closes.

Enabling Automatic Statistics Gathering

Automatic statistics gathering is enabled by default when a database

is created, or when a database is upgraded from an earlier database
release. You can verify that the job exists by viewing
theDBA_SCHEDULER_JOBS view:

SELECT * FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME =

'GATHER_STATS_JOB';

In situations when you want to disable automatic statistics gathering,

the most direct approach is to disable the GATHER_STATS_JOB as
follows:

BEGIN
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
/
 o Automatic statistics gathering relies on
the modification monitoring feature,
described in "Determining Stale
Statistics". If this feature is disabled,
then the automatic statistics gathering
job is not able to detect stale statistics.
This feature is enabled when
the   parameter is set
STATISTICS_LEVEL

to   or  .   is the default value.

TYPICAL ALL TYPICAL

When to Use Manual Statistics

Automatic statistics gathering should be sufficient for most database objects

which are being modified at a moderate speed. However, there are cases where
automatic statistics gathering may not be adequate. Because the automatic
statistics gathering runs during an overnight batch window, the statistics on
tables which are significantly modified during the day may become stale. There
are typically two types of such objects:

 Volatile tables that are being deleted or truncated and rebuilt during the
course of the day.
 Objects which are the target of large bulk loads which add 10% or more
to the object's total size.

For highly volatile tables, there are two approaches:

 The statistics on these tables can be set to NULL. When Oracle

encounters a table with no statistics, Oracle dynamically
gathers the necessary statistics as part of query optimization.
This dynamic sampling feature is controlled by
the OPTIMIZER_DYNAMIC_SAMPLING parameter, and this
parameter should be set to a value of 2 or higher. The default
value is 2. The statistics can set to NULL by deleting and then
locking the statistics:
 BEGIN
 DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS');
 DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS');
 END;
 /

 The statistics on these tables can be set to values that represent the
typical state of the table. You should gather statistics on the table when
the tables has a representative number of rows, and then lock the
statistics.

This is more effective than the  , because any statistics generated

GATHER_STATS_JOB

on the table during the overnight batch window may not be the most
appropriate statistics for the daytime workload.

For tables which are being bulk-loaded, the statistics-gathering procedures

should be run on those tables immediately following the load process, preferably
as part of the same script or job that is running the bulk load.

For external tables, statistics are not collected during  ,  , and

GATHER_SCHEMA_STATS GATHER_DATABASE_STATS

automatic statistics gathering processing. However, you can collect statistics on

an individual external table using  . Sampling on external tables is not
GATHER_TABLE_STATS

supported so the   option should be explicitly set to  . Because data

ESTIMATE_PERCENT NULL

manipulation is not allowed against external tables, it is sufficient to analyze

external tables when the corresponding file changes.

Manual Statistics Gathering

If you choose not to use automatic statistics gathering, then you need to
manually collect statistics in all schemas, including system schemas. If the data
in your database changes regularly, you also need to gather statistics regularly to
ensure that the statistics accurately represent characteristics of your database
objects.

When to Gather Statistics

When gathering statistics manually, you not only need to determine how to
gather statistics, but also when and how often to gather new statistics.

For an application in which tables are being incrementally modified,

you may only need to gather new statistics every week or every
month. The simplest way to gather statistics in these environment is
to use a script or job scheduling tool to regularly run
the GATHER_SCHEMA_STATS and GATHER_DATABASE_STATS proce
dures. The frequency of collection intervals should balance the task
of providing accurate statistics for the optimizer against the
processing overhead incurred by the statistics collection process.

For tables which are being substantially modified in batch operations,

such as with bulk loads, statistics should be gathered on those tables
as part of the batch operation. The DBMS_STATS procedure should
be called as soon as the load operation completes.

For partitioned tables, there are often cases in which only a single
partition is modified. In those cases, statistics can be gathered only
on those partitions rather than gathering statistics for the entire
table. However, gathering global statistics for the partitioned table
may still be necessary.

Determining Stale Statistics

Statistics must be regularly gathered on database objects as those

database objects are modified over time. In order to determine
whether or not a given database object needs new database
statistics, Oracle provides a table monitoring facility. This monitoring
is enabled by default when STATISTICS_LEVEL is set
to TYPICAL or ALL. Monitoring tracks the approximate number
of INSERTs, UPDATEs, and DELETEs for that table, as well as
whether the table has been truncated, since the last time statistics
were gathered. The information about changes of tables can be
viewed in the USER_TAB_MODIFICATIONS view. Following a data-
modification, there may be a few minutes delay while Oracle
propagates the information to this view. Use
the DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO procedur
e to immediately reflect the outstanding monitored information kept
in the memory.

The GATHER_DATABASE_STATS or GATHER_SCHEMA_STATS proced
ures gather new statistics for tables with stale statistics when
the OPTIONS parameter is set
to GATHER STALE or GATHER AUTO. If a monitored table has been
modified more than 10%, then these statistics are considered stale
and gathered again.
DBMS_STATS

As database administrator, you can generate statistics that quantify the data
distribution and storage characteristics of tables, columns, indexes, and
partitions. The cost-based optimization approach uses these statistics to
calculate the selectivity of predicates and to estimate the cost of each
execution plan. Selectivity is the fraction of rows in a table that the SQL
statement's predicate chooses. The optimizer uses the selectivity of a
predicate to estimate the cost of a particular access method and to determine
the optimal join order and join method.

The statistics are stored in the data dictionary and can be exported from one
database and imported into another. For example, you might want to transfer
your statistics to a test system to simulate your production environment.

You should gather statistics periodically for objects where the statistics
become stale over time because of changing data volumes or changes in
column values. New statistics should be gathered after a schema object's
data or structure are modified in ways that make the previous statistics
inaccurate. For example, after loading a significant number of rows into a
table, collect new statistics on the number of rows. After updating data in a
table, you do not need to collect new statistics on the number of rows, but
you might need new statistics on the average row length.

Use the DBMS_STATS package to generate statistics.

The DBMS_STATS package was introduced in Oracle 8i and is

Oracles preferred method of gathering object statistics. Oracle list a
number of benefits to using it including parallel execution, long term
storage of statistics and transfer of statistics between servers. Once
again, it follows a similar format to the other methods:

Statistics generated include the following:

 Table statistics
o Number of rows
o Number of blocks
o Average row length
 Column statistics
 o Number of distinct values (NDV) in column
o Number of nulls in column
o Data distribution (histogram)
 Index statistics
o Number of leaf blocks
o Levels
o Clustering factor
 System statistics
o I/O performance and utilization
o CPU performance and utilization

Generating Statistics
Because the cost-based approach relies on statistics, you should generate
statistics for all tables and clusters and all indexes accessed by your SQL
statements before using the cost-based approach. If the size and data
distribution of the tables change frequently, then regenerate these statistics
regularly to ensure the statistics accurately represent the data in the tables.

Oracle generates statistics using the following techniques:

 Estimation based on random data sampling

 Exact computation
 User-defined statistics collection methods

To perform an exact computation, Oracle requires enough space to perform a

scan and sort of the table. If there is not enough space in memory, then
temporary space might be required. For estimations, Oracle requires enough
space to perform a scan and sort of only the rows in the requested sample of the
table. For indexes, computation does not take up as much time or space.

Some statistics are computed exactly, such as the number of data blocks
currently containing data in a table or the depth of an index from its root block
to its leaf blocks.

Oracle Corporation recommends setting the ESTIMATE_PERCENT parameter of

the DBMS_STATS gathering procedures to DBMS_STATS.AUTO_SAMPLE_SIZE to
maximize performance gains while achieving necessary statistical
accuracy. AUTO_SAMPLE_SIZE lets Oracle determine the best sample size for good
statistics. For example, to collect table and column statistics for all tables in
the OEschema with auto-sampling:
EXECUTE
DBMS_STATS.GATHER_SCHEMA_STATS('OE',DBMS_STATS.AUTO
_SAMPLE_SIZE);

To estimate statistics, Oracle selects a random sample of data. You can specify
the sampling percentage and whether sampling should be based on rows or
blocks. Oracle Corporation recommends
using DBMS_STATS.AUTO_SAMPLE_SIZE for the sampling percentage. When in
doubt, choose row sampling.

 Row sampling reads rows without regard to their physical placement on

disk. This provides the most random data for estimates, but it can result
in reading more data than necessary. For example, in the worst case a
row sample might select one row from each block, requiring a full scan
of the table or index.
 Block sampling reads a random sample of blocks and uses all of the
rows in those blocks for estimates. This reduces the amount of I/O
activity for a given sample size, but it can reduce the randomness of the
sample if rows are not randomly distributed on disk. Block sampling is
not available for index statistics.

When you generate statistics for a table, column, or index, if the data
dictionary already contains statistics for the object, then Oracle updates the
existing statistics. Oracle also invalidates any currently parsed SQL
statements that access the object.

The next time such a statement executes, the optimizer automatically

chooses a new execution plan based on the new statistics. Distributed
statements issued on remote databases that access the analyzed objects use
the new statistics the next time Oracle parses them.

When you associate a statistics type with a column or domain index, Oracle
calls the statistics collection method in the statistics type, if you analyze the
column or domain index.

System Statistics

System statistics describe the system's hardware characteristics, such as I/O and
CPU performance and utilization, to the query optimizer. When choosing an
execution plan, the optimizer estimates the I/O and CPU resources required for
each query. System statistics enable the query optimizer to more accurately
estimate I/O and CPU costs, enabling the query optimizer to choose a better
execution plan.

When Oracle gathers system statistics, it analyzes system activity in a

specified time period (workload statistics) or simulates a workload
(noworkload statistics). The statistics are collected using
theDBMS_STATS.GATHER_SYSTEM_STATS procedure. Oracle
Corporation highly recommends that you gather system statistics.

Optimizer System Statistics in the DBMS_STAT Package

Parameter Options for Gathering or

Name Description Initialization Setting Statistics Unit
cpuspeedNW
Represents At system Set   = 
gathering_mode  or set
NOWORKLOAD Millions/sec.
noworkload startup statistics manually.
CPU speed.
CPU speed is
the average
number of CPU
cycles in each
second.
ioseektim
I/O seek time At system Set   = 
gathering_mode  or set
NOWORKLOAD ms
equals seek time startup statistics manually.
+ latency time + 10 (default)
operating
system
overhead time.
iotfrspeed
I/O transfer At system Set   = 
gathering_mode  or set
NOWORKLOAD Bytes/ms
speed is the rate startup statistics manually.
at which an 4096
Oracle database (default)
can read data in
the single read
request.
cpuspeed
Represents None Set   = 
gathering_mode ,  ,
NOWORKLOAD INTERVAL Millions/sec.
workload CPU or  , or set statistics
START|STOP

speed. CPU manually.

speed is the
average number
of CPU cycles
in each second.
maxthr
Maximum I/O None Set  gathering_mode  = NOWORKLOAD , INTERVAL , Bytes/sec.
Parameter Options for Gathering or
Name Description Initialization Setting Statistics Unit
throughput is or  , or set statistics
START|STOP

the maximum manually.

throughput that
the I/O
subsystem can
deliver.
slavethr
Slave I/O None Set   = 
gathering_mode  or 
INTERVAL START|STOP , Bytes/sec.
throughput is or set statistics manually.
the average
parallel slave
I/O throughput.
sreadtim
Single block None Set   = 
gathering_mode  or 
INTERVAL START|STOP , ms
read time is the or set statistics manually.
average time to
read a single
block randomly.
mreadtim
Multiblock read None Set   = 
gathering_mode  or 
INTERVAL START|STOP , ms
is the average or set statistics manually.
time to read a
multiblock
sequentially.
mbrc
Multiblock None Set   = 
gathering_mode  or 
INTERVAL START|STOP , blocks
count is the or set statistics manually.
average
multiblock read
count
sequentially.

Unlike table, index, or column statistics, Oracle does not invalidate already
parsed SQL statements when system statistics get updated. All new SQL
statements are parsed using new statistics.

Workload Statistics

Workload statistics, introduced in Oracle 9i, gather single and

multiblock read times, mbrc, CPU speed (cpuspeed), maximum
system throughput, and average slave throughput.
The sreadtim, mreadtim, and mbrcare computed by comparing
the number of physical sequential and random reads between two
points in time from the beginning to the end of a workload. These
values are implemented through counters that change when the
buffer cache completes synchronous read requests. Since the
counters are in the buffer cache, they include not only I/O delays,
but also waits related to latch contention and task switching.
Workload statistics thus depend on the activity the system had during
the workload window. If system is I/O bound—both latch contention
and I/O throughput—it will be reflected in the statistics and will
therefore promote a less I/O intensive plan after the statistics are
used. Furthermore, workload statistics gathering does not generate
additional overhead.

In release 9.2, maximum I/O throughput and average slave

throughput were added to set a lower limit for a full table scan (FTS).

Gathering Workload Statistics

To gather workload statistics, either:

 Run
the dbms_stats.gather_system_stats('start') proce
dure at the beginning of the workload window, then
the dbms_stats.gather_system_stats('stop') proced
ure at the end of the workload window.
 Run dbms_stats.gather_system_stats('interval',
interval=>N) where N is the number of minutes when
statistics gathering will be stopped automatically.

To delete system statistics,

run dbms_stats.delete_system_stats(). Workload statistics
will be deleted and reset to the default noworkload statistics.
Multiblock Read Count

In release 10.2, the optimizer uses the value of   when performing full table
mbrc

scans (FTS). The value of   is set to the maximum allowed by the
db_file_multiblock_read_count

operating system by default. However, the optimizer uses   for costing. The
mbrc=8

"real"   is actually somewhere in between since serial multiblock read requests
mbrc

are processed by the buffer cache and split in two or more requests if some
blocks are already pinned in the buffer cache, or when the segment size is
smaller than the read size. The   value gathered as part of workload statistics is
mbrc

thus useful for FTS estimation.

During the gathering process of workload statistics, it is possible

that   and 
mbrc  will not be gathered if no table scans are performed during
mreadtim

serial workloads, as is often the case with OLTP systems. On the other hand, FTS
occur frequently on DSS systems but may run parallel and bypass the buffer
cache. In such cases,   will still be gathered since index lookup are performed
sreadtim

using the buffer cache. If Oracle cannot gather or validate gathered   or  , mbrc mreadtim

but has gathered   and  , then only 

sreadtim  and   will be used for costing.
cpuspeed sreadtim cpuspeed

FTS cost will be computed using analytical algorithm implemented in previous

releases. Another alternative to computing   and   is to force FTS in serial
mbrc mreadtim

mode to allow the optimizer to gather the data.

Noworkload Statistics

Noworkload statistics consist of I/O transfer speed, I/O seek time, and CPU
speed ( ). The major difference between workload statistics and noworkload
cpuspeednw

statistics lies in the gathering method.

Noworkload statistics gather data by submitting random reads against all data
files, while workload statistics uses counters updated when database activity
occurs.   represents the time it takes to position the disk head to read data.
isseektim

Its value usually varies from 5 ms to 15 ms, depending on disk rotation speed
and the disk or RAID specification. The I/O transfer speed represents the speed
at which one operating system process can read data from the I/O subsystem.
Its value varies greatly, from a few MBs per second to hundreds of MBs per
second. Oracle uses relatively conservative default settings for I/O transfer
speed.

In Oracle 10g, Oracle uses noworkload statistics and the CPU cost model by
default. The values of noworkload statistics are initialized to defaults at the first
instance startup:
ioseektim = 10ms
iotrfspeed = 4096 bytes/ms
cpuspeednw = gathered value, varies based on system

If workload statistics are gathered, noworkload statistics will be ignored and

Oracle will use workload statistics instead.

Gathering Noworkload Statistics

To gather noworkload statistics,

run dbms_stats.gather_system_stats() with no arguments.
There will be an overhead on the I/O system during the gathering
process of noworkload statistics. The gathering process may take
from a few seconds to several minutes, depending on I/O
performance and database size.

The information is analyzed and verified for consistency. In some

cases, the value of noworkload statistics may remain its default
value. In such cases, repeat the statistics gathering process or set
the value manually to values that the I/O system has according to its
specifications by using
the dbms_stats.set_system_stats procedure.

Locking Statistics for a Table or Schema

Statistics for a table or schema can be locked. Once statistics are

locked, no modifications can be made to those statistics until the
statistics have been unlocked. These locking procedures are useful in
a static environment in which you want to guarantee that the
statistics never change.

The DBMS_STATS package provides two procedures for locking and

two procedures for unlocking statistics:

 LOCK_SCHEMA_STATS
 LOCK_TABLE_STATS

 UNLOCK_SCHEMA_STATS

 UNLOCK_TABLE_STATS

Estimating Statistics with Dynamic Sampling

The purpose of dynamic sampling is to improve server performance by

determining more accurate estimates for predicate selectivity and statistics for
tables and indexes. The statistics for tables and indexes include table block
counts, applicable index block counts, table cardinalities, and relevant join
column statistics. These more accurate estimates allow the optimizer to produce
better performing plans.

You can use dynamic sampling to:

  Estimate single-table predicate selectivities when collected statistics
cannot be used or are likely to lead to significant errors in estimation.
 Estimate statistics for tables and relevant indexes without statistics.

 Estimate statistics for tables and relevant indexes whose statistics are too
out of date to trust.
How Dynamic Sampling Works

The primary performance attribute is compile time. Oracle determines at compile

time whether a query would benefit from dynamic sampling. If so, a recursive
SQL statement is issued to scan a small random sample of the table's blocks, and
to apply the relevant single table predicates to estimate predicate selectivities.
The sample cardinality can also be used, in some cases, to estimate table
cardinality. Any relevant column and index statistics are also collected.

Depending on the value of the   initialization parameter, a certain

OPTIMIZER_DYNAMIC_SAMPLING

number of blocks are read by the dynamic sampling query.

When to Use Dynamic Sampling

For a query that normally completes quickly (in less than a few seconds), you will
not want to incur the cost of dynamic sampling. However, dynamic sampling can
be beneficial under any of the following conditions:

 A better plan can be found using dynamic sampling.

 The sampling time is a small fraction of total execution time for the query.

 The query will be executed many times.

Dynamic sampling can be applied to a subset of a single table's predicates and

combined with standard selectivity estimates of predicates for which dynamic
sampling is not done.
How to Use Dynamic Sampling to Improve Performance

You control dynamic sampling with the  OPTIMIZER_DYNAMIC_SAMPLING  parameter, which can be
set to a value from   to  . The default is  .
0 10 2

 A value of   means dynamic sampling will not be done.

0

 Increasing the value of the parameter results in more aggressive

application of dynamic sampling, in terms of both the type of tables
sampled (analyzed or unanalyzed) and the amount of I/O spent on
sampling.
Dynamic sampling is repeatable if no rows have been inserted, deleted, or
updated in the table being sampled. The parameter   turns off
OPTIMIZER_FEATURES_ENABLE

dynamic sampling if set to a version prior to 9.2.0.

Getting Statistics for Partitioned Schema Objects

Partitioned schema objects can contain multiple sets of statistics. They can have
statistics that refer to any of the following:

 The entire schema object as a whole (global statistics)

 An individual partition
 An individual subpartition of a composite partitioned object

Unless the query predicate narrows the query to a single partition, the optimizer
uses the global statistics. Because most queries are not likely to be this
restrictive, it is most important to have accurate global statistics. Intuitively, it
can seem that generating global statistics from partition-level statistics is
straightforward; however, this is true only for some of the statistics. For
example, it is very difficult to figure out the number of distinct values for a
column from the number of distinct values found in each partition, because of
the possible overlap in values. Therefore, actually gathering global statistics
with the DBMS_STATS package is highly recommended, rather than calculating
them with the ANALYZE statement.

Using the DBMS_STATS Package

The PL/SQL package DBMS_STATS lets you generate and manage statistics for

cost-based optimization. You can use this package to gather, modify, view,
export, import, and delete statistics. You can also use this package to identify or
name statistics gathered.

The DBMS_STATS package can gather statistics on indexes, tables, columns, and

partitions, as well as statistics on all schema objects in a schema or database. It
does not gather cluster statistics--you can use DBMS_STATS to gather statistics on
the individual tables instead of the whole cluster.

The statistics-gathering operations can run either serially or in parallel. Index

statistics are not gathered in parallel.
For partitioned tables and indexes, DBMS_STATS can gather separate statistics for
each partition, as well as global statistics for the entire table or index. Similarly,
for composite partitioning,DBMS_STATS can gather separate statistics for
subpartitions, partitions, and the entire table or index. Depending on the SQL
statement being optimized, the optimizer can choose to use either the partition
(or subpartition) statistics or the global statistics.

DBMS_STATS gathers only statistics needed for cost-based optimization; it does

not gather other statistics. For example, the table statistics gathered
by DBMS_STATS include the number of rows, number of blocks currently
containing data, and average row length, but not the number of chained rows,
average free space, or number of unused data blocks.

Statistics Gathering Procedures in the DBMS_STATS Package

Procedure Collects

GATHER_INDEX_STATS Index statistics

GATHER_TABLE_STATS Table, column, and index statistics

GATHER_SCHEMA_STATS Statistics for all objects in a schema

Statistics for all dictionary objects
GATHER_DICTIONARY_STATS

GATHER_DATABASE_STATS
Statistics for all objects in a database
CPU and I/O statistics for the system
GATHER_SYSTEM_STATS

EXEC DBMS_STATS.gather_database_stats;
EXEC
DBMS_STATS.gather_database_stats(estimate_percent
=> 15);

EXEC DBMS_STATS.gather_schema_stats('SCOTT');
EXEC DBMS_STATS.gather_schema_stats('SCOTT',
estimate_percent => 15);
EXEC DBMS_STATS.gather_table_stats('SCOTT',
'EMPLOYEES');
EXEC DBMS_STATS.gather_table_stats('SCOTT',
'EMPLOYEES', estimate_percent => 15);

EXEC DBMS_STATS.gather_index_stats('SCOTT',
'EMPLOYEES_PK');
EXEC DBMS_STATS.gather_index_stats('SCOTT',
'EMPLOYEES_PK', estimate_percent => 15);
This package also gives you the ability to delete statistics:
EXEC DBMS_STATS.delete_database_stats;
EXEC DBMS_STATS.delete_schema_stats('SCOTT');
EXEC DBMS_STATS.delete_table_stats('SCOTT',
'EMPLOYEES');
EXEC DBMS_STATS.delete_index_stats('SCOTT',
'EMPLOYEES_PK');

Statistics on Tables, Indexes and Columns

Statistics on tables, indexes, and columns are stored in the data

dictionary. To view statistics in the data dictionary, query the
appropriate data dictionary view (USER, ALL, or DBA).
These DBA_* views include the following:

 DBA_TABLES
 DBA_OBJECT_TABLES

 DBA_TAB_STATISTICS

 DBA_TAB_COL_STATISTICS

 DBA_TAB_HISTOGRAMS

 DBA_INDEXES

 DBA_IND_STATISTICS
  DBA_CLUSTERS

 DBA_TAB_PARTITIONS

 DBA_TAB_SUBPARTITIONS

 DBA_IND_PARTITIONS

 DBA_IND_SUBPARTITIONS

 DBA_PART_COL_STATISTICS

 DBA_PART_HISTOGRAMS

 DBA_SUBPART_COL_STATISTICS

 DBA_SUBPART_HISTOGRAMS

Generating System Statistics

Gather statistics during the day. Gathering ends after 720 minutes and is stored
in the mystats table:
BEGIN
DBMS_STATS.GATHER_SYSTEM_STATS(
gathering_mode => 'interval',
interval => 720,
stattab => 'mystats',
statid => 'OLTP');
END;
/

Gather statistics during the night. Gathering ends after 720 minutes and is
stored in the mystats table:
BEGIN
DBMS_STATS.GATHER_SYSTEM_STATS(
gathering_mode => 'interval',
interval => 720,
stattab => 'mystats',
statid => 'OLAP');
END;
/
If appropriate, you can switch between the statistics gathered. It is possible to
automate this process by submitting a job to update the dictionary with
appropriate statistics.

During the day, the following jobs import the OLTP statistics for the daytime
run:
VARIABLE jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,
'DBMS_STATS.IMPORT_SYSTEM_STATS(''mystats'',''OLTP'');'
SYSDATE, 'SYSDATE + 1');
COMMIT;
END;
/

During the night, the following jobs import the OLAP statistics for the
nighttime run:
BEGIN
DBMS_JOB.SUBMIT(:jobno,
'DBMS_STATS.IMPORT_SYSTEM_STATS(''mystats'',''OLAP'');'
SYSDATE + 0.5, 'SYSDATE + 1');
COMMIT;
END;
/