Performance Monitoring

The responsibility of a database administrator lies not only in creating a database and
ensuring that it is available at all times to its users, but also making sure it is operating in
top condition. A well tuned and optimized database can draw parallels with a well oiled
machine. However achieving a well tuned and optimized database can be quite a task.
Anyone setting out to tune it should have a thorough understanding of the architecture of
the database, the applications being run on the database and the goals that you are trying
to achieve in the form of concrete values.
Performance tuning has always been an important responsibility for a database
administrator. With earlier releases of the Oracle database, a good part of the database
administrator's time was spent on monitoring database health, identifying bottlenecks and
improving system performance. It was not only tedious and complicated, but also prone
to errors if you are not using proper guidelines.
Very often the most important question is where and with what do we start? The
administrator may also determine if a pattern exists. In earlier versions of administrators
performed tuning by gathering and analyzing statistics in the database. The information
mostly in the form of raw data that the DBA had to deal with could be plenty and quite
difficult to compile. Some administrators would probably invest in a third-party tool or a
homegrown tool to collect elaborate statistics during database operation and derive
performance metrics from them. Hence gathering relevant statistics is a crucial part of
performance tuning.
One of the major enhancements made by the Oracle 10g database over its earlier versions
is a complete overhaul to the way performance tuning is done. The task of the
administrator has been simplified considerably with the introduction of automated tools,
new features and advisors. The Oracle database can provide real information about the
database's health.
In Oracle 10g, a new component known as the Automatic Workload Repository offers a
significant boost to statistics gathering and performance tuning related tasks.

Overview of common manageability feature of Oracle 10g

In earlier versions of Oracle, a major part of a DBA responsibility revolved around
determining solutions to various issues about the health of the database. These
would involve issue associated with space, resource management, backup and
recovery, statistics collection, SQL management and so on. In Oracle 10g the
Oracle Database performs database manageability tasks that automatically inform
the DBA of any performance or resource allocation problems. This is popularly
known as the Manageability infrastructure of Oracle 10g.
The main components of this common manageability infrastructure are:

 The Automatic Workload Repository (AWR) This is central element of

the manageability infrastructure. This component installs with the Oracle
database, and is responsible for collecting, maintaining, processing and
utilizing performance statistics and metrics for problem detection and selftuning purposes.
Server-Based Advisors A number of new advisors have been designed
around the manageability infrastructure to provide valuable
recommendations for specific problems. The Automatic Database
Diagnostic Monitor (ADDM), identifies bottlenecks in the database, and
additionally makes recommendations on the options that are available to fix
them.
Automatic Routine Administration tasks This is implemented via the
Scheduler. Certain routine or repetitive tasks can be delegated to the
Scheduler, in order to ensure the good shape of the Oracle database. Once
such routine task could be analyzing optimizer statistics.
Server-Generated Alerts In this regard, a DBA can configure alerts that
trigger during certain problem areas, such as out-of-space errors for
tablespaces. When a problem is detected, the Oracle database sends you an
alert message with possible remedial actions.
The Automatic Workload Repository
As mentioned earlier this new component of the Oracle database, installs with the Oracle
database and aims as acting as a central resource for performance tuning purposes.
Basically, it collects performance related statistics and derives performance metrics from
them to track a potential problem and self-tuning purposes. AWR is part of a
management-monitoring infrastructure.
The AWR is made up of two main parts:
1) An in-memory statistics collection facility used to collect base statistics. The
kind of statistics that are collected include object statistics, new time model
statistics that determine how much time was spent on activities, system and
session statistics, and recent session activity statistics. The statistics are accessible
via fixed views. The statistics in memory are transferred to a repository on disk
periodically by a background process known as MMON.
2) The workload repository

Is a collection of persistent system performance statistics. Snapshots of the

performance data in memory are generated once every hour and collected in the
workload repository. This interval can be modified if desired. These historical
statistics are stored permanently in the repository so that they can be accessed at a
later point in time. The statistics are accessible through data dictionary views. The
snapshots continue to remain even when the database is restarted or the instance
crashes. Snapshots are used for computing the rate of change of a statistic. Every
snapshot has a unique sequence number (SNAP_ID).They can be used to
determine patterns and trends or analyzes performance problems that occurred
earlier. Manual snapshots can be taken by the administrator in conjunction with
automatic snapshots by invoking a PL/SQL procedure.
The workload repository is created in the WR schema that resides in the
SYSAUX tablespace. The WR schema is owned by the user SYS.
The AWR stores among others base statistics, SQL statistics, metrics, ASH data
and the recommendation provided by advisors.

Active Session History

In order to view recent session activity, Oracle 10g provides a rolling buffer in memory.
This memory structure enables you to analyze system performance based on current
workload. The buffer holds session activity including activity of background sessions. A
sample is collected every second. When a session is active, the Oracle database looks for
events that the session is waiting for. If it finds it, it records the event in the ASH.
Inactive sessions are not sampled. This sampling facility is very efficient since it directly
accesses the internal database structures. The kind of information sampled includes:

SQL_ID: A new hash value use to uniquely identify SQL statements

SID
Client ID, Service ID
Program, Module, Action
Object, File, Block
Wait event number, actual wait time (if waiting).

ASH statistics are accessible through the V$ACTIVE_SESSION_HISTORY view. A

row exists for each active session per sample.
It is from the ASH that the information is transferred to the workload repository by the
MMON background process every 60 minutes and by the MMNL background process
whenever the buffer becomes full.
Base Statistics and Metrics

Raw data that is collected is known as base statistics. The number of physical reads in the
system since startup is a base statistic. Base statistics are collected automatically by
Oracle.
Metrics are derived from base statistics. The MMON background process periodically
updates metric data from the corresponding base statistics. Metrics track the rates of
change in the Oracle database. Each metric is associated with a metric name, and a
unique identifier known as the metric number. The average physical reads per second in
the database is an example of a metric. Metrics are used for self-tuning purposes. Metric
data can be accessed using views such as V$SYSMETRIC, V$SESSMETRIC and so on.
Since metrics are always created, determining the changed rate for a particular statistic
becomes very easy and is always readily available.
Statistics Levels
The amount of statistics captured can be controlled using the initialization parameter
STATISTICS_LEVEL. The three values that can be taken by the parameter are:
BASIC The computation of AWR statistics and metrics is turned off. All self-tuning
capabilities are turned off. You can manually capture AWR statistics using procedures in
the DBMS_WORKLOAD_REPOSITORY package.
TYPICAL This is the default and recommended value. A part of the statistics is
collected.
ALL All possible statistics are captured.
Creating Baselines
A baseline is a mechanism by which you can tag set of snapshot data pertaining to
important periods. Baselines are defined on pairs of snapshots. A baseline may be
provided with a user generated name or a system generated identifier. A baseline can be
created by executing the DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE
procedure.
Once a baseline is created it remains in the database until you drop them. Baselines are
usually created to set up baselines from some representative periods in the past.
The Structure of the Workload Repository Schema
The WR schema is made up of two types of tables, namely Metadata tables and Historical
statistical tables. Metadata tables are used to control, process and describe the WR tables.
These tables are used to determine when to perform snapshots and what to capture to
disk. The metadata tables are prefixed with WRM$.
Historical statistical tables store statistical data generated by the Oracle database based on
the current workload. The historical statistical tables are prefixed with WRH$.

Data dictionary views can be used to query the workload repository. Any view related to
the historical information in the Workload repository has the DBA_HIST_ prefix.
Workload Repository Capture and Purging Policy
The MMON background process is responsible for capturing in-memory statistics and
creating the snapshots every 60 minutes. However you can control the interval within
which the snapshots will be captured (INTERVAL) as well the duration of time that the
AWR information is retained in the workload repository (RETENTION). This is done by
using DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
packaged procedure.
The RETENTION parameter of the procedure indicates how long (in terms of days), the
AWR information must be retained. By default this is 7 days. Automatic purging of data
can be turned off by setting RETENTION to zero. However a minimum of one day of
history must be maintained.
The INTERVAL parameter of the procedure indicates how often the system will
automatically generate snapshots. The value of this parameter cannot be set to less than
10 minutes. The default is 60 minutes. If you set he INTERVAL to 0, automatic
capturing of snapshots is turned off.
Command Syntax:
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
RETENTION NUMBER, INTERVAL NUMBER);
In this example displayed below, the retention period is specified as 43200 minutes (30
days) and the interval between each snapshot is specified as 30 minutes. If NULL is
specified, the existing value is preserved..
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention => 43200,
interval => 30);
END;
/
You can configure RETENTION and INTERVAL parameters from the Enterprise
Manager (EM) console. Select Database -> Administration -> Workload Repository.
The DBMS_WORKLOAD_REPOSITORY Package
This PL/SQL package is used to manage the Workload Repository. It contains various
procedures that can be used to create, drop, and modify snapshots and baselines.

Procedure Name
CREATE_SNAPSHOT
DROP_SNAPSHOT_RANGE
CREATE_BASELINE
DROP_BASELINE
MODIFY_SNAPSHOT_SETTINGS

Description of Procedure
To manually create a snapshot
immediately
To drop a range of snapshots
To create a single baseline
To drop a single baseline
To modify a snapshot settings

For example
SQL> EXECUTE
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id
NUMBER, end_snap_id NUMBER, baseline_name VARCHAR2)
Snapshots that belong to baselines are retained until the baseline is dropped.
Database Usage Metrics
Using you the workload repository you can keep track of the Database Usage
Metrics. The MMON process tracks and records this information once a week.
The metrics are divided into the two categories.
The database feature usage statistics - you get information about Advanced
Replication, Oracle Streams, advanced queuing, Virtual Private database etc.
To retrieve this information you can query
DBA_FEATURE_USAGE_STATISTICS view or use the EM console. You
can access the Database Features Usage Statistics page by clicking the
Administration Tab on the Database Home page.
[SCREENSHOT ]
The High Water Mark value for certain database attributes such as the size of
the largest segment, maximum number of sessions, maximum number of tables
etc. To retrieve information you can query the
DBA_HIGH_WATER_MARK_STATISTICS view or use the EM console.
[SCREENSHOT]
AWR Reports
Summary reports on statistics stored in the workload repository can be generated by
using the SQL*Plus script awrrpt.sql. The report provides information about the
overall behavior of the system over a period of time. The reports an either in a text file or
HTML format.
The script should be run as a SYSDBA user. You will be prompted for the format (either
text or HTML), the number of days of snapshots to choose from, the begin snap_id and
end snap_id, and the name of the report file.

Running the awrrpt.sql Report

To generate a text report for a range of snapshot Ids, run the awrrpt.sql script at the
SQL prompt:
@$ORACLE_HOME/rdbms/admin/awrrpt.sql

First, you need to specify whether you want an HTML or a text report.
Enter value for report_type: text

Specify the number days for which you want to list snapshot Ids.
Enter value for num_days: 2

After the list displays, you are prompted for the beginning and ending snapshot Id for the
workload repository report.
Enter value for begin_snap: 150
Enter value for end_snap: 160

Next, accept the default report name or enter a report name. The default name is accepted
in the following example:
Enter value for report_name:
Using the report name awrrpt_1_150_160

The workload repository report is generated.

Workload Repository Views
Performance statistics and metrics are viewed using various views.
View Name
V$ACTIVE_SESSION_HISTORY
V$METRIC views

Description
Displays active database session activity. The data
in this view is sampled every second.
Provide metric data to track the performance of the
system.
$METRICNAME displays the mapping of the name of
metrics to their metric ID.
V$SERVICEMETRIC displays values of metrics for
the most recent 60-second interval. A history of
the last one hour will be kept in the system.

The in-memory metric values can be viewed

through the V$SYSMETRIC and
V$SYSMETRIC_HISTORY view. The views
provide system-level statistics.
V$WAITCLASSMETRIC displays metric values of
wait classes for the most recent 60-second interval.
DBA_HIST views

These views contain historical data stored in the

database. The groups of views includes:
DBA_HIST_ACTIVE_SESS_HISTORY displays the
history of the contents of the in-memory active
session history for recent system activity.
DBA_HIST_BASELINE displays information about
the baselines captured on the system
DBA_HIST_DATABASE_INSTANCE displays
information about the database environment
DBA_HIST_SNAPSHOT displays information on
snapshots in the system
DBA_HIST_SQL_PLAN displays the SQL execution
plans
DBA_HIST_WR_CONTROL displays the settings for
controlling AWR

MONITORING THE DATABASE

In the previous section we looked at the Automatic Workload Repository in depth. The
AWR component is crucial in effective performance tuning. In this section we present
two new methodologies that can be used in Oracle for effective monitoring and tuning of
an Oracle database. The two methodologies for monitoring the Oracle 10g database
include:
1. Proactive Monitoring
2. Reactive Monitoring.
Proactive Monitoring
Proactive monitoring is achieved using the two components:

Automatic Database Diagnostic Monitor (ADDM) This component ,

introduced in Oracle 10g, allows the DBA to identify bottlenecks within the
database. It provides a holistic tuning solution. Analysis is performed top down,
first identifying symptoms and then refining them to reach the root causes of
performance problems. The feature in addition to other manageability components
can be used to make recommendations to resolve bottlenecks.

Server Generated Alerts Using this feature the Oracle Server can
automatically detect certain undesirable alarming situations. The Oracle server
can be configured to respond to such situations and alert the DBA if the situation
does arise.

Reactive Monitoring
When using reactive monitoring the DBA can make use of the powerful new data sources
as well as performance-reporting capabilities of the Oracle 10g database to detect and
resolve bottlenecks. These new data sources are meant to capture important and relevant
information about the database's health. Bottlenecks in the database can be detected
manually using a drill-down method with a few mouse clicks.
THE AUTOMATIC DATABASE DIAGNOSTIC MONITOR
This new feature of Oracle 10g is used to proactively monitor the database. It is a serverbased performance expert. It ties up all sorts of relevant information in the database to
perform a detailed analysis and generate a list of recommendations. The types of
problems that ADDM considers include:

CPU bottlenecks - Is the system CPU bound by Oracle or some other application?
Undersized Memory Structures - Are the Oracle memory structures, such as the
SGA, PGA, and buffer cache, adequately sized?
I/O capacity issues - Is the I/O subsystem performing as expected?
High load SQL statements - Are there any SQL statements which are consuming
excessive system resources?
High load PL/SQL execution and compilation, as well as high load Java usage
RAC specific issues - What are the global cache hot blocks and objects; are there
any interconnect latency issues?
Sub-optimal use of Oracle by the application - Are there problems with poor
connection management, excessive parsing, or application level lock contention?
Database configuration issues - Is there evidence of incorrect sizing of log files,
archiving issues, excessive checkpoints, or sub-optimal parameter settings?
Concurrency issues - Are there buffer busy problems?
Hot objects and top SQL for various problem areas

Within the database statistics are gathered automatically every 60 minutes and stored in
the automatic workload repository (AWR), in the form of snapshots. The information
gathered is very precise. The ADDM is scheduled to run automatically by the MMON
background process. Every time a snapshot is taken, the ADDM is triggered to do an
analysis of the period corresponding to the last two snapshots.
The results generated by the analysis are stored in the AWR and is accessible through the
Enterprise Manager Console.

It is possible to invoke the ADDM from the EM console or manually. This option gives
you the ability to run an analysis across any two snapshots. By doing this, ADDM
provides tuning recommendations on the user-defined time period.
In earlier versions of Oracle, statistics gathering could be done using Statspack. However
this method lacks granularity of statistics. Another important feature is that ADDM
concentrates its analysis on issues that impact the system the most. Using ADDM, you
can easily identify top performance issues, such as Top SQL, I/O issues or Configuration
issues to name a few. This is primarily because a new methodology implemented in
ADDM.
The methodology used by ADDM is based on a wait and time statistic model. The model
is helpful in determining where time is spent within the database. The ADDM analysis
uses a top-down approach that focuses mainly on determining resource bottlenecks.
It uses a tree structure to represent all possible tuning issues. The root of the tree
represents the symptoms and going down to the leaves helps identify the root causes. The
ADDM walks down a tree using the time-based thresholds for each node. If the timebased threshold is not exceeded for a specific node, the ADDM prunes the corresponding
subtree. This way the ADDM concentrates only on problem areas. In the diagram below
the waits due to concurrency are an issue and non-issue subtrees such as the one
associated with RAC and IO Waits are pruned by the ADDM.

CONCURRENCY

BUFFER BUSY
PARSE LATCHES

SYSTEM WAIT
RAC WAITS

IO WAITS
Some of the performance issues that were not detected by Statspack are:
Excessive login and logoff
Memory under-sizing
Hot blocks and objects with SQL
RAC service issues
Locks and ITL contention
Checkpointing causes
PL/SQL; Java time

ADDM Output
The output generated by ADDM is best viewed using the Enterprise Manager Console.
After an analysis, the ADDM reports its findings along with the impact on the database.
The impact is measured in terms of time spent. The ADDM findings include symptoms
and root causes. A number or recommendations are also generated. Recommendations
generated by ADDM include:

Hardware changes - Adding CPUs or changing the I/O subsystem configuration

Database configuration - Changing initialization parameter settings
Schema changes - Hash partitioning a table or index, or using automatic segmentspace management (ASSM)
Application changes - Using the cache option for sequences or using bind
variables
Using other advisors - Running the SQL Tuning Advisor on high load SQL or
running the Segment Advisor on hot objects

To get a more detailed analysis/recommendation about a specific problem, a call could be

made to advisors, such as the segment or undo advisor. The ADDM output is stored in
the Automatic Workload Repository for future reference.
ADDM analysis results are represented as FINDINGS. An example of ADDM analysis
results is shown below:
FINDING 1: 31% impact (7798 seconds)
-----------------------------------SQL statements were not shared due to the usage of
literals. This resulted in
additional hard parses which were consuming significant
database time.
RECOMMENDATION 1:
Application Analysis, 31% benefit (7798 seconds)
ACTION: Investigate application logic for possible use of
bind variables
instead of literals. Alternatively, you may set the
parameter
"cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033
were found to be
using literals. Look in V$SQL for examples of such SQL
statements.

Details of the latest ADDM run can be obtained from the EM console. First select the
Database Home page -> Diagnostic Summary region -> Performance Findings Link
-> ADDM Findings Page. Specific areas of interest on this page are the View Report

Button. This gives you details of the performance analysis in the form of a text report. By
clicking on a specific issue, you are directed to a Performance Finding Details page.
This page also gives you recommendations to solve the corresponding issue. The Benefit
column gives you the maximum reduction in database elapse time if a recommendation is
implemented. ADDM may also suggest that you invoke a specific advisor for future
analysis of certain problem areas. For e.g., a faulty SQL statement can be fixed by
running the SQL Tuning Advisor.

Data Dictionary Views containing ADDM information

Data Dictionary View
DBA_ADVISOR_TASKS

Description
This view provides basic information
about existing tasks, such as the task Id,
task name, and when created.
DBA_ADVISOR_LOG
This view contains the current task
information, such as status, progress, error
messages, and execution times.
DBA_ADVISOR_RECOMMENDATIONS This view displays the results of completed
diagnostic tasks with recommendations for
the problems identified in each run.
DBA_ADVISOR_FINDINGS
This view displays all the findings and
symptoms that the diagnostic monitor
encountered along with the specific
recommendation.

Server-Generated Alerts
This feature is one of the principal components of the common manageability
infrastructure. Server-generated alerts are the capability of the Oracle database to
automatically detect alarming situations that may arise in the database. If an
alarming situation occurs, the DBA can be alerted with suggestions for remedial
actions.
An alert may be configured to identify some internally determined or user-defined
problem situation. An alert can be contain information about the object such as a
tablespace, a description of the problem, a brief advice on remedial action, the
name of an advisor that can provide more detailed recommendations and the status
or level of severity.
An alert may be queued in a predefined queue called ALERT_QUE that is owned
by the SYS user. The Enterprise Manager may be used to notify the DBA about
outstanding alerts. This may be done by means of email or pager. Server-generated
alerts are always displayed on the EM console.
There are two kinds of server-generated alerts:
Threshold
Non-threshold alerts.
Most of the alerts in the Oracle database are configured by setting two threshold
values, namely Warning threshold and Critical threshold. In the Oracle database
there are about 161 metrics for which you can define thresholds. Some of them
being User Commits Per Sec, CPU Time Per call, SQL service Response Time,
Physical Reads Per Second. A threshold alert is automatically cleared when the
DBA has responded to the alert.
A threshold alert is displayed in the DBA_OUTSTANDING_ALERTS view and
when cleared is sent to the DBA_ALERT_HISTORY view.
Server generated errors may also correspond to database events and are known as
non-threshold errors. These errors go directly to the history table. Examples of
some situations that result in alerts are:
Snapshot too old errors
Resumable session suspended
Recovery Area Low on Free space errors

Certain alerts are always enabled in the database and may be called out-of-the-box
alerts. To mention a few:
Tablespace usage
Snapshot too old
Resumable session suspended
Recovery Area Low on Free space errors
The SERVER-ALERT Usage
As a DBA if you want the Oracle database to notify you of alert situations, you
can use the model given below:
Using the EM console or PL/SQL procedure set the threshold limits for the
server alert metrics.
Identify a means to be notified, either by Email address, blackout period or
pager).
When the alert is generated, the alert displays in the EM console. EM sends
out a notification to the administrators.
You may use the suggestions provided to correct the alert.
The STATISTIC_LEVEL initialization parameter should be set to TYPICAL or
ALL for this functionality.
Setting Threshold Values Using Pl/Sql
The new DBMS_SERVER_ALERT package is used to set up thresholds on
metrics.
PROCEDURE NAME
SET_THRESHOLD
GET_THRESHOLD

Description
Used to define threshold settings for a
given metric
Used to read settings for a given metric

Consider the example below:

SQL> BEGIN
DBMS_SERVER_ALERT.set_threshold (
DBMS_SERVER_ALERT.tablespace_pct_full,
DBMS_SERVER_ALERT.operator_ge, 80,
DBMS_SERVER_ALERT.operator_ge, 95, 1, 1, ORCL,
DBMS_SERVER_ALERT.object_type_tablespace, USERS);
END;
You can use the NULL value to return to the database-wide default values.

The parameters are explained in the order they appear in the example:

The internal name of the metric (tablespace_pct_full)

The operator for comparing the actual value with the threshold value.
The warning threshold value (80)
The operator for comparing the actual value with the threshold value
The critical threshold value (95)
The observation period which defines for how long the actual behaviour of
the system must deviate from the threshold value before the alert is issued.
(1 hour).
The consecutive occurrences which define how many observation periods
the metric value should violate the threshold values before the alert is
issued (1 observation period)
The name of the instance for which the threshold is set (ORCL).
The type of metric (object_type_tablespace)
The name of the object for which the thresholds are set (USERS).

TUNING AND DIAGNOSTIC ADVISORS

Advisors are server components that provide relevant feedback about resource
utilization and performance with respect to specific database components.
The advisors use a common data source known as the Automatic workload
repository (AWR). There is a uniform interface and a seamless integration
between the different advisors available in Oracle 10g.
A list of available advisors is given below:
1. Automatic Database Diagnostic Monitor (ADDM)
This advisor monitors the overall health of the database. Uses a top-down
approach starting with symptoms and coming down to the root causes. It
also comes up with recommendations for fixing the problems. This advisor
is a central component to the advisory framework and can call upon other
advisors.
2. SQL Tuning Advisor
Provides SQL statement tuning advice.
3. SQL Access Advisor
Deals with schema issues and determines optimal ways to access data.

4. Memory Advisor
An advisor for system memory and optimizes the memory for an instance.
Used when automatic memory tuning is not enabled.
a. PGA Advisor Gives detailed advice and recommendations on work
areas along with optimal usage of PGA memory based on workload
characteristics.
b. SGA Advisor tunes and provides recommendations for the SGA,
depending on the access to various components in the SGA.
c. Buffer Cache Advisor Predicts cache hit rates for buffer access for
different sizes of the buffer cache.
d. Library Cache Advisor Predicts the cursor cache hit rate for he
library cache for different sizes.
5. Segment Advisor
Responsible for space issues regarding a database object. It can analyze
growth trends.
6. Undo Advisor Advices and recommends values for undo retention and
size of the undo tablespace based on current workload and workload
history.
An advisor may be invoked during the MMON performing its monitoring
actions or in a wizard in some of the DBA tools. Certain server alerts may also
recommend the DBA to view a certain Advisor for additional information.
Attributes of Advisors
Can operate in LIMITED and COMPREHENSIVE Modes: Limited
displays a relatively shallow analysis whereas a comprehensive mode
displays a more in-depth analysis.
Time limit: Specifies a maximum amount of time that the advisor can
run.
Interruptible: Specifies if an advisor provides partial results upon being
interrupted.
User Directive: Specifies whether the advisor can take user directives.
These could influence the recommendations provided.
Invoking the Advisors from EM Console

Select the Database Control Home Page -> Related Links -> Advisor Central
Link -> Advisor Central Page.
From the advisor central page you can list all the advisor tasks that were registered
in the workload repository.
The DBMS_ADVISOR Package
This is a package that is new to Oracle 10g. It consists of various procedures and
constants that are used by advisor modules. To execute any of the procedures you
must be granted the ADVISOR privilege.
PROCEDURE
CREATE_TASK
DELETE_TASK
EXECUTE_TASK
INTERRUPT_TASK
GET_TASK_REPORT
RESUME_TASK
UPDATE_TASK_ATTRIBUTES
SET_TASK_PARAMETER
MARK_RECOMMENDATION
GET_TASK_SCRIPT

DESCRIPTION
Creates a new task in the repository
Deletes a task from the repository
Initiates execution of the task
Suspends a task that is currently
executing
Text report about recommendations
Resumes a suspended task
Updates task attributes
Modifies a task parameter
Marks one or more recommendations as
accepted, rejected or ignored
Creates a script of all the
recommendations that are accepted.

Configuring a Typical Tuning Session Using PL/SQL

In a typical tuning session you would execute the following steps:
1. Create an advisor task. This is an executable data area in the advisor
repository that manages the task. You can do this by executing the
DBMS_ADVISOR.CREATE_TASK procedure.
2. Adjust the task parameters Parameters can be set to control the behavior
of the task. Parameters may include TARGET_OBJECTS,
TIME_WINDOW, TIME_LIMIT etc. The TIME_WINDOW specifies the
time period that the Advisor considers for its analysis. You can perform this
step by executing the DBMS_ADVISOR.SET_TASK_PARAMETER
packaged procedure.
3. Perform an analysis This step initiates the execution of the task. A task
may be interrupted and then resumed if necessary. The

DBMS_ADVISOR.EXECUTE_TASK packaged procedure may be

invoked during this step.
4. Review the results You can generate a report consisting of the various
recommendations Oracle provides. You can do this by executing the
DBMS_ADVISOR.CREATE_TASK_REPORT packaged procedure.
Given below is an example of manually invoking the ADDM advisor to analyze
the system between snapshots 60 and 66.
SQL> VARIABLE TNAME VARCHAR2(50)
DECLARE
TID
NUMBER;
BEGIN
DBMS_ADVISOR.CREATE_TASK('ADDM',TID,:TNAME);
DBMS_ADVISOR.SET_TASK_PARAMETER(:TNAME,'START_SNAP
SHOT',60);
DBMS_ADVISOR.SET_TASK_PARAMETER(:TNAME,'END_SNAPSHOT',66
);
DBMS_ADVISOR.EXECUTE_TASK(:TNAME);
END;
IMPORTANT DATA DICTIONARY VIEWS
DESCRIPTION
Properties of the advisors
Global information about the
task
Task current status
DBMS_ADVISOR_LOG
information
Task's parameters
DBMS_ADVISOR_PARAMETERS
Commands associated with
DBMS_ADVISOR_COMMANDS
actions
Objects referenced by tasks
DBMS_ADVISOR_OBJECTS
Findings discovered by the
DBMS_ADVISOR_FINDINGS
advisor
DBMS_ADVISOR_RECOMMENDATIONS Task's recommendations
Actions associated with
DBMS_ADVISOR_ACTIONS
recommendations
Rationales for the
DBMS_ADVISOR_RATIONALE
recommendations

VIEW NAME
DBMS_ADVISOR_DEFINITIONS
DBMS_ADVISOR_TASKS

DBA_ADVISOR_USAGE

Usage information for each

advisor

Gather optimizer statistics

In earlier versions of Oracle, the task of gathering statistics for various objects was the
database administrator's responsibility. This task is rather important since the Cost Based
Optimizer uses the statistics to make proper decisions on how data is to be retrieved.
Absent or stale statistics could result in in-efficient execution plans being generated. The
Automatic Optimizer Statistics Collection feature automates this task and relieves the
DBA of this task. The feature thereby greatly reduces the likelihood of having poorly
written SQL statement and enhances SQL execution performance by providing optimal
input to the Cost Based Optimizer.
Guidelines
To ensure that statistics will be gathered, you would need to set the parameter
STATISTICS_LEVEL to either TYPICAL or ALL. When this is done, a job is
started at instance startup to automatically collect statistics.

If the STATISTICS_LEVEL parameter is set to BASIC, then statistics will be

gathered only for certain objects, and all objects that have stale statistics will be
skipped.

In Oracle 10g, there may be certain tables or schemas that you don't want to
subject to the automatic statistics gathering feature. In this case you can lock them
using a LOCK_TABLE_STATS or LOCK_SCHEMA_STATS procedure of the
DBMS_STATS package. Once you have locked the statistics on a table, all the
dependent statistics such as tables statistics, column statistics, histograms and
dependent index statistics are also locked.
SQL> EXECUTE
DBMS_STATS.LOCK_TABLE_STATS('schema','tablename');
SQL> EXECUTE DBMS_STATS.LOCK_SCHEMA_STATS('schema');

To unlock the statistics on a specified table or schema you can use the
UNLOCK_TABLE_STATS or UNLOCK_SCHEMA_STATS procedure of the
DBMS_STATS package.

To determine the lock status of statistics you can query STATTYPE_LOCKED

column in {USER|ALL|DBA}_TAB_STATISTICS view.

You can however keep in mind that it is possible to overwrite statistics even if
they are locked by setting the value of the FORCE argument to TRUE when using
the DELETE_*_STATS, IMPORT_*_STATS, SET_*_STATS procedures of the
DBMS_STATS package.

To display the start and end times of all DBMS_STATS operations you can query
the DBA_OPTSTAT_OPERATIONS data dictionary view. The information in

this view is purged by default after 31 days. You can modify this retention period
value if desired.

If current statistics are resulting in a sub-optimal execution plan it is possible to

revert back to previously gathered statistics. This is possible only if the statistics
were gathered automatically and not by a DBA issuing an ANALYZE command.
o The procedure RESTORE_TABLE_STATS can be used to restore
statistics of a tables as of a specified timestamp.
o To restore statistics of all tables of a schema as of a specified timestamp
you can use the RESTORE_SCHEMA_STATS procedure.
o To restore the statistics of all the tables of the database as of a specified
timestamp you can use the RESTORE_DATABASE_STATS procedure.
o To restore statistics of all fixed tables as of a specified timestamp you can
use the RESTORE_FIXED_OBJECTS_STATS procedure. To do the
action you need to have either the SYSDBA role or the ANALYZE ANY
DICTIONARY system privilege.
o To restore statistics on all dictionary tables as of a specified timestamp
you can use the RESTORE_DICTIONARY_STATS procedure. To do the
action you need to have either the SYSDBA role or the ANALYZE ANY
DICTIONARY system privilege.
o To restore system statistics as of a specified timestamp you can use the
RESTORE_SYSTEM_STATS procedure.

In Oracle 10g, index statistics collection occurs by default during Index creation
and rebuilding unless the statistics are locked. The COMPUTE STATISTICS
clause of the CREATE INDEX and ALTER INDEX commands are now obsolete.

GATHER_STATS_JOB
Optimizer statistics are automatically gathered using the job GATHER_STATS_JOB.
This job gathers statistics on all objects in the database which have missing or stale
statistics.
The 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 10P.M to 6 A.M and all day
on weekends. The GATHER_STATS_JOB continues until it finishes, even if it
exceeds the allocated time for the maintenance window. This behavior can be
changed.
The GATHER_STATS_JOB job gathers optimizer statistics by invoking the
DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure.
You can verify that the job exists by querying DBA_SCHEDULER_JOBS view.

SQL> SELECT * FROM DBA_SCHEDULER_JOBS

WHERE JOB_NAME='GATHER_STATS_JOB';
If you want to disable automatic statistics gathering, the most direct approach is to
invoke the DISABLE procedure of DBMS_SCHEDULER package.
BEGIN
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
/