RE: Scaledown hardware

Hmm. Well first of all .25 * 3600 is 900, not 1200.  

Maybe that shouldn't even be first, though. It has been quite a few years since I've done an actual "scale down service" under duress project. However, since the alternative was that the IT department of the client was to be told that DR was too expensive as an insurance policy, and hardware was still very very expensive, they were happy to pay my rates and I was happy to do the project.  

But the first thing you need to do is figure out how much batch load you have. After that you have to figure out whether it is possible to time shift any of the batch load when operating under duress. Now some of that batch activity *MAY* scale with interactive use. Figure out how much less it might be at a service level to support one quarter of the normal interactive throughput. The result is a SWAG of batch load that you cannot defer even when operating under duress. So you do the math when you get those numbers, but if you're at 70% with 30 active users it might easily be that 20% or 65% of the machine load has nothing to do with the interactive users.  

You probably also need to build a login control screen where you route folks to a "sorry, try again later" screen if they would be the nth+1 active user when you want to limit to n users.  

Then, when you have that in place and you can easily toggle the number from 900 to 3600 (or 4000 or whatever), you need to arrange for a test under normal conditions as a proof of concept. First you can establish just how low you can toggle the active interactive users until you cannot transact critical business. If the real answer is much higher than 25%, then you need to adjust for the much more significant problem of doing the real horsepower constrained test. Depending on the hardware and the OS you may be able to simply software partition your hardware to a functionally less capable state. Otherwise you may need to get a vendor loaner of the "25%" machine. But for most businesses needing a 12 CPU server in the first place, it would not be prudent to proceed without a real test under conditions where it is easy to revert to full horsepower.  

Lately though, after you figure out what the costs are for the above exercise, you just call it a wash and buy a matching machine for business continuation with the money you would have paid to make the test.  

Now you *may* be able to shrink both machines a little by running deferrable reports on the standby. That is only dependent on being able to identify the reports and load from those reports that is deferrable, so it costs no where near as much as a restricted horsepower and load test. You may also be able to shift things like extractions to a datawarehouse to the standby, as long as you remember to be sure that the upgrade of the business continuation site and the newly commissioned remote site will happen within the time you can operate without putting new data in the datawarehouse.  

Make sure you include some "C" level folks in this decision loop. When the CEO and CFO cast their attention on just what the operational logistics would be to operate with limited computer resources it may affect your budget.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of amonte
Sent: Friday, September 22, 2006 6:02 AM To: oracle-l_at_freelists.org
Subject: Scaledown hardware  

Hi

I am sizing a server for a database which will be used for disaster purposes. It should support 25% of production load.

Right now I have a production server with 12 CPU and 48Gb memory, in peak time 70% of CPU usage is observed (30 Active database users) and 40GB is used. This supports 3600 users roughly.

Is this that simple divide my actual HW by 4? i.e 3 CPU and 12 GB to support 1200 users? I think I can do that for memory but not that sure for CPU usage.

TIA Alex

--
http://www.freelists.org/webpage/oracle-l