Grokbase › Groups › Oracle › oracle-l › October 2002
FAQ
Ave !

I like to hear Your opinion about the most importat
issues, what should be monitored from the database (8.1.7, SUN) during
perfomance testing. The purpose in this case, is limit the
monitoring to concern only about 10 most important ones.

I have difficulties to make my mind to pick up the right ones, so
if You had to have made similar kind of decisions or have opinions,
please let me know.

TIA

Jorma

Name: Jorma Vuorio Phone: +358-9-7180 67759

Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: Jorma.Vuorio_at_nokia.com

Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).

Search Discussions

  • Mark J. Bobak at Oct 2, 2002 at 9:23 am ⇧
    Jorma,

    Performance tuning is a complex subject. There really isn't a list of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck, so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what. Determine
    the cause of the biggest bottleneck and minimize or eliminate it.

    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark
    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Mark J. Bobak
    INET: mark_at_bobak.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jorma.Vuorio_at_nokia.com at Oct 2, 2002 at 11:08 am ⇧
    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that

    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L

    Jorma,

    Performance tuning is a complex subject. There really isn't a list of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck, so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what. Determine
    the cause of the biggest bottleneck and minimize or eliminate it.

    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark
    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Mark J. Bobak
    INET: mark_at_bobak.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jorma.Vuorio_at_nokia.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Inka Bezdziecka at Oct 2, 2002 at 3:03 pm ⇧
    Well ...
    if you need short reports, look for:

    waits
    buffer cache hit ratio
    dictionary hit ratio
    library hit ratio
    latches
    parsing/execution ratio
    data file i/o
    shared pool memory distribution
    session contention
    session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L

    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that

    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L

    Jorma,

    Performance tuning is a complex subject. There really isn't a list of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck, so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what. Determine
    the cause of the biggest bottleneck and minimize or eliminate it.

    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark
    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Mark J. Bobak
    INET: mark_at_bobak.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jorma.Vuorio_at_nokia.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Inka Bezdziecka
    INET: IBezdziecka_at_cupe.ca

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Greg Moore at Oct 2, 2002 at 9:18 pm ⇧
    The ten most important performance items to monitor are your ten most
    important business transactions. Period, end of story.

    If you want to provide an intelligent response, monitor how long they take
    and provide a weekly report, noting any changes.

    Ratios and wait events are just diagnostic tools -- when business
    transactions become slow you use them to find where the problem is.

    Anyone who asks you to monitor ten internal things, such as ratios or wait
    events, and no more than just ten because they only want the ten most
    important, is simply uneducated and unexperienced, since these things are of
    no importantance if the system is running fast enough for the users, and
    besides there are way more than ten important things like this. However,
    they may also be very smart, since a good manager may be wise to start by
    getting a handle on the ten most important things.

    Probably, you want to be taking statspack snapshots every hour just to have
    a baseline, so just DO THAT and give the statspack report to the manager
    once a week -- and make them happy by picking out ten items you consider
    important and running a yellow highlighter over them. Have a cover page
    that compares the current value of the ten items with the same items four
    weeks ago -- so you are monitoring them. That's fast, easy and smart, it
    makes your manager happy and you'll have your eye on the ball too.

    But don't forget that the most important thing to monitor is reality. Your
    coolest move is to have the manager pull the users into a meeting and get
    them to identify the ten business transactions that are most important to
    them. Find out if any are too slow. Find out if anything is too slow.
    Monitor that. Tune that.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Greg Moore
    INET: sqlgreg_at_pacbell.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Smith, Ron L. at Oct 2, 2002 at 9:53 pm ⇧
    Right On!

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 4:18 PM
    To: Multiple recipients of list ORACLE-L

    The ten most important performance items to monitor are your ten most
    important business transactions. Period, end of story.

    If you want to provide an intelligent response, monitor how long they take
    and provide a weekly report, noting any changes.

    Ratios and wait events are just diagnostic tools -- when business
    transactions become slow you use them to find where the problem is.

    Anyone who asks you to monitor ten internal things, such as ratios or wait
    events, and no more than just ten because they only want the ten most
    important, is simply uneducated and unexperienced, since these things are of
    no importantance if the system is running fast enough for the users, and
    besides there are way more than ten important things like this. However,
    they may also be very smart, since a good manager may be wise to start by
    getting a handle on the ten most important things.

    Probably, you want to be taking statspack snapshots every hour just to have
    a baseline, so just DO THAT and give the statspack report to the manager
    once a week -- and make them happy by picking out ten items you consider
    important and running a yellow highlighter over them. Have a cover page
    that compares the current value of the ten items with the same items four
    weeks ago -- so you are monitoring them. That's fast, easy and smart, it
    makes your manager happy and you'll have your eye on the ball too.

    But don't forget that the most important thing to monitor is reality. Your
    coolest move is to have the manager pull the users into a meeting and get
    them to identify the ten business transactions that are most important to
    them. Find out if any are too slow. Find out if anything is too slow.
    Monitor that. Tune that.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Greg Moore
    INET: sqlgreg_at_pacbell.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Smith, Ron L.
    INET: rlsmith_at_kmg.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Cary Millsap at Oct 2, 2002 at 11:48 pm ⇧
    Very well said.

    Cary Millsap
    Hotsos Enterprises, Ltd.
    http://www.hotsos.com

    Upcoming events:
    - Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11
    Honolulu
    - 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas
    - Jonathan Lewis' Optimising Oracle, Nov 19-21 Dallas

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 4:18 PM
    To: Multiple recipients of list ORACLE-L

    The ten most important performance items to monitor are your ten most
    important business transactions. Period, end of story.

    If you want to provide an intelligent response, monitor how long they
    take
    and provide a weekly report, noting any changes.

    Ratios and wait events are just diagnostic tools -- when business
    transactions become slow you use them to find where the problem is.

    Anyone who asks you to monitor ten internal things, such as ratios or
    wait
    events, and no more than just ten because they only want the ten most
    important, is simply uneducated and unexperienced, since these things
    are of
    no importantance if the system is running fast enough for the users, and
    besides there are way more than ten important things like this.
    However,
    they may also be very smart, since a good manager may be wise to start
    by
    getting a handle on the ten most important things.

    Probably, you want to be taking statspack snapshots every hour just to
    have
    a baseline, so just DO THAT and give the statspack report to the manager
    once a week -- and make them happy by picking out ten items you consider
    important and running a yellow highlighter over them. Have a cover page
    that compares the current value of the ten items with the same items
    four
    weeks ago -- so you are monitoring them. That's fast, easy and smart,
    it
    makes your manager happy and you'll have your eye on the ball too.

    But don't forget that the most important thing to monitor is reality.
    Your
    coolest move is to have the manager pull the users into a meeting and
    get
    them to identify the ten business transactions that are most important
    to
    them. Find out if any are too slow. Find out if anything is too slow.
    Monitor that. Tune that.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Greg Moore
    INET: sqlgreg_at_pacbell.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Cary Millsap
    INET: cary.millsap_at_hotsos.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jared.Still_at_radisys.com at Oct 3, 2002 at 12:58 am ⇧
    Buffer Cache Hit Ratio?

    What's that?

    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    cc:
    Subject: RE: Performance monitoring

    Well ...
    if you need short reports, look for:

    waits
    buffer cache hit ratio
    dictionary hit ratio
    library hit ratio
    latches
    parsing/execution ratio
    data file i/o
    shared pool memory distribution
    session contention
    session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L

    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that

    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L

    Jorma,

    Performance tuning is a complex subject. There really isn't a list of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck, so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what. Determine
    the cause of the biggest bottleneck and minimize or eliminate it.

    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark
    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Rachel Carmichael at Oct 3, 2002 at 1:38 am ⇧
    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four) that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck,
    so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com




    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jorma.Vuorio_at_nokia.com at Oct 3, 2002 at 6:43 am ⇧
    Hi Greg

    You can count on, that I have tried to tell them, what You
    wrote in two first lines. I have to got a hammer...:)

    -----Original Message-----
    Sent: 03 October, 2002 00:18
    To: Multiple recipients of list ORACLE-L

    The ten most important performance items to monitor are your ten most
    important business transactions. Period, end of story.

    If you want to provide an intelligent response, monitor how long they take
    and provide a weekly report, noting any changes.

    Ratios and wait events are just diagnostic tools -- when business
    transactions become slow you use them to find where the problem is.

    Anyone who asks you to monitor ten internal things, such as ratios or wait
    events, and no more than just ten because they only want the ten most
    important, is simply uneducated and unexperienced, since these things are of
    no importantance if the system is running fast enough for the users, and
    besides there are way more than ten important things like this. However,
    they may also be very smart, since a good manager may be wise to start by
    getting a handle on the ten most important things.

    Probably, you want to be taking statspack snapshots every hour just to have
    a baseline, so just DO THAT and give the statspack report to the manager
    once a week -- and make them happy by picking out ten items you consider
    important and running a yellow highlighter over them. Have a cover page
    that compares the current value of the ten items with the same items four
    weeks ago -- so you are monitoring them. That's fast, easy and smart, it
    makes your manager happy and you'll have your eye on the ball too.

    But don't forget that the most important thing to monitor is reality. Your
    coolest move is to have the manager pull the users into a meeting and get
    them to identify the ten business transactions that are most important to
    them. Find out if any are too slow. Find out if anything is too slow.
    Monitor that. Tune that.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Greg Moore
    INET: sqlgreg_at_pacbell.net

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jorma.Vuorio_at_nokia.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------

    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Grabowy, Chris at Oct 3, 2002 at 3:18 pm ⇧
    Sort of putting on my devil's advocate hat...

    "perhaps" the document is old and just hasn't been updated. A lot of the documentation that we have lying around is marked as 7.3, we just haven't had the time to update them, since were overwhelmed with real work, and can't hire additional DBAs.
    some Oracle sites still believe in the myths and ratio based tuning. It can be difficult to convince a client that their long practiced tuning methodology is "obsolete". So for your specific case, perhaps they have dealt with these types of clients in the past so they "tread lightly".

    It will be interesting to see how the hosting company responds to your explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L

    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four) that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck,
    so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com




    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Grabowy, Chris
    INET: cgrabowy_at_fcg.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Rachel Carmichael at Oct 3, 2002 at 5:44 pm ⇧
    they haven't been around as a company all that long so I doubt the doc
    is from 7.3

    as for the methodology, I've talked to their DBAs and they are forward
    thinking, which is why the doc suprised me

    "Grabowy, Chris" wrote:
    Sort of putting on my devil's advocate hat...

    - "perhaps" the document is old and just hasn't been updated. A lot
    of the documentation that we have lying around is marked as 7.3, we
    just haven't had the time to update them, since were overwhelmed with
    real work, and can't hire additional DBAs.
    - some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete". So for your specific
    case, perhaps they have dealt with these types of clients in the past
    so they "tread lightly".

    It will be interesting to see how the hosting company responds to
    your explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L


    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache
    hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four)
    that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    --- Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.
    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any
    systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the
    bottleneck,
    so
    that you can understand how to tune it. If may be latch
    contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have
    opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com


    === message truncated ===

    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Deshpande, Kirti at Oct 3, 2002 at 8:03 pm ⇧

    some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete".
    In such cases, Connor's wonderful script comes very handy;)
    http://www.oracledba.co.uk/tips/choose.htm
    I have used it to convince some old dogs....

    Kirti

    -----Original Message-----
    Sent: Thursday, October 03, 2002 12:44 PM
    To: Multiple recipients of list ORACLE-L

    they haven't been around as a company all that long so I doubt the doc
    is from 7.3

    as for the methodology, I've talked to their DBAs and they are forward
    thinking, which is why the doc suprised me

    "Grabowy, Chris" wrote:
    Sort of putting on my devil's advocate hat...

    - "perhaps" the document is old and just hasn't been updated. A lot
    of the documentation that we have lying around is marked as 7.3, we
    just haven't had the time to update them, since were overwhelmed with
    real work, and can't hire additional DBAs.
    - some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete". So for your specific
    case, perhaps they have dealt with these types of clients in the past
    so they "tread lightly".

    It will be interesting to see how the hosting company responds to
    your explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L


    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache
    hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four)
    that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    --- Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.
    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any
    systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the
    bottleneck,
    so
    that you can understand how to tune it. If may be latch
    contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have
    opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com


    === message truncated ===

    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Deshpande, Kirti
    INET: kirti.deshpande_at_verizon.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jared.Still_at_radisys.com at Oct 3, 2002 at 8:53 pm ⇧
    Of course, BCHR was already obsolete in 7.3.;)

    "Grabowy, Chris"
    Sent by: root_at_fatcity.com
    10/03/2002 08:18 AM
    Please respond to ORACLE-L



    To: Multiple recipients of list ORACLE-L
    cc:
    Subject: RE: Performance monitoring

    Sort of putting on my devil's advocate hat...

    "perhaps" the document is old and just hasn't been updated. A lot of
    the documentation that we have lying around is marked as 7.3, we just
    haven't had the time to update them, since were overwhelmed with real
    work, and can't hire additional DBAs.
    some Oracle sites still believe in the myths and ratio based tuning. It
    can be difficult to convince a client that their long practiced tuning
    methodology is "obsolete". So for your specific case, perhaps they have
    dealt with these types of clients in the past so they "tread lightly".

    It will be interesting to see how the hosting company responds to your
    explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L

    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four) that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.

    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the bottleneck,
    so
    that you can understand how to tune it. If may be latch contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com




    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Grabowy, Chris
    INET: cgrabowy_at_fcg.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Jared.Still_at_radisys.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Grabowy, Chris at Oct 3, 2002 at 8:53 pm ⇧
    Of course!!

    I just laughed when he published that script, and didn't think anything more of it. Now I can use it to "drive home" my point. Excellent.

    Thanks Kirti.

    -----Original Message-----
    Sent: Thursday, October 03, 2002 4:03 PM
    To: Multiple recipients of list ORACLE-L
    some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete".
    In such cases, Connor's wonderful script comes very handy;)
    http://www.oracledba.co.uk/tips/choose.htm
    I have used it to convince some old dogs....

    Kirti

    -----Original Message-----
    Sent: Thursday, October 03, 2002 12:44 PM
    To: Multiple recipients of list ORACLE-L

    they haven't been around as a company all that long so I doubt the doc
    is from 7.3

    as for the methodology, I've talked to their DBAs and they are forward
    thinking, which is why the doc suprised me

    "Grabowy, Chris" wrote:
    Sort of putting on my devil's advocate hat...

    - "perhaps" the document is old and just hasn't been updated. A lot
    of the documentation that we have lying around is marked as 7.3, we
    just haven't had the time to update them, since were overwhelmed with
    real work, and can't hire additional DBAs.
    - some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete". So for your specific
    case, perhaps they have dealt with these types of clients in the past
    so they "tread lightly".

    It will be interesting to see how the hosting company responds to
    your explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L


    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache
    hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four)
    that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    --- Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.
    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any
    systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the
    bottleneck,
    so
    that you can understand how to tune it. If may be latch
    contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have
    opinions,
    please let me know.

    TIA
    Jorma
    -----------------------------------------------------------------
    Name: Jorma Vuorio Phone: +358-9-7180 67759
    Company: Nokia Business Infrastucture Fax: +358-9-7180 67465
    Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND
    Internet: jorma.vuorio_at_nokia.com Mobile: +358-50-486 8043
    -----------------------------------------------------------------
    --
    --
    Mark J. Bobak
    Oracle DBA
    mark_at_bobak.net
    "It is not enough to have a good mind. The main thing is to use it
    well."
    -- Rene Descartes
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com


    === message truncated ===

    Do you Yahoo!?
    New DSL Internet Access from SBC & Yahoo!
    http://sbc.yahoo.com

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Rachel Carmichael
    INET: wisernet100_at_yahoo.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Deshpande, Kirti
    INET: kirti.deshpande_at_verizon.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Grabowy, Chris
    INET: cgrabowy_at_fcg.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Rajesh.Rao_at_jpmchase.com at Oct 3, 2002 at 9:49 pm ⇧
    BHR has taken quite a beating. I am sure the point everyone's trying to
    make is that a 99% BHR does not indicate a well tuned database, and a 50%
    BHR does not indicate a poorly peforming database. A low BHR does not mean
    I need to increase db_buffers as was believed and practiced earlier. Point
    well taken and understood. But, it "CAN" be an indicator that something out
    of the ordinary is happening in my well tuned database. I emphasize on
    "CAN". Why have the PIO's increased so suddenly? Say, if the BHR is
    consistently around 80, and suddenly, it drops to 70, or rises to 95, I
    want to know why? What you infer from the BHR is what counts. There would
    definitely be other ways of finding this out. Or are there?

    Regards
    Raj

    "Grabowy,
    Chris" To: Multiple recipients of list ORACLE-L
    Subject: RE: Performance monitoring
    Sent by:
    root_at_fatcity.
    com

    October 03,
    2002 04:53 PM
    Please
    respond to
    ORACLE-L

    Of course!!

    I just laughed when he published that script, and didn't think anything
    more of it. Now I can use it to "drive home" my point. Excellent.

    Thanks Kirti.

    -----Original Message-----
    Sent: Thursday, October 03, 2002 4:03 PM
    To: Multiple recipients of list ORACLE-L
    some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete".
    In such cases, Connor's wonderful script comes very handy;)
    http://www.oracledba.co.uk/tips/choose.htm
    I have used it to convince some old dogs....

    Kirti

    -----Original Message-----
    Sent: Thursday, October 03, 2002 12:44 PM
    To: Multiple recipients of list ORACLE-L

    they haven't been around as a company all that long so I doubt the doc
    is from 7.3

    as for the methodology, I've talked to their DBAs and they are forward
    thinking, which is why the doc suprised me

    "Grabowy, Chris" wrote:
    Sort of putting on my devil's advocate hat...

    - "perhaps" the document is old and just hasn't been updated. A lot
    of the documentation that we have lying around is marked as 7.3, we
    just haven't had the time to update them, since were overwhelmed with
    real work, and can't hire additional DBAs.
    - some Oracle sites still believe in the myths and ratio based
    tuning. It can be difficult to convince a client that their long
    practiced tuning methodology is "obsolete". So for your specific
    case, perhaps they have dealt with these types of clients in the past
    so they "tread lightly".

    It will be interesting to see how the hosting company responds to
    your explanations.

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 9:39 PM
    To: Multiple recipients of list ORACLE-L


    we're hiring a hosting company to manage and monitor our production
    apps... they handed me their spreadsheet of Oracle "things" to
    monitor... I finally found "wait events" on that list. Buffer cache
    hit
    ratios were high on the list and flagged as "critical"

    nuh uh, didn't have time to gently explain (with the two by four)
    that
    that was going to be unacceptable. But I will have loads of time
    tomorrow. What scares me is that this list was compiled by
    "experienced" DBAs.

    --- Jared.Still_at_radisys.com wrote:
    Buffer Cache Hit Ratio?

    What's that?






    "Inka Bezdziecka"
    Sent by: root_at_fatcity.com
    10/02/2002 08:03 AM
    Please respond to ORACLE-L


    To: Multiple recipients of list ORACLE-L

    cc:
    Subject: RE: Performance monitoring


    Well ...
    if you need short reports, look for:

    1. waits
    2. buffer cache hit ratio
    3. dictionary hit ratio
    4. library hit ratio
    5. latches
    6. parsing/execution ratio
    7. data file i/o
    8. shared pool memory distribution
    9. session contention
    10. session memory usage

    inka

    -----Original Message-----
    Sent: Wednesday, October 02, 2002 7:08 AM
    To: Multiple recipients of list ORACLE-L


    Thak's Mark

    I agreed, but they have gotten an idea to get only couple
    "most important" measurements from db, because they don't want
    to have a huge reports with all possible statistics. Very
    understandable, but as You wrote, there isn't any absolutely top ten.
    In any case, I have to do this (stupid) list, so give Your best shot,
    please.

    t.Jorma
    Ps. I heard, that Dave Ensor from BMC, has once presented that
    kind of list?

    -----Original Message-----
    Sent: 02 October, 2002 12:23
    To: Multiple recipients of list ORACLE-L


    Jorma,

    Performance tuning is a complex subject. There really isn't a list
    of
    10 things to watch for. Every system is different.

    I would (attempt to) summarize tuning by these five steps:

    1.) Have a capacity/performance target in mind. If you don't know
    where you're going, how will you know if you have gotten there?

    2.) Monitor your response times as load increases. Can you achieve
    your response time target at the specified load? If so, you're done,
    successful test, congratulations. If not, continue to next step.

    3.) Actively monitor what's going on in the database, while it's
    happening. It's always easier to see it in real time than just
    looking
    at random StatsPack snapshots taken at 5 or 10 or 15 minute
    intervals.
    (Not that I'm saying StatsPack shouldn't be collected. I'm just
    saying
    don't rely on StatsPack as your only source of info about the
    database.) The V$ Wait Interface is your friend. If you're not
    familiar with it, go to http://www.hotsos.com/ and get Mogens
    Norgaard's
    paper, Introducing the V$ Wait Interface. Where is the database
    spending it's time? What's the bottleneck? If you identify a few
    trouble sessions, you may want to dive deeper w/ some 10046 traces at
    level 8 on specific sessions. You almost certainly do NOT want to do
    this instance wide.

    4.) Once you have some indication as to what's going on in the
    database, you need to see how the system is doing overall. On most
    flavors of *nix, where I'm comfortable, sar (System Activity
    Reporter)
    is an excellent tool. Use it to determine if you have any
    systemwide
    CPU, memory, or I/O contention. (Other OSes almost certainly have
    similar utilities.)

    5.) Address the biggest bottleneck. This is where it can't be
    summarized in a simple step. You need to understand the
    bottleneck,
    so
    that you can understand how to tune it. If may be latch
    contention.
    Depending on the latch, it could be poorly tuned SQL, or lack of bind
    variables, or simple CPU capacity limits, or a whole host of things.
    I/O contention? Could be anything from poorly designed and/or
    configured RAID array to poorly tuned SQL, or who knows what.
    Determine
    the cause of the biggest bottleneck and minimize or eliminate it.


    There you have it, Mark's Simplified Performance Tuning, in five easy
    steps!;-)

    -Mark


    On Wed, 2002-10-02 at 02:08, Jorma.Vuorio_at_nokia.com wrote:
    Ave !

    I like to hear Your opinion about the most importat
    issues, what should be monitored from the database (8.1.7, SUN) during
    perfomance testing. The purpose in this case, is limit the
    monitoring to concern only about 10 most important ones.

    I have difficulties to make my mind to pick up the right ones, so
    if You had to have made similar kind of decisions or have
    opinions,
    please let me know.

    TIA
    Jorma
    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author:
    INET: Rajesh.Rao_at_jpmchase.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).
  • Jared Still at Oct 4, 2002 at 5:43 am ⇧

    On Thursday 03 October 2002 14:49, Rajesh.Rao_at_jpmchase.com wrote:

    "CAN". Why have the PIO's increased so suddenly? Say, if the BHR is
    consistently around 80, and suddenly, it drops to 70, or rises to 95, I
    want to know why? What you infer from the BHR is what counts. There would
    definitely be other ways of finding this out. Or are there?
    Track them with statspack.

    --
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    --
    Author: Jared Still
    INET: jkstill_at_cybcon.com

    Fat City Network Services -- 858-538-5051 http://www.fatcity.com
    San Diego, California -- Mailing list and web hosting services
    ---------------------------------------------------------------------
    To REMOVE yourself from this mailing list, send an E-Mail message
    to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
    the message BODY, include a line containing: UNSUB ORACLE-L
    (or the name of mailing list you want to be removed from). You may
    also send the HELP command for other information (like subscribing).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedOct 2, '02 at 6:08a
activeOct 4, '02 at 5:43a
posts17
users12
websiteoracle.com

12 users in discussion

Jorma.Vuorio_at_nokia.com: 3 posts Jared.Still_at_radisys.com: 2 posts Grabowy, Chris: 2 posts Rachel Carmichael: 2 posts Jared Still: 1 post Rajesh.Rao_at_jpmchase.com: 1 post Inka Bezdziecka: 1 post Greg Moore: 1 post Mark J. Bobak: 1 post Smith, Ron L.: 1 post Deshpande, Kirti: 1 post Cary Millsap: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase