| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: FW: Disk capacity planning
I found myself working with some "larger" databases in the 500-800 GB range that also spawn into multiple test databases.
I take a "df -k" or "bdf" and bring that into excel. Then I take a query on all "autoextend" and break that out by disk.
then I put that all together and tell what's left on disks.
This allows me to "quickly" match test to prod by using autoextend and then run this to find out just which disks are WAY over kill and which ones still have room left. I may find a disk that has been "promised" 40 gig, but only had 5 gig on it, but then find 2-5 volumes that have 5-30 gig on them, and I can then add datafiles where they are needed and pull the extra autoextend from the "full" disk.
The advantage is I'm usually quite okay while they are working and come back around and make it more "perfect" before they get me into trouble.
-- Michael Kline Midlothian, VA 23112 804-744-1545Received on Tue Jan 20 2004 - 13:14:26 CST
> 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-----
> chris_at_thedunscombes.f2s.com
> 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 <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: 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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: mkline1_at_comcast.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).
 |
 |