Thanks for the detailes suggestions.
I just read the documentation from the Oracle Consulting Guy, I guess he has not been taught well enough at Oracle Corp because he actuallys says
"Quantify without running the process" (what the hechk!)
Or he has been taught by sales people :-P
The hardest thing in the *world* to do is estimate how much capacity a piece of Oracle application work will consume (sorry, Mogens, I meant * planet*). When I was at Oracle, I got these questions all the time: "40 GL users, 20 AP users, 6,000 vendors, …, the CEO has green eyes: what kind of system should we buy?"
The real proof of how impossible this can be comes when you can show that two identical companies with identical application software configured identically, with identical hardware, identical user counts, and even identical row counts can have two totally different performance characteristics. All it takes is one custom report. Or one user who runs 60 aged trial balance reports per day at one site instead of the 6 runs a day at the other site, to have a profound impact upon performance. Even some variable like the order in which a table's rows are inserted and deleted can mess up your on-paper capacity plan beyond recognition.
It's truly the Butterfly Effect. It's unstoppable.
What people do, then, is this: They overbuy their hardware by some "safe" factor like, say, five (Tom Kyte's famous observation). If you try to overbuy your hardware by 5X, then your performance won't stink too bad if you accidentally messed up and actually overbought by only 2X. If you really did overbuy by 5X, then—what the heck—you'll grow into that capacity someday, right? (One of my focal messages to the world is that you probably can't hit all of your business targets by *only* overbuying on hardware…)
What if your problem is that humans haven't invented a machine big enough to cover you 5X? Then you have to do something a lot more expensive. Like actually test. Which of course will require that you actually plan out what you're *really* going to want to do with your application. Which is expensive as heck. Or you convince yourself that you can save all this planning and expense by using an Oracle RAC configuration (the Easy Button™!), which of course is even *more* expensive, because it doesn't exonerate you from needing to do the planning and testing that you needed to do in the first place, plus now you have an even more extravagant and complex system to plan and manage.
There's no easy answer. You have to have some reasonable operational data before you can create a reasonable capacity plan. When you have *no* data whatsoever, then make sure that you start with hardware that will easily scale in the likely direction that your business will need it to scale. And then carefully manage—at least *measure—*the work that you let people do on your system.
Hotsos Enterprises, Ltd.
*Nullius in verba*
Hotsos Symposium 2007 / March 4–8 / Dallas
Visit www.hotsos.com for curriculum and schedule details... ------------------------------
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Dennis Williams *Sent:* Tuesday, June 06, 2006 11:30 AM *To:* ax.mount@xxxxxxxxx *Cc:* oracle-l@xxxxxxxxxxxxx *Subject:* Re: Batch process resource estimation?
I think this is a classic computer science puzzle. How to estimate the resources consumed by a program without executing it. Cary Millsap may even address this issue in his book.
When configuring a new site, often you are in the unenviable position of having to guesstimate the size of server to purchase and an early stage. This doesn't meant these are very reliable. The ERP vendors like Oracle Applications usually have developed some rules of thumb, for a payroll of X number of employees you need a machine of Y capacity. And usually there is a cushion so you err on the side of a slightly larger server than is needed.
Usually most of us develop a rough idea how many resources a process will consume with experience, but I think that is the best you'll do. Now, just watch someone respond and prove me wrong.