-----Original Message-----
From: Orr, Steve [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 12:55 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database trackingI concur with the recommendation to use STATSPACK but you might want to augment it. I take STATSPACK snapshots every 15 minutes and if there's a performance problem caused by a few bad queries I can usually isolate the offenders. But constant fined-grained STATSPACK snapshots can be a lot of overhead so you may want something more lightweight.
I've developed a DBA web app which queries V$SYSSTAT and V$SYSTEM_EVENT every minute. I assume regular queries on these tables do not impact system performance enough to worry about. I record the result sets from these queries outside of Oracle in a very light weight RRDTool "round robin database." (RRDTool is free, http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/.) From this I can produce 55 graphs on demand for 5 different time spans: daily; weekly; monthly; quarterly; and yearly. Of course damagement loves graphs/pictures. The storage needed for one plus year's worth of minute to minute V$SYSSTAT/V$SYSTEM_EVENT query data only comes to 3.2MB for each database instance being monitored. A cool thing to do is produce a graph with a visually obvious spike in some V$SYSTEM_EVENT wait statistic at say 3:15PM yesterday then correlate that graphic spike to a specific problem query as recorded in STATSPACK. It provides nice "smoking gun" incriminating evidence to be used for putting duhvelopers on trial.
Steve Orr
Bozeman, MT
Title: RE: Database tracking
I concur, I have used MRTG for this in the past, now I
have an Access database that I connect to via ODBC and get my graphs. They
are very handy for trending and analysis, If someone says I had a problem
yesterday around 3 pm I go look at the charts and I usually see something
out of whack. I can also look at my data over longer periods just like
MRTG and RRD, I basically copied the storage logic I saw in those tools so I get
a lot of history without the overhead of a ton of storage space. I opted
to keep my data in the database because I can literally install the whole system
in about 2 minutes on the average database. With MRTG and RRD it takes a
bit more to get things set up.
I have another system which stores 25 stats from the
from the tables mentioned below in a single row and takes a snapshot every
hour. 365 days * 24 rows per day is not really that much storage.
This allows me to quickly determine what is increasing (V$SYSSTAT) and what is
the impact (V$SYSTEM_EVENT). This can also be deployed in a couple of
minutes on the average database.
Finally I usually determine some other type of metric
to gather data on, for example, J.D. Edwards OneWorld performance will be most
impacted by batch jobs which are listed in the F986110 table. I have an
report which gets the # of jobs, total run time and average run time for grouped
by job. I can quickly see if particular jobs need to be tuned, are running
more often or just taking longer for some reason.
Most systems have some key components which impact
performance the most. I use of mix of the options above depending on
the requirements at hand. As far as alerting goes I pretty much send
everything to the Oracle alert log and I have a very nice script which allows me
to respond to various patterns in the file including running commands, sending
email/pages or just logging the event somewhere else.
- RE: Database tracking Post, Ethan
- Re: Database tracking Jared . Still
- RE: Database tracking Jared . Still
- RE: Database tracking Post, Ethan
- Re: Database tracking Arup Nanda
- RE: Database tracking Jamadagni, Rajendra
- RE: Database tracking STEVE OLLIG
- RE: Database tracking Charu Joshi
- RE: Database tracking Jamadagni, Rajendra
- RE: Database tracking Orr, Steve
- RE: Database tracking Post, Ethan
- RE: Database tracking Rajesh . Rao
- RE: Database tracking Leonard, George
- RE: Database tracking Orr, Steve
- Re: Database tracking Anjo Kolk