Database Reference
In-Depth Information
Managing Baselines
A
baseline
is a regular snapshot that is marked, by setting a flag, as a baseline. As a result, it's excluded from the
purging process. To manage that flag, the
statspack
package provides two sets of procedures and functions. The
first set, composed by the subroutines named
make_baseline
, is used to set the flag for one or several snapshots.
The second one, composed by the subroutines named
clear_baseline
, is used to unset the flag for one or several
snapshots. The
statspack
package provides both functions and procedures that implement the same functionality.
The only difference between them is that only the functions return the number of snapshots for which the flag has
been modified. To identify the snapshots to be altered, you can specify either a range of IDs or a period of time. For
example, the following call marks all snapshots between the two specified timestamps as baselines:
perfstat.statspack.make_baseline(
i_begin_date => to_date('2014-04-02 17:00:00','YYYY-MM-DD HH24:MI:SS'),
i_end_date => to_date('2014-04-02 17:59:59','YYYY-MM-DD HH24:MI:SS')
);
In a similar way, the following call unsets the flag for all snapshots between the two specified timestamps:
perfstat.statspack.clear_baseline(
i_begin_date => to_date('2014-04-02 00:00:00','YYYY-MM-DD HH24:MI:SS'),
i_end_date => to_date('2014-04-02 23:59:59','YYYY-MM-DD HH24:MI:SS')
);
Analysis With Diagnostics Pack
For an analysis with the Diagnostics Pack, I advise using the performance pages provided by Enterprise Manager
(it's irrelevant whether you use Database Control, Grid Control, or Cloud Control). As described in Chapter 4, the
Performance Home and Top Activity pages display either real-time or historical information. Since this chapter
focuses on analyzing performance problems that occurred in the past, it goes without saying that historical
information has to be used. In this mode, by default, information about the last week is available.
The analysis with historical information is basically the same as the one with real-time data. Hence, refer to
Chapter 4 for detailed information. Here are the most relevant differences:
•
With historical data, a 30-minute interval (instead of 5) is used to select the period for which
you want to display more details about the database load. (For more flexibility, if possible, you
should use ASH Analytics.)
•
Data is less detailed or even missing because not all real-time data is stored in AWR.
Nevertheless, you should be able to have access to enough information about the top
consumers.
•
You aren't able to search for a specific session. In fact, the Search Sessions item in the
Performance menu isn't available. Sessions can be accessed only through the Top Sessions table.
In addition to its integration inside Enterprise Manager, AWR provides a series of reports that can be used to
assess the load during a specific period of time. Here are the three most commonly used:
•
The AWR report summarizes the operations performed during a period of time specified as
input. It can be produced either through Enterprise Manager or by executing the
$ORACLE_
HOME/rdbms/admin/awrrpt.sql
script. Since this report is based on the Statspack report, take
a look at the next section for information about its interpretation.
