System sizing for Database server

[YLTan]

Does anyone have some guidelines for high availability production system sizing for database server (24x7) running oracle? e.g. cpu, mem, netwrk interface, clustering, server class, etc..etc...

[Sanjay Kumar Suri]

Hello Tan

"Oracle 24x7" by Venkat S. Devraj by Oracle Press is a good book.

Regards.

sks

[Sunil Sharma_1]

Hi,

System sizing depends on lot other parameters like,
1. Type of database
2. type of application
3. no. of users/ noo. of concurrent users
etc etc.

I think this thread may help you

http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1072778057593+28353475&threadId=92753

Sunil

[A. Clay Stephenson]

This is an almost impossible question to answer without more data. The most important datum is the efficiency of the application/SQL code. In almost any database environment, well-written code, even on a very modest box, will run circles around poorly-written code executed on an otherwise very fast box with rich resources. The point that I am trying to make is that long before you worry too much about hardware know your application and its requirements.

The other thing to consider is that Oracle needs lots of memory. That will almost certainly be your first bottleneck. I would say that for 64-bit Oracle, you will need at least 8GB --- and that is modest.

[Tim D Fulford]

Hi

As many of the above have aleeady pointed out the question you have asked avalances into more questions!

The way I would do what you are trying to do is
1 - Assess where you are now. Are you trying to replace an existing database server? If so Use MeasureWare or OpenView PerformanceAgent to see what is happening now. Also try and define what the system is doing & measure that. e.g. if it is placing orders, updating records etc find out how many orders are placed & updataed every 5 minutes (to match the measure ware reasukts). Then try some corrolation, if nothing else you should come up with.. the next computer needs to be 2.6 times more powerful than our current beast and twice as fast a disk subsystem etc. Combine this with tpc-c/tpc-h/tpc-r/tpc-r figures from http://www.tpc.org/ (which ever is more appropriate). This should allow you to gauge how big you system should be.
2 - If you do not have a current server with the appropriate software/database running then you will need to do more work. I assume if this is to be a 24x7 there is a tesbed server. Do the above on the testbed.
3 - If you are unable to do 1 or 2 then you are really guessing. If this is the case, speak to the guys with the dosh & explain that soem meaningful research will need to be done before putting $$ into a beast that may not fly. Failing that, ask some random guys on the internet wht you need... which kind of brings up back to here...

Regards

Tim

[SteveKirby]

I have gonethrough this porcess a few times, and getting good info is tough.

There are very few sizing worksheets available to the end customer for server/ database/ or hardware and each vendor is doing their own testing.

Some ideas:
1) Contact the application vendor (if this is an application database) and get the sizing docs. E.g. Oracle Applications has some sizing guidelines at the beginning of the Install manual you can use, IF you are using Oracle Applications.

2) Contact a hardware vendor or reseller and tell them you are looking at new hardware. They will often do a bunch of the work for you, but they usually oversize the system (in my experience).

3) Build a system on a cheap-o test/development server and test. This is harder, but you'll get a good feel for the application. Mostly I look at cpu %, RAM and iostat to see what the bottle necks are. Also ps to get the memory of the processes connected to the database.

4) When you talk about clustering, etc. I avoid clustering, unless the availablility requirements for minimla downtime are present.. and are cost justified. It is harder to find people to support clusters and the added complexity (to me) hasn't been worth the benefit.

5) Some of this is based on user expectation of response time. I can 'overload' a box if there is a lot of reporting going on and user-response time isn't as critical... I generally oversize a box if users start complaining, even if I think the box is fine.

6) For a Single datapoint. I have been running an N-Class server with 4GB RAM, 4 Proc (900MHx I think) on an FC60 Disk Array running Oracle Apps. We have 120 Concurrent Users And we are screaming. Prior to this we were running on 2 K480's each with a bout 60 users and 2GB RAM on Mod 30's and we were just about at the comfort zone for the performance... couldn't get much slower or users started screaming.