 |
|
Oracle Tips by Burleson |
Results of taking a
STATSPACK snapshot Frequency
After taking the initial snapshot, allow a
short period time to pass and then repeat the process. As soon as
there are at least two snapshots with no database downtime in
between, prepare a report on the database activity during that
interval. The length of the time interval is the subject of a great
deal of debate among DBAs. Ideally, the interval should be just
long enough so that the problem-related statistics will be
completely collected, but short enough to omit other statistics
which might obscure the relevant data. The goal is to avoid a
condition in which the spike in the statistics that indicate the
problem gets ‘averaged-out’ of the picture.
If STATSPACK is run via a cron job or from a
job scheduling package, it can easily be scheduled to run at a
frequency ranging from once every minute to once a month or anywhere
in between. The trick is to find the balance between too often and
not often enough. For most reactive tuning situations, snapshots
taken at intervals from five to fifteen minutes apart will provide a
reasonable amount of data to make a good start on tuning.
An important thing to remember is that even
if statistics are gathered too frequently with STATSPACK, reporting
can always be done on a larger time window. For example, if
snapshots are at five-minute intervals and there is a report that
takes 30 minutes to run, that report may or may not be slow during
any given five-minute period. After looking at the five-minute
windows, the DBA can decide to look at a 30-minute window and then
run a report that spans six individual five-minute windows. The
moral of the story is to err on the side of sampling too often
rather than not often enough.
The above book excerpt is from:
Oracle Wait Event Tuning
High Performance with Wait
Event Iinterface Analysis
ISBN 0-9745993-7-9
Stephen Andert
http://www.rampant-books.com/book_2004_2_wait_tuning.htm |
