Chris,

Thanks.

When people do what you say, it's kind of like what would have happened
if NASA had used the following assumption throughout the Apollo project:
"Assume adequate quantities of breathable air..."

It would have made the planning phase much simpler, but it would have
been a touch more difficult on the users once the journey began. :)


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-----
[EMAIL PROTECTED]
Sent: Tuesday, January 20, 2004 3:19 AM
To: Multiple recipients of list ORACLE-L

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Cary Millsap
  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).

Reply via email to