Sizing a new Server for SQL Server

[davidchardonnet]

Hello,

I want to set up a new MS SQL Server 2000 in my company's network, but I don't know how to size it.
What Processor(s) do I need, RAM size, Hard disk? Backup server...

Do you know what to do to find which machine which will fit our needs?

Thank you

David

 

[JayKusch]

Since you have not listed your needs, it is rather had to give specs. How many users will be on the system? How heavily will the system be used, based on possible number of transactions? Will it be used for OLAP or OLTP? Will other application reside on the server that are not database related?

rule of thumb ... the bigger ther better! Hope this get you started and please post some more guidlines for our forum gurus to chew on.

Thanks

J. Kusch

 

[davidchardonnet]

Well there will be about 10 databases in the server in the beginning.
The server will grow in power as new applications will come.

So now, I think we can have about 50 simultaneous users on the same SQL server, but after there will be 200 simultaneous users.

There will be no OLAP on it, and no OLTP (I don't know what is OLTP). And there won't be any other application than SQL server. I have no idea of the transactional traffic.

 

[pweegar]

With memory as cheap as it is, and HD prices as cheap as they are, I'd suggest going with as fast a proccessor as you can, stick as much memory in your server as it will take and as big a hard drive9s) as you can get. You will definetly want to think of a server with multiple proccessors, with a min. of 2, with 4 being better. The more memory the better, esp. as your db's grow and the number of users climb. As far as HD's go, you'll probably want to look at SCSI drives with a RAID controller (using RAID 5 for redundancy and security).

I'm struggling with a P3, 2 processors and 512 MB of Ram. Add to it, my RAID array has only 36GB of storage. My main DB is around 4GB. And can get painfully slow. We use SQL Server to store image indexes for our Optial Storage and Retrieval System. At times it's painfully slow, esp when we only have 10 lic. for the SQL server.

 

[johnherman]

A rule of thumb for converting flat data to relational structures with indexes is 3-4 times the flat size. Dimensional structures are 2-3 times bigger. So, multiply the number of records or number of records expected at the time of implementation by the size of each record in bytes. Then multiply by the rule of thumb factor. Do this for each file/table. Then add at least 20% for tempdb, flat file storage, logging, growth, etc.

Sometimes the grass is greener on the other side because there is more manure there - original.