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).
Received on Tue Jan 20 2004 - 06:09:55 CST
