Voice of the DBA

Tag: sql server

  • What Differentiates Enterprise?

    Now THIS is Enterprise Edition.

    There seems to be regular disagreement from SQL Server professionals about what features are most important for future versions and which bugs should receive the highest priority. However one thing that many customers complain about is the lack of features in the Standard Edition (SE) that exist in the Enterprise (EE) or Data Center (DC) editions.

    In SQL Server 2000, it used to be that a customer had to buy Enterprise Edition (EE) to get clustering or log shipping. In SQL Server 2005 Standard Edition got clustering, but no partitioning or database snapshots. SQL Server 2008 and SQL Server 2008 R2 added new features, some of which are only available in EE and DC editions. In each case, as SQL Server evolves, some features get moved down to SE, while others do not. The distinctions between editions are arbitrarily made, with the idea that some features are “Enterprise and are used for large scale SQL Server installations. However there are also size limits on the editions that limit the number of instances, nodes in clusters, memory, processors, and more.

    Is that the best way to separate the editions of SQL Server? It seems that I rarely find many people that agree with the different mix of features and limits that are built into the different editions.  This Friday I wanted to get your opinion:

    What should differentiate Enterprise (or Data Center) edition from Standard edition?

    Do you think there should be a feature distinction? Or a hardware distinction? What would you change about the way things are done, or what makes the most sense to you, as a SQL Server customer.

    In my mind, I’d like to see SQL Server priced on scale, and not on features. I’d like to see all features in all editions above Express. However charge me by the core, or some formula of cores + RAM that might make licensing cheaper for those low end dual core systems we have now, maybe equal for 4-8 cores, and then scaling up as people move to more cores, and handle larger workloads.  Let me add licenses as I add hardware, and easily move those licenses around as I move my instances between physical servers.

    Licensing is always a controversial subject, and one that we rarely agree on. However I’m curious what people think about the plan that might seem the most fair to them.

    Steve Jones

    The Voice of the DBA Podcasts

  • Test Before Deciding

    Do you extensively test?

    Will a new index improve the overall performance of your database server? Will adding another index slow down your insert or update performance? Can adding another file to tempdb make things run quicker?

    The answer to all of those questions is definitively “it depends.” That sounds contradictory, but it’s actually the answer that applies to all of your workloads. Your workload, on your version of SQL Server, on your hardware, with your data sets, will perform differently than the same version of SQL Server on the same hardware than my workload.

    What does that mean for DBAs and developers? It really means that you can’t easily make hard and fast decisions about many of the settings, configurations, and designs you use for performance are just guidelines. The best DBAs I know have lots of guidelines and rules of thumb that they use to begin their design or analysis of a database instance. However they are willing to make exceptions or changes to their “rules” if the situation warrants a change.

    How do they know when to change? They test.

    It’s that simple. Running tests, comparing the changes in performance, measuring the metrics that occur from implementing a particular feature allows a DBA to make an educated guess about whether or not any alteration of your code, your indexes, or your design will bring about improvement. However testing before you make the chance isn’t enough. Even after you have made a change, you need to continue to monitor, essentially “re-testing” in a live system, to determine if the system is still performing well.

    Just trusting that you are “sure” of what to do or not to do is a mistake. Set up tests, gather metrics, and make informed decisions to ensure you servers are operating at peak performance.

    Steve Jones

    The Voice of the DBA Podcasts

  • My Connect Items – Won’t Fix

    There’s been some work to close out items in Connect that aren’t going to be fixed. I don’t know exactly if these are items that aren’t good ideas, are dropped because of a lack of resources, or because no one wants to figure that out.

    However, I had three items closed as Won’t Fix in the last couple days. None are what I’d consider critical, but they were ideas I had to make the product work smoother. I won’t resubmit them, unless I get some feedback that people find them important. Here were my items:

    Remove Auto-close

    Set the database default to simple

    Allow User Objects to be Deprecated

    The last one is the one that I think made the most sense. Not as something that’s critical, but something that might help smooth the way that people work with SQL Server, and help them build better software.

  • NoSQL is Not the Answer

    The NoSQL Logo

    There’s a lot of talk and press around NoSQL databases, which are a class of systems that are different from relational databases (RDBMS). Most of us are familiar with the competitive RDBMS’s to SQL Server; systems like Oracle, DB/2, MySQL, PostgreSQL, and a few more. NoSQL systems are less well known, going by names like Cassandra, MongoDB, and the best known system used by Google, BigTable.

    It seems there are a lot of ranting and raving about which system is better, and even some comparisons that look at performance in different ways that we use systems. I found a SQL Server v MongoDB comparison recently. It seems to show that SQL Server lags way behind MongoDB in terms of simple insert, update, and select operations. I’m not sure it’s the best real world test, but it shows some interesting results.

    Those comparisons  are important, but ultimately we do a lot more than simply insert rows and select from basic small sets of data in many of our applications. I see many systems making use of complex queries with aggregations, multi-table joins, and complex sorting operations. These might work well in a NoSQL system, but they also might not. Who knows how well complex business transactions and reports will perform on these platforms. Someone will have to try and see if these systems can handle those needs.

    NoSQL is worth examining further and learning about. I would not be surprised to see some of the features, such as easier scale-out, coming to SQL Server in the next few years. However I’m certainly not ready to view NoSQL systems as any type of evolution of the RDBMS. I think it’s much more likely that NoSQL systems solve a certain domain of problems better than a row-oriented RDBMS, much like column-oriented databases seem to be much more efficient at working with some types of data warehouses.

    Steve Jones

    BTW, if you want to listen to a little NoSQL humor, check out this video. It’s Not Safe For Work (NSFW), so be sure that you have a properly configured “cone of silence” so as not to offend others.

    The Voice of the DBA Podcasts