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, [EMAIL PROTECTED] wrote:
See the "Ratio Modeling" paper at Orapub.com
It is a quick and dirty method for capacity planning.
[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/21/2004 01:34 AM Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> 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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>:
> >
> > > 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: '[EMAIL PROTECTED]'
> > >
> > >
> > >
> > > 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-----
> > > [EMAIL PROTECTED]
> > > 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
> >
> > [EMAIL PROTECTED]
> >
> > -------------------------------------------------
> > Everyone should have http://www.freedom2surf.net/
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author:
> > INET: [EMAIL PROTECTED]
> >
> > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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
[EMAIL PROTECTED]
------------------------------------------------- Everyone should have http://www.freedom2surf.net/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
