FAQ
I'm looking for some *extra* info before I pull my hair out on this one, folks!
I'm managing and performing an 11g upgrade project and today, there was concern raised about me adding the dbms_resource_manager.calibrate_io run instead of gather_system_stats in a database build process. Over the last couple years reading here and there, I had come to believe that calibrate_IO was something of a replacement for gather_system_stats, but after research today, I'm not so sure about that!

I have the basics down and am quite comfortable with the technical specs of the new calibrate IO feature, but still feel there may very well be some great value to gathering system stats, (This is for a mart build, is run once with a sufficient work load produced on the system at the initial build time, never again for the life of the datamart...)

Can someone tell me why I would want to run one over the other, run both or where I'm missing some data here?
Thanks!

Kellyn Pot'Vin
Sr. Database Administrator and Developer
DBAKevlar.com

Search Discussions

  • CRISLER, JON A at Dec 3, 2011 at 12:22 am
    My understanding was that db_calibrate was very narrowly focused, and only collects metrics on disk i/o- and I did not think those metrics were kept to influence the DB behavior. In other words, sort of like the same function as Orion- a benchmark and nothing more. Even if it did save those metrics (and show me the docs where it says it does) gather_system_stats captures a lot more info, including CPU performance.

    To err on the safe side- run them both.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Kellyn Pot'vin
    Sent: Friday, December 02, 2011 7:15 PM
    To: oracle-l@freelists.org
    Subject: System Statistics and Calibrate IO

    I'm looking for some *extra* info before I pull my hair out on this one, folks!
    I'm managing and performing an 11g upgrade project and today, there was concern raised about me adding the dbms_resource_manager.calibrate_io run instead of gather_system_stats in a database build process. Over the last couple years reading here and there, I had come to believe that calibrate_IO was something of a replacement for gather_system_stats, but after research today, I'm not so sure about that!

    I have the basics down and am quite comfortable with the technical specs of the new calibrate IO feature, but still feel there may very well be some great value to gathering system stats, (This is for a mart build, is run once with a sufficient work load produced on the system at the initial build time, never again for the life of the datamart...)

    Can someone tell me why I would want to run one over the other, run both or where I'm missing some data here?
    Thanks!

    Kellyn Pot'Vin
    Sr. Database Administrator and Developer
    DBAKevlar.com
    --
    http://www.freelists.org/webpage/oracle-l


    --
    http://www.freelists.org/webpage/oracle-l
  • Greg Rahn at Dec 3, 2011 at 12:41 am
    I don't see a technical requirement to run either. I have yet to use
    system stats on any warehouse workload, and calibrate is only necessary for
    11.2.0.2 auto DOP, and then I would just set the values manually - the same
    way the Exadata best practice guide recommends.
    On Fri, Dec 2, 2011 at 4:15 PM, Kellyn Pot'vin wrote:

    I'm looking for some *extra* info before I pull my hair out on this one,
    folks!
    I'm managing and performing an 11g upgrade project and today, there was
    concern raised about me adding the dbms_resource_manager.calibrate_io run
    instead of gather_system_stats in a database build process. Over the last
    couple years reading here and there, I had come to believe that
    calibrate_IO was something of a replacement for gather_system_stats, but
    after research today, I'm not so sure about that!

    I have the basics down and am quite comfortable with the technical specs
    of the new calibrate IO feature, but still feel there may very well be some
    great value to gathering system stats, (This is for a mart build, is run
    once with a sufficient work load produced on the system at the initial
    build time, never again for the life of the datamart...)

    Can someone tell me why I would want to run one over the other, run both
    or where I'm missing some data here?

    --
    Regards,
    Greg Rahn | blog <http://bit.ly/u9N0i8> | twitter <http://bit.ly/v733dJ> |
    linkedin <http://linkd.in/gregrahn>


    --
    http://www.freelists.org/webpage/oracle-l
  • Subodh Deshpande at Dec 5, 2011 at 7:13 am
    yes, I think its upgrade project then all the parameters such memory, cpu,
    hardware are not going to change
    then what may change is only I/O..
    look at it from customer requirement..so if you at least have some minimum
    stat about previous I/O you can justify the performance after upgrade..and
    post actions taken if required..

    if you keep all the stat it may help you for your own learning
    experience..and if you are habitual with upgrades then perhaps may not be
    required to gather the stats..just depending upon the performance you can
    take the actions if any are required...

    thanks..subodh
    On 3 December 2011 06:10, Greg Rahn wrote:

    I don't see a technical requirement to run either. I have yet to use
    system stats on any warehouse workload, and calibrate is only necessary for
    11.2.0.2 auto DOP, and then I would just set the values manually - the same
    way the Exadata best practice guide recommends.
    On Fri, Dec 2, 2011 at 4:15 PM, Kellyn Pot'vin <kellyn.potvin@ymail.com
    wrote:
    I'm looking for some *extra* info before I pull my hair out on this one,
    folks!
    I'm managing and performing an 11g upgrade project and today, there was
    concern raised about me adding the dbms_resource_manager.calibrate_io run
    instead of gather_system_stats in a database build process. Over the last
    couple years reading here and there, I had come to believe that
    calibrate_IO was something of a replacement for gather_system_stats, but
    after research today, I'm not so sure about that!

    I have the basics down and am quite comfortable with the technical specs
    of the new calibrate IO feature, but still feel there may very well be some
    great value to gathering system stats, (This is for a mart build, is run
    once with a sufficient work load produced on the system at the initial
    build time, never again for the life of the datamart...)

    Can someone tell me why I would want to run one over the other, run both
    or where I'm missing some data here?

    --
    Regards,
    Greg Rahn | blog <http://bit.ly/u9N0i8> | twitter <
    http://bit.ly/v733dJ> |
    linkedin <http://linkd.in/gregrahn>


    --
    http://www.freelists.org/webpage/oracle-l


    --
    =============================================
    TRUTH WINS AT LAST, DO NOT FORGET TO SMILE TODAY
    =============================================


    --
    http://www.freelists.org/webpage/oracle-l
  • Kellyn Pot'vin at Dec 5, 2011 at 4:47 pm
    Apologies, I did not clearly state the following: this database mart build is started with a duplicate from another database that has DIFFERENT disk, memory and CPU.  We run the system stats once the duplicate is finished and then I would also like, as part of the 11g project to calibrate the IO at this step.   We are heavily dependent upon parallel processing here.  There really isn't much of anything that runs without parallel. Again- The hardware that the mart resides on is completely different than the target database system it is duplicated from...
    Thanks!

    Kellyn Pot'Vin
    Sr. Database Administrator and Developer
    DBAKevlar.com

    ________________________________
    From: Subodh Deshpande <deshpande.subodh@gmail.com>
    To: kellyn.potvin@ymail.com
    Cc: "oracle-l@freelists.org" <oracle-l@freelists.org>
    Sent: Monday, December 5, 2011 12:13 AM
    Subject: Re: System Statistics and Calibrate IO


    yes, I think its upgrade project then all the parameters such memory, cpu, hardware are not going to change
    then what may change is only I/O..

    look at it from customer requirement..so if you at least have some minimum stat about previous I/O you can justify the performance after upgrade..and post actions taken if required..

    if you keep all the stat it may help you for your own learning experience..and if you are habitual with upgrades then perhaps may not be required to gather the stats..just depending upon the performance you can take the actions if any are required...

    thanks..subodh


    On 3 December 2011 06:10, Greg Rahn wrote:

    I don't see a technical requirement to run either.  I have yet to use
    system stats on any warehouse workload, and calibrate is only necessary for
    11.2.0.2 auto DOP, and then I would just set the values manually - the same
    way the Exadata best practice guide recommends.
    On Fri, Dec 2, 2011 at 4:15 PM, Kellyn Pot'vin wrote:

    I'm looking for some *extra* info before I pull my hair out on this one,
    folks!
    I'm managing and performing an 11g upgrade project and today, there was
    concern raised about me adding the dbms_resource_manager.calibrate_io run
    instead of gather_system_stats in a database build process. Over the last
    couple years reading here and there, I had come to believe that
    calibrate_IO was something of a replacement for gather_system_stats, but
    after research today, I'm not so sure about that!

    I have the basics down and am quite comfortable with the technical specs
    of the new calibrate IO feature, but still feel there may very well be some
    great value to gathering system stats, (This is for a mart build, is run
    once with a sufficient work load produced on the system at the initial
    build time, never again for the life of the datamart...)

    Can someone tell me why I would want to run one over the other, run both
    or where I'm missing some data here?

    --
    Regards,
    Greg Rahn  |  blog <http://bit.ly/u9N0i8>  |  twitter <http://bit.ly/v733dJ>  |
    linkedin <http://linkd.in/gregrahn>


    --
    http://www.freelists.org/webpage/oracle-l


    --
    =============================================
    TRUTH WINS AT LAST, DO NOT FORGET TO SMILE TODAY
    =============================================
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedDec 3, '11 at 12:15a
activeDec 5, '11 at 4:47p
posts5
users4
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase