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).
