|
Statspack is a very nice tool, however if one
really wants to find problems lurking in a database even five minute intervals
can be too long. By finding problems I mean locating inefficiencies
proactively. As good as the first few chapters of "Database Tuning 101"
are, the book preaches a reactive and not a proactive tuning method. Both
are needed.
I have
reached the conclusion that some data such as that in V$SESSION_WAIT and
V$SQLTEXT should be collected each minute. I don't mean to collect
everything just the active sessions and those that have been idle for a minute
or less. It would be nice to collect session stats every minute as well,
but that becomes too expensive. I choose to collect the session
stats which best mirror what tkprof puts out.
Running statspack is not ideal for this. It will
record information which I do not need that fine-grained. I do however
need it for comparison purposes.
I
can better answer questions such as who is accessing the data, what
fields are being accessed, what is the query plan used, how
expensive is the access, etc. I can also better answer questions, such as,
"One of my overnight jobs ran very slowly, can you tell me
why?"
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Much
of this monitoring could be replaced by proper code
review.
Ian
MacGregor
Stanford Linear Accelerator Center
|
- Statspack Intervals Robertson Lee - lerobe
- Re: Statspack Intervals Anjo Kolk
- RE: Statspack Intervals Robertson Lee - lerobe
- RE: Statspack Intervals DENNIS WILLIAMS
- RE: Statspack Intervals Orr, Steve
- RE: Statspack Intervals MacGregor, Ian A.
- RE: Statspack Intervals Jesse, Rich
- RE: Statspack Intervals kkennedy
- RE: Statspack Intervals Robertson Lee - lerobe
- RE: Statspack Intervals Jared . Still
- Re: Statspack Intervals Yechiel Adar
- RE: Statspack Intervals MacGregor, Ian A.
- RE: Statspack Intervals MacGregor, Ian A.
- RE: Statspack Intervals Jesse, Rich
