SQL Server 2005 Enterprise v/s Standard

  • We are creating a new enterprise level software (web application) to be installed on 2 node 2005 SQL Server SAN cluster. The DB is going to be running live OLTP application and live reports. The DB is expected to be about 150 GB to start with. XML and image (< 1 MB) files make 2/3 of database size. DB is expected to have max 50-100 concurrent users. DB has data auditing running - all transactions being written to history tables (can grow to terabyte in 2 years time). Are these really highly desired (practically used) install features not available in Standard edition?
    - Partitioning, More CPUs supported, Fast Recovery, Indexed View Matching, Parallel processing of indexing operations, Online Restore, Advanced SSIS features, Additional tuning options for the accuracy, performance, and scalability, Text Mining for analysis via reporting and OLAP.

    Trying to determine weather we really need SQL Server Enterprise or Standard edition (for Prod env.) is good enough for our requirements. Currently in UAT application is running reasonably well.

    Even if we don't need Enterprise now, are we going to need it in near future for performance, scalability, overall maintenance of db in long run

  • Are these really highly desired (practically used) install features not available in Standard edition?

    - Partitioning, More CPUs supported, Fast Recovery, Indexed View Matching, Parallel processing of indexing operations, Online Restore, Advanced SSIS features, Additional tuning options for the accuracy, performance, and scalability, Text Mining for analysis via reporting and OLAP.

    Basically those are all enterprise features. The advanced SSIS feature are like data mining, text mining, and data cleansing, also fuzzy lookup which I don't really have a use for..

    See here:

    http://www.microsoft.com/Sqlserver/2005/en/us/Compare-Features.aspx

    CEWII

  • Which features out of these are generally used and for exactly/practically what purpose:

    Partitioning, More CPUs supported, Fast Recovery, Indexed View Matching, Parallel processing of indexing operations, Online Restore, Advanced SSIS features, Additional tuning options for the accuracy, performance, and scalability, Text Mining for analysis via reporting and OLAP.

  • What do you mean generally used? I'm sure there are plenty of people using all of them. The issue is whether they will help in your environment. For that, you should read about them and decide whether they apply.

  • Thanks SSChampion.

    I tried to explain our environment in my original email which can grow to 1 terabyte in 1-2 years.

    I think 2 more important and more commonly used ones are:

    Partitioning, More than 4 CPUs - What do you think about these EE features, are we going to need these 2 items.

    Not sure on these.

    Fast Recovery, Indexed View Matching, Parallel processing of indexing operations, Online Restore, Advanced SSIS features, Additional tuning options for the accuracy, performance, and scalability, Text Mining for analysis via reporting and OLAP.

    Please advice from your experience. Can we atleast say, we should be good on SE to start with may be for a year or so and then move to EE when really needed.

  • You absolutely can start with Standard and move to Enterprise, but again, you haven't given enough information for us to decide if those features matter.

    The size of the database doesn't have much to do with CPU load, or the need for partitioning. I have a 1TB disk on my desktop. I could easily have a 1TB db without partitioning. That matters more with large single tables that often query a small portion of the data, usually by some partition function like range or date.

    all the rest of those features are used for different situations, but rather than ask us to explain where they will be used, why don't you research each of them. Spend an hour working on each one and see if it applies to your situation. There isn't a quick answer as to whether it will or not.

  • we have 1TB databases on Standard edition and 100GB databases on EE. we use online indexing mostly for EE but with the speed of today's hardware it might be cheaper to buy more disks to make maintenance go faster.

  • If I was building this system, I would not be building it on SQL Server 2005. I would be building this on SQL Server 2008 and implementing filestream access for the image data.

    This would keep the image data as files in a file system and synchronized with the database during backups.

    Whether or not I purchased Enterprise Edition would depend upon the hardware I was getting and what the utilization of the system was.

    Jeffrey Williams
    “We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

    ― Charles R. Swindoll

    How to post questions to get better answers faster
    Managing Transaction Logs

  • Jeff,

    I partially agree with your post, I have had to buy Enterprise because there were features I needed, your points are also valid about hardware and utilization but if there are needed features you are going to go that direction..

    CEWII

  • We have a system that is incredibly similar to yours, built on standard edition. For us, using online rebuilds would be extremely useful. We do have dedicated reporting machines, so direct reporting from our production system isn't as much a concern as is maximum possible uptime and the briefest possible maintenance window. One other difference that bit us was not being able to use Asynchronous mirroring.

    To sum up, for us it would have been worth the additional investment. Look carefully at growth, and then factor in what will happen if your estimates are low. Also, I think Jeffrey has some very good points about 2008, although I don't know the cost boundaries you must stay within.

  • Thanks for all the replies and to all of you.

    All the information is going to help make some decisions. The good thing is we can switch to EE if don't do it upfront.

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply