Thanks for the time answering my question guys... :-)
Tanel, I've just inherited the database that I'm handling right now and I was not part of the "real" capacity planning. I really lack experience on this part of the job and I would appreciate your thoughts on any good documentation regarding IOPS prediction and determining IO throughput requirements.
Thanks again guys and best regards,
Rhojel
|
| Kip.Bryant@Vishay.com
Sent by: ml-errors@fatcity.com
01/14/2004 01:54 AM
Please respond to ORACLE-L
|
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
cc: (bcc: Rhojel Echano/Manila/PH/SGS)
Subject: Re: Disk capacity planning |
Hi Rhojel,
You've had some responses that go beyond your forecasting question. I'll
go the simple-minded route here. Maybe there is some canned software out
there that will do it but it seems vendors stay away from forecasting future
growth. Maybe this is to avoid being held accountable for "faulty" results
(probably shouldn't trust my answer either...). Anyway, I was taught that
the first rule of forecasting is that the forecast will be wrong. This
doesn't mean you shouldn't forecast the growth of your database. It just
means that you need to follow your forecast on a regular basis and note
variances (ie: significant changes to growth rates) and ask questions. A
spike in growth can be a development boo-boo, new functionality, growth in
business, or something else.
A simple approach is to track (at least monthly...depending on your comfort
zone) the physical size of tablespaces and actual data and calculate net
changes in size between your forecasting periods (eg: Month). Summarize
this and calculate the average rate over time (eg: Year). Given the average
rate and the last rate, you can forecast your growth using both rates over
some horizon (1 year? 2 years?) and compare it to your available diskspace.
You should be able to identify when you'll run out...but don't assume this
will be correct. Also track significant events that may have driven growth.
And if there is a major difference between the average growth rate and the
last growth rate...it's analysis time.
There are fancier forecasting methods like "exponential smoothing" and so on
but the simple approach might get you started. But you need to keep testing
results to see if your situation has changed. The above would be a fairly
simple spreadsheet.
Kip Bryant
|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
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author:
INET: Kip.Bryant@Vishay.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@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: Rhojel_Echano_at_sgs.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).
Received on Tue Jan 13 2004 - 23:54:25 CST
