When I worked for Oxford, there was a way to force the application to
either perform or die. The OLTP database was enforcing profiles and
there was limit of 1500 logical reads per call, because it was
estimated that our typical OLTP application never performs more
then that. If application was unable to achieve that performance, it
wasn't allowed to the production OLTP system. That way, the performance
could be guaranteed.
On 01/21/2004 01:19:26 PM, Jared.Still_at_radisys.com wrote:
> See the "Ratio Modeling" paper at Orapub.com
>
> It is a quick and dirty method for capacity planning.
>
>
>
>
>
>
> chris_at_thedunscombes.f2s.com
> Sent by: ml-errors_at_fatcity.com
> 01/21/2004 01:34 AM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> cc:
> Subject: Re: FW: Disk capacity planning
>
>
> Mladen,
>
> I agree you can measure how many IOs are being done and how many a
> disk
> sub-
> system, such as those provided by EMC, can perform and still give
> "good"
> performance. What I meant is that it is hard and some would say
> impossible
> to
> estimate how many IOs per sec a new application will do. A
> combination
> of
> paper
> calculations, testing, experience and looking at comparable systems
> will
> help
> to provide a good estimate.
>
> Cheers,
>
> Chris
>
>
> Quoting Mladen Gogala <mgogala_at_adelphia.net>:
>
> > Oh, but it is done, you only need to ask. EMC routinely measures
> how
>
> many
> > I/Os
> > per second can they perform and they even have tools to measure it.
> Speaking
> > of
> > monitoring I/O, there used to be an old OS, which is mostly dead
> today
> and it
> > used
> > to have command monitor io/item=queue which would show length of
> the
> I/O
> > queues
> > per device, which was extremely useful, because you could quickly
> find
> out
> > which
> > devices are "hot" and which are not.
> >
> >
> > On 2004.01.20 04:19, chris_at_thedunscombes.f2s.com wrote:
> > > Cary,
> > >
> > > Good answer. The problem is most people concentrate on bytes
> because
> it's
> > > relatively easy and everyone understands it. IOs per sec is much
> harder to
> >
> > > calculate for a new system and hence it's not normally done.
> > >
> > > Cheers,
> > >
> > > Chris Dunscombe
> > >
> > >
> > >
> > > Quoting Cary Millsap <cary.millsap_at_hotsos.com>:
> > >
> > > > I don't think this one made it through on my first attempt.
> > > >
> > > >
> > > >
> > > > Cary Millsap
> > > > Hotsos Enterprises, Ltd.
> > > > http://www.hotsos.com
> > > > Nullius in verba
> > > >
> > > > Upcoming events:
> > > > - Performance <http://www.hotsos.com/training/PD101.html>
> Diagnosis
> > > > 101: 1/27 Atlanta
> > > > - SQL Optimization 101: 2/16 Dallas
> > > > - Hotsos Symposium 2004
> <http://www.hotsos.com/events/symposium/2004>
> :
> > > > March 7-10 Dallas
> > > > - Visit www.hotsos.com for schedule details...
> > > >
> > > > -----Original Message-----
> > > > Sent: Tuesday, January 13, 2004 5:54 PM
> > > > To: 'ORACLE-L_at_fatcity.com'
> > > >
> > > >
> > > >
> > > > Counting bytes is far, far, FAR less important than counting
> > > > I/O-per-second (IOps) requirements and making sure that you
> have
>
> enough
> > > > total capacity to handle your system's peak I/O loads. Counting
> bytes is
> > > > important too, but what many people find is that the
> byte-counting
> > > > exercise will result in the sub-verdict of needing far fewer
> disk
> drives
> > > > than you'll really, truly need.
> > > >
> > > >
> > > >
> > > > The way I'd recommend structuring your project is to evaluate
> the
> > > > following:
> > > >
> > > >
> > > >
> > > > - How many bytes will you need to store your data? How
> many
> > > > disks is that? Call the answer B.
> > > >
> > > > - How many disks will you need to meet your IOps
> requirements?
> > > > Call the answer P.
> > > >
> > > > - How many disks will you need to meet your
> availability
> > > > requirements? Call the answer A.
> > > >
> > > > - (Consider other attributes as necessary, like
> perhaps
> I/O
> > > > throughput requirements.)
> > > >
> > > >
> > > >
> > > > Roughly speaking, the number of disks you'll need to buy is
> max(B,
> P, A,
> > > > .). It's more complicated than that because you'll need to
> segment
> your
> > > > total drive set into sensibly-sized arrays, you'll be able to
> buy
> some
> > > > disks now then some later, and so on, but this is the general
> gist.
> The
> > > > important thing is to have enough hardware to meet *all* of the
> > > > constraints your business will place upon your system.
> > > >
> > > >
> > > >
> > > > Cary Millsap
> > > > Hotsos Enterprises, Ltd.
> > > > http://www.hotsos.com
> > > > Nullius in verba
> > > >
> > > > Upcoming events:
> > > > - Performance <http://www.hotsos.com/training/PD101.html>
> Diagnosis
> > > > 101: 1/27 Atlanta
> > > > - SQL Optimization 101: 2/16 Dallas
> > > > - Hotsos Symposium 2004
> <http://www.hotsos.com/events/symposium/2004>
> :
> > > > March 7-10 Dallas
> > > > - Visit www.hotsos.com for schedule details...
> > > >
> > > > -----Original Message-----
> > > > Rhojel_Echano_at_sgs.com
> > > > Sent: Tuesday, January 13, 2004 12:29 AM
> > > > To: Multiple recipients of list ORACLE-L
> > > >
> > > >
> > > >
> > > >
> > > > Hi everyone!
> > > >
> > > > Can anybody point me to any good documentation regarding disk
> capacity
> > > > planning? Sharing your experience or approach will also give me
> so
> much
> > > > help. I'd like to know other people's approach on forecasting
> the
> growth
> > > > of their databases particularly on determining the (growth)
> rate
> of
> disk
> > > > space usage and on deciding when to add and how many disk to
> add
> on
> an
> > > > Oracle server.
> > > >
> > > > Thanks in advance.
> > > >
> > > > Best Regards,
> > > > Rhojel
> > > >
> > > >
> > >
> > >
> > > Chris Dunscombe
> > >
> > > chris_at_thedunscombes.f2s.com
> > >
> > > -------------------------------------------------
> > > Everyone should have http://www.freedom2surf.net/
> > > --
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > > --
> > > Author:
> > > INET: chris_at_thedunscombes.f2s.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).
> > >
> >
> > --
> > Mladen Gogala
> > Oracle DBA
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Mladen Gogala
> > INET: mgogala_at_adelphia.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).
> >
>
>
> Chris Dunscombe
>
> chris_at_thedunscombes.f2s.com
>
> -------------------------------------------------
> Everyone should have http://www.freedom2surf.net/
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author:
> INET: chris_at_thedunscombes.f2s.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.net
--
Author: Mladen Gogala
INET: mladen_at_wangtrading.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).
Received on Wed Jan 21 2004 - 12:54:30 CST
