Good points, Niall. I was probably more focused on the situation of
being presented with 200 snapshots taken 15 minutes apart, and then
being asked to find out the root cause of "the bad performance of the
system". I simply can't come up with a straight-forward method for doing
that - a method which I can tell other folks to follow to reach results
with guarantee.
I recently had lunch with a fine lady, who used to be an account manager
for IBM, selling mainframe systems to large companies. She isn't
technical, so I tried to explain about the excellent instrumentation of
the MVS and Oracle software. She then said: Well, when a large mainframe
customer decides to upgrade to some new CPU, the boys can tell the
customer exactly how much the response time will improve (or not) for
each application in the system.
Imagine being able to do that in our world. When I talk to mainframe
people they're really very surprised to hear about these problems. If
they have an application with performance problems they can find out
where the time is going and do something about it.
Imagine that we in the Wild West World of Unix, VMS, Windows and Linux
set our sights that high?
Mogens
Niall Litchfield wrote:
> Hi Mogens
>
>
>>There are so many things I need to learn about ex-wives,
>>databases and
>>snapshots of data. If we leave the two first topics for now, would
>>anybody care to tell me what kind of conclusive thoughts it's
>>possible
>>to derive from comparing two cumulative snapshots, except
>>that they're y
>>different and that most numbers will be higher in one and
>>lower in another?
>>
>>Iff - only iff - there's one job/session running while taking the
>>snapshot(s), then it might be possible to conclude something
>>about that
>>job/session. But otherwise?
>
>
> To play devils advocate for a small while, I think that while 2 such reports will be in general meaningless, a collection for a reasonable length of time (read > 42 snapshots) might have the following uses.
>
> 1. Abrupt changes in overall 'efficiency' stats can be a good indicator of change. A hangover from my support days is the tendency to ask first 'what has changed', unfortunately this gets interpreted as 'what did you change you good for nothing little....' and so tends to get answered with 'Nothing - it's the database'. If you can say well in february we got these figures but from march the 1st we got these the user might suddenly recall that oh yes we just loaded 2004/5 budgets and released the management reports based on them to end users.
> 2. SLAs tend to be driven by easily graphable and measurable stats (rather than for example performance requirements). A repository of these makes producing SLA data easier (of course getting yapppack in there might help).
> 3. Not all databases are instrumented the same way, so it might be 'useful' for management to receive the same information in the same way across all platforms that the shop runs.
> 4. It keeps the dba employed :)
>
> In other words one can use stats and graphs for more uses than just problem resolution.
>
> True story. In December I asked the manager responsible for what we have classed as our core business apps the following question.
>
> "Do we have a list of key business processes that our corporate systems run periodically (I'm thinking invoicing,new starters etc). What I'd like to do is make a list of these processes (if one doesn't already exist from <REMOVED> or upgrade checklists) and see if we can get some meaningful benchmarking and performance monitoring stats going for these systems."
>
> To date no such processes have been identified to me. To my knowledge no such list exists. They do have CPU utilisation and availability stats though and are happy with them for some reason. I don't think that this is an especially unusual position to be in. in fact we might be unusual in explicitly identifying core business applications.
>
>
>
> Niall Litchfield
> Oracle DBA
> Audit Commission
> +44 117 975 7805
>
>
>
> **********************************************************************
> This email contains information intended for
> the addressee only. It may be confidential
> and may be the subject of legal and/or
> professional privilege. Any dissemination,
> distribution, copyright or use of this
> communication without prior permission of
> the sender is strictly prohibited.
> **********************************************************************
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Mon Mar 15 2004 - 13:48:19 CST
