RE: FW: Disk capacity planning

I agree wholeheartedly. This is why I think that anyone who attempts to size a system with formulas alone (that is, without testing) is almost 100% certain to either overspend miserably or downright fail.

There are two things that are really important about testing. One is that it shows you how much hardware you'll need, because you can use real operational measurements to count things like IOps, instead of counting on smart people to infer operational statistics accurately while looking at paper. Just as importantly, it shows you how much wasted work your db/app/users are doing. This gives you the chance to eliminate that waste and go forward on a less expensive infrastructure than you might have imagined if you had studied it only on paper.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:

- Performance Diagnosis 101: 1/27 Atlanta
- SQL Optimization 101: 2/16 Dallas
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit www.hotsos.com for schedule details...

-----Original Message-----
Niall Litchfield
Sent: Tuesday, January 20, 2004 4:15 AM
To: Multiple recipients of list ORACLE-L

Hi

The bad news is that I don't believe that calculating IO/Sec *can* be done
for a *new* system. At least I'd like to see how it is done. I'm willing to
bet that any formula for doing it will include (x%) for 'overhead', which
actually means 'stuff I don't know about'. Of course if the *new* system is
a replacement for an old system with known IO requirements and the workload
is similar (or predictably different) then obviously a calculation/lower bound could be set.

(of course if one has the exact data set that you will use, and the IO required by each and every sql statement in use, and the exact number of clients and the exact machine and software configuration that will be used
for always then one can measure your IO requirement. I have never seen such
a situation.)

Actually however I think that this bad news is rather mitigated by the fact
that I don't believe that capacity can be calculated ahead of time for a *new* system either. It will entirely depend on the take up of the application and any changes to the design/usage post go-live.

I think that that leaves us in a relatively good position, namely that we
can estimate values for B,P etc based on our skill, judgement (and budget :(
), and that because none of the figures are *hard* figures it ought to be
possible to negotiate *sensible* disk purchases. They key is to take into
account all the demands on the system (as Cary says). I'm afraid that for
*new* systems though getting into formulae for *calculating* requirements is
likely to give false assurances. Time to brush up on negotiating skills (and
to find how how to effectivey bribe your sys admin and/or budget holders).

Yours unscientifically

Niall

> -----Original Message-----
> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On
> Behalf Of chris_at_thedunscombes.f2s.com
> Sent: 20 January 2004 09:19
> To: Multiple recipients of list ORACLE-L
> Subject: Re: FW: Disk capacity planning
>
>
> 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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Niall Litchfield
  INET: niall.litchfield_at_dial.pipex.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: 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).