Sizing servers for Oracle Products

[Andrew Moody_1]

I'm looking at putting forward some suggestions to update our current hardware and wanted opinions.

Is it worth getting involved with the HP sales guy and his Oracle sizing spread sheet or as we already have servers in place that I know work, would you just upgrade based on the existing specifications.

My gut feeling is to follow both paths and then try and find some common ground from which to make recommendations/decisions, but I'd be interested in your thoughts and experience.

[Yogeeraj_1]

hi Andrew,

Depending on how much you know your own system, you may choose either path.

If you are experience enough, you should be your own judge. There is also the Product types that should be considered.

For example, for your database part, it would be talking more about disk space growth

when it comes to the Application server products, depending on the utilisation level, you would think about more CPU.

If you have your measureware reports, this can also guide you on the daily DISK/CPU/MEMORY utilisation.. and act upon it accordingly.

just some quick thoughts...

am sure you will get lots of other replies too

good luck!

kind regards
yogeeraj

[Peter Godron]

Andrew,
if you already have servers that do the job, I would use them as a baseline, unless mainteneance costs/future growth prevents it.

Gather some performance stats on your servers and estimate allowable growth. Then cover yourself by getting a manager to look at the figures and authorise your plan.

[Andrew Moody_1]

Thanks Yogeeraj

For all the servers internal storage really isn't an issue as we use EVA's for most of our storage.

[Andrew Moody_1]

Cheers Peter, that's my gut feeling at the moment, however I'm aware that our account managers with Oracle and HP may have another line into us that I want to have neutralised before they show up.

I've got N class and L class servers with 4 PA-8700 processors that to me seem massively overspecced for what they do. I don't see why a job being done by 4 PA-8700 processors and 8-12GB Ram can't be done equally as well by a 3440 with 2 or 3 PA-8900 processors with similar RAM. That would then allow me to release older N and L class machines to upgrade the development environment so I keep all my users happy at minimum cost.

But as I've been doing this barely 6 months I wanted a non-vested interest peer review of my idea's before I argue my case to various vested interest and budget managers.

[Vipulinux]

Hi
Check this interesting discussion:
http://groups.google.com/group/comp.databases.oracle.server/browse_thread/thread/6b30ced33bb24168/996f9393ed8532de?lnk=st&q=Hardware+sizing+HP+UX+for+oracle&rnum=2&hl=en#996f9393ed8532de

Cheers

[Jeff Schussele]

Hi Andrew,

I've always found Oracle to be much more I/O intensive than CPU.
Therefore you should also take a long, hard look at upgrading I/O more than CPU.
A 3440 would be plenty if Ns & Ls are doing it now. But spend plenty of time at looking at pure I/O speed - like more paths or moving to 2GB fibre speeds. So if you think you'll want more HBA paths to the SAN keep in mind the PCI slot limitations of the rp3440 - you may want to consider an rp 4440 solely for it's higher PCI slot count.
Also, if you're not Gig-E now & have a high client count - then move to Gig-E, while you have the chance.
Memory requirements won't change so just match them with current usages.

My 2 cents,
Jeff

[renarios]

Hi Andrew,

I just upgraded the production servers from Oracle 8i (8.1.7.4) to 9i (9.2.0.7) and had to upgrade our internal memory. Oracle 9i consumes more memory to perform the same.
With Oracle 10g I had the same issues on the preproduction systems. At our site, CPU power was not the issue. Increasing the internal memory helped us out.

Cheers,

Renariso

[Andrew Moody_1]

Jeff, we are running dual 2GB fiber to SAN and 1000Mbps ethernet so we are ok there I think. I could always get Dual Hba's to take account of the PCI card count, but you've hit on the one aspect that I can see so far of justifying the larger form factor machines, PCI slot count.

Renarios - Oracle products current running 11.5.8 moving to 11.5.10 currently. I've no idea how this dovetails with your experience as I'm no DBA.....

[Raju Joseph (PDI)]

When you move from 11.5.8 to 11.5.10, make provision for at least 15% increase in internal memory and swap space.
Oracle 8i vs 9i vs 10g, it takes a significant amount of memory unless you trim down the install to the very minimum needed features.
--Raju

[Jeff Schussele]

I hear you there Andrew.
This is one of the nits I have to pick with these new "slim" servers.
For crying out loud - two, TWO!!, slots are not enough for *any* server - like a 3410. Sheesh - I've had more expandibilty in laptops I've used - WHY should a server be that handicapped?!?!?!
Then you get into the issue of just what kind of "ropes" you feed these slots with. EX: slots 7/8 have 1GB bandwidth on the 4440 & the others go from 512MB down to 256MB.
So one *must* be very dilligent in how they populate these slots.

OK - off my soapbox,
Jeff

[Andrew Moody_1]

Quite Jeff

After all, two pci slots, so you add a single hba card and another 1000Mbps ethernet card and it's full.

But then they've got to lever us to buy the bigger form factor servers somehow eh?

Thanks guys btw for all your suggestions so far, and if anyone has any more information I'd be glad to glean it. After all, as I said further up the list, I've been at this only a matter of months.

Cheers

[TwoProc]

Andrew, keep this in mind while sizing...

Four PA-8700 procs are actually four whole and separate procs. Let's say they are 750Mhz.

2 PA-8800's or 8900's whole be one dual core chip running at 1Ghz. The problem is that these two chips are one core, and are sharing cache. Even HP will tell you that the benchmark for this dual-core chip is only 50% more than a single chip(PA-8800s anyway). This would effectively give you 1.5Ghz of proc power.

This means that you now have basically the SAME total horsepower as two 750 Mhz PA-7500's !

While I've found that this is not quite a true statement (as I have both), it's probably closer than you would be comfortable with.

However, if you're running 440 Mhz or 550Mhz chips (as my older Ls and Ns do), then the upgrade as per your discussion would do you a world of good.

Keep in mind that you mentioned having "2 or 3" procs - dual core chips come in sets of two naturally, and 3 isn't doable.

So, let's say you scale down to 2 procs from four. While you may have the same total HP in Ghz (and probably more than), you will unfortunately have less divisibility for tasks. That means that only two very intensive (and probably not well tuned) tasks can put your server at 100%, leaving poor response for everything else. On your old configuration, you'd only be at 50% at this point. As a case in point, you ever notice that a two proc server *seems* to run about four times faster than than a one proc? It's because on a one proc, ANY meaningfully sized single process and can and will push the server to 100%. So, in your case, it would be two processes as the 100% mark, and after that it's welcome to "time slice and wait" city.

[Andrew Moody_1]

Thanks John, some things worth mulling over and factoring in.

L-class and N-class generally have 4x 750Mhz PA8700
one N-class has 3x 875Mhz PA8700

No machine has more than 12Gb of RAM

We have N-class machines running as oracle apps servers which I want to replace with smaller (rp3440) machines but as powerful machines. Then redeploy the bigger older machines as database servers for the development environment. I figure I can upgrade both production and development this way for less than it would take to put in a an all new development environment.


That's my current train of thought...

[Mark Greene_1]

From my limited experience, the Oracle sizing tools are highly dependant on the accuracy of the data: the number of users, the type of data use (update vs report only), and the overall growth-rate of the database (not just the size). Changing one or more of these numbers one order of magnatude up or down can make a big difference.

Also, 9i and 10g take progressively more memory, which is driven in part by the java requirements. If you have a webserver requirement with any sort of middleware to drive the app, you're memory requirements will be even greater.

mark

[A. Clay Stephenson]

Since you are planning on using your older boxes in the development environment, let me make a whackball suggestion. Intentionally cripple the old boxes even more. Remove some of the processor's and reduce the memory? Why? Because if the code runs well enough on the intentionally crippled boxes in test/development, it stands a much greater probability of scaling up well in the production environment. I can't tell you the number of times that I have seen code fly in test/development and die like a dog when deployed in production. Algorithms that run well on a dog generally will then run well on a newer, faster box.

[Andrew Moody_1]

Thanks Mark.

Clay, my only problem with that would be judging the amount by which to handicap the older boxes.

I was thinking I could harvest a little of the old internal hardware to scale up the production database server, but to do that I'd need to purchase more Core i/o, cell board etc which would start to make it exspensive again.

It's all good stuff though guys, every response adds to the knowledge from which eventually I'm going to have to make a decision.

[A. Clay Stephenson]

Surprisingly the answer as to how much to "handicap" (I suppose in the interest of political correctness that we should say "physically challenge".) a development box is more rather than less. Our developers run on an old K-box -- intentionally; and yes, they did howl initially. I heard things like "Compiles take too long; I can't meet deadlines." Unfortunately (for them), I had done enough development over the years to know that compile/link times are perhaps 1% (and that is an extremely liberal estimate) of the total development time. After coming to understand my reasons, everyone came on board with the "dog" approach and essentially we have no "scaling" problem when new code is moved to production. The fact that having your developers working on a "dog" annoys them is an added bonus.