Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Projecting resource requirements

Re: Projecting resource requirements

From: Martic Zoran <>
Date: Wed, 9 Mar 2005 06:59:55 -0800 (PST)
Message-ID: <>

Hi David,

> I'm ok with disk consumption but cpu and memory
> seem harder to project.

Not sure why are you saying that. I found the most complex to find out I/O requirements. You should be aware that disk capacity sizing is not only about the "size" but about I/O throughput expressed in random I/O and MB/s whatever higher.

Also the overall system needs to be in the perfect balance to save the money or you can have something more then others. But the memory to I/O balance is very important. That means you cannot do sizing of memory without sizing of I/O. Less memory will usually cause more I/O.

> give me the list of questions/queries they will be
> asking and the frequency of each.

Exactly, you need to find the top SQL consumers, the frequency, the timeframe for executing them. You should size for the peak hour. It can be 10% of the daily volume but can be less or more.

Based on SQL's and db schema it is possible to predict how much CPU it is going to use.

Somebody said spreadsheets are usually no useful, but it is not about spreadsheets or manual process. It is about the logic behind, how are you calculating first CPU usage.
Either manual process or spreadsheet may be wrong.

After that you need to size the memory probably based on the proper data working set, where you need to predict what is that size on the knowledge how is app working and what is doing, mostly based on the top SQL consumers. Then you need to find out how much logging you are going to have per second, how much DBWR writes to predict the I/O throughput needed.

Of course choosing architecture that is extendable will give you some future growth.

I had the situations where the customer wanted us to size for the year 2007.

Do not forget the backlog processing. If the system can be down for some time, when you recover the system it needs to process the time that it did not.

We had the systems where we needed to process 3 days worth of data in 1 day. Whatever is higher: busy hour per normal processing or average hour for these 3 days you need to size the HW for it.

I have never seen such a complex tool that is providing so many input parameters to be set.


Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
Received on Wed Mar 09 2005 - 10:03:12 CST

Original text of this message