FAQ
TeamQuest

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Mary Bahrami
Sent: Friday, March 05, 2004 4:48 PM
To: oracle-l_at_freelists.org
Subject: historical performance tool for oracle and/or sql server?

All,

I need to gather a snapshot of performance data for the OS and databases on a weekly basis, and maintain about a year's worth of weekly stats. I think the oem v9 'performance overview' provides the right data (cpu, memory, i/o, disk use, etc), but don't see how to schedule the data gathering and automate the delivery, it looks like a manual process, it that right? Any other tools I should look at? Databases range from oracle 7.3 to 9.2 and sql 2000.

Thanks much,
Mary

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

Search Discussions

  • Mary Bahrami at Mar 6, 2004 at 12:43 am
    All,

    I need to gather a snapshot of performance data for the OS and databases on a weekly basis, and maintain about a year's worth of weekly stats. I think the oem v9 'performance overview' provides the right data (cpu, memory, i/o, disk use, etc), but don't see how to schedule the data gathering and automate the delivery, it looks like a manual process, it that right? Any other tools I should look at? Databases range from oracle 7.3 to 9.2 and sql 2000.

    Thanks much,
    Mary

    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.
  • Mogens Nørgaard at Mar 7, 2004 at 6:59 pm
    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
    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?

    Best regards,

    Moans Longballs Nogood
    - former student of Economics at LSU (Baton Rough) and Copenhagen
    University.

    Mary Bahrami wrote:
    All,

    I need to gather a snapshot of performance data for the OS and databases on a weekly basis, and maintain about a year's worth of weekly stats. I think the oem v9 'performance overview' provides the right data (cpu, memory, i/o, disk use, etc), but don't see how to schedule the data gathering and automate the delivery, it looks like a manual process, it that right? Any other tools I should look at? Databases range from oracle 7.3 to 9.2 and sql 2000.

    Thanks much,
    Mary
    ----------------------------------------------------------------
    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
    -----------------------------------------------------------------
  • Mary Bahrami at Mar 6, 2004 at 1:27 am
    Thanks, that's exactly what I'm looking for.

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org

    Sent: Friday, March 05, 2004 2:50 PM
    To: oracle-l_at_freelists.org
    Subject: RE: historical performance tool for oracle and/or sql server?

    TeamQuest

    Dick Goulet
    Senior Oracle DBA
    Oracle Certified 8i DBA

    -----Original Message-----
    From: Mary Bahrami
    Sent: Friday, March 05, 2004 4:48 PM
    To: oracle-l_at_freelists.org
    Subject: historical performance tool for oracle and/or sql server?

    All,

    I need to gather a snapshot of performance data for the OS and databases on a weekly basis, and maintain about a year's worth of weekly stats. I think the oem v9 'performance overview' provides the right data (cpu, memory, i/o, disk use, etc), but don't see how to schedule the data gathering and automate the delivery, it looks like a manual process, it that right? Any other tools I should look at? Databases range from oracle 7.3 to 9.2 and sql 2000.

    Thanks much,
    Mary

    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
    -----------------------------------------------------------------
    ----------------------------------------------------------------
    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
  • Niall Litchfield at Mar 8, 2004 at 4:19 am
    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.

    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.
    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).
    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.
    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 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
    -----------------------------------------------------------------
  • Mogens Nørgaard at Mar 15, 2004 at 1:48 pm
    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 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
    -----------------------------------------------------------------
  • Mladen Gogala at Mar 15, 2004 at 2:07 pm

    On 03/15/2004 02:50:22 PM, Mogens Nørgaard wrote:

    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.
    We can lie, too. Telling someone that the application will work that much faster
    with that many times faster CPU is what DEC used to call "technical support on
    the marketing level". What the lady forgot to tell you is the infamous "spiral
    of death". It goes like this: you are told that the new CPU will speed up your
    apps by the factor X, so you buy the new CPU, and it fails. Then the IBM-er
    comes in and proclaims that the thing is not working because you need more memory.
    You buy more memory, and you still don't reach your goal. Gang from the big
    blue comes in and tells you that you need new channel controllers to be able
    to fully utilize all that wonderful RAM you bought. The channel controllers are
    bought and installed, and the effect is only the fraction of the expected one.
    Consultants tell you that your machine is hunky dory, but in order to fully
    utilize the new toy, you need the new release of the OS. After that, you
    are told that in order to fully utilize the new OS, you need a stronger CPU....
    It's nice to see that the fundamentals of the IBM world haven't changed much.
    What do you think that "IBM" stands for? "I've Been Mugged".

    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
    -----------------------------------------------------------------
  • Mogens Nørgaard at Mar 15, 2004 at 2:14 pm
    :-))).

    Mladen Gogala wrote:
    On 03/15/2004 02:50:22 PM, Mogens Nørgaard wrote:

    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.

    We can lie, too. Telling someone that the application will work that much faster
    with that many times faster CPU is what DEC used to call "technical support on
    the marketing level". What the lady forgot to tell you is the infamous "spiral
    of death". It goes like this: you are told that the new CPU will speed up your
    apps by the factor X, so you buy the new CPU, and it fails. Then the IBM-er
    comes in and proclaims that the thing is not working because you need more memory.
    You buy more memory, and you still don't reach your goal. Gang from the big
    blue comes in and tells you that you need new channel controllers to be able
    to fully utilize all that wonderful RAM you bought. The channel controllers are
    bought and installed, and the effect is only the fraction of the expected one.
    Consultants tell you that your machine is hunky dory, but in order to fully
    utilize the new toy, you need the new release of the OS. After that, you
    are told that in order to fully utilize the new OS, you need a stronger CPU....
    It's nice to see that the fundamentals of the IBM world haven't changed much.
    What do you think that "IBM" stands for? "I've Been Mugged".
    ----------------------------------------------------------------
    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
    -----------------------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedMar 6, '04 at 12:43a
activeMar 15, '04 at 2:14p
posts8
users5
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase