Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Which version of Sql Server 2008 do you use with your Enterprise Moss installation and why?

More specifically, do you actually need all that the Enterprise Sql Server version provides or is the standard version more than capable to provide service for a company of 1000+ users. What about 5000 users?

As an added note, we will be running the entire installation in an esx farm with a SAN data source.

share|improve this question
up vote 3 down vote accepted

Rather than counting the number of users, I'd ask a few other questions.

Does it need to be accessed by end users 24/7? If so, you need Enterprise Edition to get online index rebuilds. If you can get maintenance windows after hours or on the weekends, then you can get by with Standard Edition, which takes indexes offline while rebuilding them.

Have you tested your IO throughput? You said you're using ESX - if it's v3.5 or earlier, or if you're not using the top license tier for v4, then you don't get multipathing capabilities. Your throughput is confined to just one host bus adapter per array. If these terms make your eyes bleed, here's the short story - you might be bottlenecked at just 200-400MB/sec, which can be saturated with a dozen SATA drives. No matter what kind of SAN you hook up, it won't matter if you can only get one HBA of throughput at a time. Standard versus Enterprise will be the least of your problems.

How do you plan to do disaster recovery? If you're thinking about using log shipping or database mirroring, then look into Enterprise's capabilities. If you're doing mirroring, then you get some slick features around corrupt page recovery by using the mirror's SAN instead of the primary.

Are you storing sensitive data or documents in SharePoint? If so, you should consider Enterprise to take advantage of Transparent Data Encryption. That encrypts the data at rest, when it's sitting on the SAN, thereby preventing someone from grabbing a SAN snapshot or a copy of your backup tapes and restoring an entire copy of your database when you're not looking.

Don't worry about compression. Enterprise adds the ability to do data compression, but don't let that sway your decision. Your SharePoint users are probably going to be storing a ton of binary documents, which don't compress very well anyway.

share|improve this answer
Wow. I will find out and post back. – Mike T Jun 4 '09 at 19:58
Additional on compression - most of the docs will be stored as off-row LOB data (i.e. the data will not be part of the actual table record, but there will be a link to it's location in the database). In that case data compression will not compress it anyway - only does on-row data compression. – Paul Randal Jun 4 '09 at 20:30
DUUUDE, you're good! – Brent Ozar Jun 5 '09 at 11:37
@Brent Does your wording of Enterprise refer to SQL Enterprise or MOSS Enterprise? Also, MOSS 2007 SP2 added index rebuilds as a background maintenance task for all MOSS versions. – Alex Angas Jun 17 '09 at 14:18
@Alex Brent is talking about SQL Server Enterprise Edition. The automatic MOSS index rebuilds run online if you are using SQL Server Enterprise (which supports online rebuilds) and offline if you are using SQL Server Standard (which does not support online rebuilds) – Sean Earp Jun 17 '09 at 16:39

If you are starting with around 1000 users and might end up with 5000+ users, I'd say it's a typical scale-up project, and I would defo go with enterprise edition. I would probably go with a clustered backend right from the start.

That said, it all depends on the traffic pattern of those 1000-500 users and the service level you wish to deliver. It's not impossible to switch from standard to enterprise later either, but it will cost you some downtime, which might or might not be an option.

share|improve this answer

For a customer we chose a Sql Server 2008 Enterprise Ed. 2 node cluster for high availibility, not speed. The design is a conservative straight out of the Microsoft playbook 5 node farm with 3 front end MOSS nodes on Hyper-V and a Dell Equallogic iSCSI SAN.

The SQL cluster was not virtualized since at design time (mid 2008) the virtualized SQL 2008 cluster configuration was not supported by Microsoft.

alt text

share|improve this answer
Though it isn't officially supported, that shouldn't stop the vm's from being unaware that they are not physical machines... right? – Mike T Jun 4 '09 at 19:27
We set up the architecture in mid 2008. It could be that Microsoft started supporting virtualized SQL clusters later that year. – Peter Stuer Jun 4 '09 at 20:03
Thanks for the info. That is nearly the same configuration we will run. The only addition will be that all of them will be housed within an ESX farm providing redundent availablity. – Mike T Jun 9 '09 at 16:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.