Hardware recommendation for MS SQL Server 2008 R2

J

JackTheKnife

Limp Gawd
Joined
Mar 27, 2006
Messages
272
I'm looking for any hardware recommendation for Microsoft SQL Server 2008 R2. Can be pre-build (Dell/HP) or something DYI. It will be development system with three databases (1st - 20 tables and 2nd - 50 tables and 3rd - 2 tables) and around 3000 new records each day overall.

Thanks for any suggestion.
 
Moved thread over here since this is more up this forum's alley.
 
First of all, I would not go with a custom-built machine. If you're doing any production work, having a top-tier vendor with an on-site SLA and direct access to the exact identical parts throughout the warranty period is very important.

Few thoughts come to mind:
1. Will users be remoting into machine to use it, or interfacing with the data through a web/client application?
2. Is the database part of a vendor product? If so, what product? If this is part of a custom/homemade solution, what can you tell us about it?
3. What kinds of data will this be returning? Any embedded types, such as blobs? Any idea on column and row counts, both for the pool of data and some potential resultsets?
4. What is the network and infrastructure like going from user to database and back again?

Edit:
5. What is your budget? Do you have any existing business discounts with top-tier vendors?
6. What is your uptime and availability requirement?
7. Anyone familiar at your site with backup/rollback procedures of databases and transactions in SQL Server? If so, have you decided how to roll this in with existing backup procedures of your other data?
 
Last edited:
Since your request for advice is very thin on the specific details....

Here are some guidelines

HP or Dell

Use Hardware RAID 10 or RAID 5 and make sure you buy the BBU option.

Use SAS drives if at all possible.

Quad core or better

16GB RAM or more SQL eats RAM
 
Your usage profile doesn't really help narrow it down. I mean, if 3000 new records a day is the extent of their activity, the you can go with a lower end server and save some costs. Myself, I'm a fan of HPs servers. I use DL160s for a lot of smb projects. P410 Raid with 512 BBWC, pared up with some SATA drives, no problems.

Then, I'd throw esxi on there and virtualize.
 
The previous company I worked for we had a small budget for some SQL servers so we bought them as Dual Quad Core processors, 24GB of RAM, a good RAID card with 1GB of on board memory and battery backup, with 3 sets of drives in RAID1. These were IBM servers X3550 servers with 2 hour onsite service warranty for 3 years.

So set 1 was for the OS, Set 2 was for the DBs, Set 3 was for the logs. We then had a Drobo 800i (equivalent) in multipath setup for the SQL backups every 24 hours.

We were serving out to 10,000 users without much issue.
 
PTNL said:
First of all, I would not go with a custom-built machine. If you're doing any production work, having a top-tier vendor with an on-site SLA and direct access to the exact identical parts throughout the warranty period is very important.

Few thoughts come to mind:
1. Will users be remoting into machine to use it, or interfacing with the data through a web/client application?
2. Is the database part of a vendor product? If so, what product? If this is part of a custom/homemade solution, what can you tell us about it?
3. What kinds of data will this be returning? Any embedded types, such as blobs? Any idea on column and row counts, both for the pool of data and some potential resultsets?
4. What is the network and infrastructure like going from user to database and back again?

Edit:
5. What is your budget? Do you have any existing business discounts with top-tier vendors?
6. What is your uptime and availability requirement?
7. Anyone familiar at your site with backup/rollback procedures of databases and transactions in SQL Server? If so, have you decided how to roll this in with existing backup procedures of your other data?
Click to expand...

Ad.1
Users will interface with the data through a web/client application (Linux server, same network)

Ad.2
DB is part of a custom/homemade solution, mostly working on a text data (not bigger than 255 characters)

Ad.3
Mostly text (no blobs for now) , biggest table has 18 columns and that one will have incremental rows increase (those 3000 per day); also I'm looking to run some "jobs" on those data (compare columns and update values based on that)

Ad.4
It is local only (100/1000)

Ad.5
~$3000

Ad.6
24/7, but mostly will be "used" 12-15 hours per day

Ad.7
As for now we are doing once per day

Hope it will helps.

Thanks.
 
A low-end Dell server would fit that budget. Something along the lines of the R310 hardware with 8 GB RAM and a redundant power supply. You can decide what hard drive and RAID arrangement is best, but given the details you provided I think two RAID-1 arrays of SATA drives -- one array for app/OS, the other array for DB -- would suffice.

Once you get out of development, you can splurge more for nicer disks and beefier hardware on the production box
 
Watch your RAID cards though. We ran into issues the one time we had a standard raid card, we needed one with some caching on the card for our SQL servers.
 
Is it better to get PERC H700 (512MB cache) or just stick to SAS 6iR with 2x RAID1 SATA configuration?
 
JackTheKnife said:
Is it better to get PERC H700 (512MB cache) or just stick to SAS 6iR with 2x RAID1 SATA configuration?
Click to expand...
As alluded to by previous comments, it depends more about the transaction volume, frequency, transaction time needed (assuming queries have been optimized), whether complex table locking is necessary or not. And those comments are also based around much, much larger scopes of usage than what you've outlined.

So purely based on what you've revealed about the DB schema and structure, I wouldn't think that would be necessary for a development box -- and possibly not even the production machine. My company has used plenty of those machines with the SAS 6IR with SATA drives for plenty of internal applications with larger DB scopes than yours. And things have been working great. My suggestion is to save the cost difference on this machine, and apply it to the budget on the production machine you will eventually deploy.
 
You must log in or register to reply here.
Back
Top