Archive for the ‘sqlserver’ category

SQL Server isn’t cheap. Licensing costs alone for a simple 4-core VM running SQL Server Standard Edition (and the Software Assurance required to make those licenses worthwhile) will typically cost around $10,000 to license for 2 years – while Enterprise Edition Licenses for the same VM would weigh in at closer to $40,000 for those same two years.

Against such a backdrop, when users post detailed information about bugs, problems, or issues – only to have their reports dismissed with “Closed – as Won’t Fix”, it’s not hard to see why so many SQL Server users end up hating connect. To them, Connect is (at worst) either an affront to the amount of money they’ve invested in SQL Server as a product or (at best) simply a quagmire: a place where bug reports and feedback enters only to become aimlessly lost, overlooked for years to come, and possibly never see the light of day again.

And, I get it: In order for SQL Server to remain competitive, Microsoft has to keep their limited pool of developers (there’s a real talent shortage in terms of the skill-sets needed to work on something as complex as SQL Server’s internals) focused on tight deadlines if new features and and capabilities are ever going to ship – meaning that Microsoft sometimes has to take a hard-line when it comes to bona-fide bugs.

But, ultimately, there’s still a perception that Microsoft simply doesn’t care or can’t be bothered – in far too many cases.

One Thing Microsoft Could and Should Do to Help with this Problem

One thing Microsoft really needs to do, is go BACK and re-evaluate previously closed bug reports.

For example, consider this report – covering a problem with reviewing data from Extended Event Sessions. Originally filed against SQL Server 2014, the issues was closed as not reproducible. Fair enough – sometimes trying to reproduce bugs is hideously difficult – especially when there might not be enough detail or context in the first ‘repro’ sent in with a given bug. But, all these years later, the bug still exists (even against SQL Server 2016) and the bug continues to be “Closed” or ignored – whereas there IS a simple explanation for what’s going on and IF Microsoft were to review closed bugs, you’d assume they’d re-evaluate this one, see what’s going on, and FIX the problem.

One of these is CLEARLY not like the others – and, in fact, were it not for that specific thing (and the entire climate leading up to that disaster + everything that’ll follow thereafter), I’d say that living in interesting times was hardly a curse…

With SQL Server 2012, Microsoft changed how SQL Server was licensed – by making customers pay per core instead of per socket. While this caused grumbling among SQL Server professionals and customers, I’ve always seen it as a MOSTLY fair move on Microsoft’s part – as their goal with licensing SQL Server has always been to charge customers based upon the amount of compute being handled by SQL Server.

Where this change feels a bit less than fair, though, is when it comes to the artificial limitations put into place against SQL Server’s Standard Edition’s use of RAM (SQL Server 2012 Standard Edition was limited to an absurd 64GB of RAM, whereas SQL Server 2016 and 2016 Standard Editions are limited to a still paltry 128GB of RAM).

Stated differently, I think it’s fair for Microsoft to charge customers per core – but not if they’re going to heavily curtail how much compute you can do with this core by severely limiting the amount of RAM you can allocated per core. (Standard Edition Licenses weigh in at around $2,800 per core – but if you’ve dropped $45K for a 16 core 2014 Standard Edition box, you’re limited to a paltry 8GB of RAM per core – whereas a 2016 instance with 24 cores would cost $65,000 yet top out at a miserly 5.33GB/core of RAM – or less RAM per core (for a higher overall price).)

A Better Way?

Yes, there are ways around this limitation (like using Buffer Pool Extensions (available on Standard Edition) or even potentially spinning up multiple instances per OSE – as the 128GB RAM limitation is per instance NOT per host), and Enterprise Edition really isn’t that expensive when you compare it to Oracle or even when you think about how much it will DO for you in a given year (and compare how much it costs per year to, say, what you’d pay 2 or 3 employees per year).

Still, I think there might be a better way: Enable up to 32GB of RAM per each 2-core Standard Edition ‘pack’ licensed. With this approach, a simple 4-core VM could pull off up to 64GB of RAM, a ‘decent’ Standard Edition instance with 8 cores could pull off up to 128GB of RAM (the max currently in place today) and a higher-end 2016 box with 24 cores (i.e., 12x 2-core packs) could top out at 384GB of RAM.

Arguably, this approach would add a tiny bit of additional complexity into the licensing landscape (and orgs running 4-core boxes today with 128GB of RAM would obviously find fault with my ‘logic’), but I’d wager that medium to large Standard Edition instances would benefit tremendously – to the point I’d even guess that Microsoft Support Services would probably field a slightly smaller number of support calls for performance related issues simply because of the extra benefits additional RAM can provide to SQL Server workloads.

SQL Sentry just announced that the PRO version of Plan Explorer is now completely free – as in you don’t even have to register to use it. (For those in the know, there used to be two versions: a ‘lighter-weight’ free version, and a paid-for PRO version; they’ve now consolidated all features into the PRO version – and made it free.)

Spoil Yourself with Better Insight and Analysis

I’ll be honest: since I spend so much of my time on my clients’ machines when analyzing performance problems and looking at execution plans, I’ve made a conscious effort in the past to avoid using Plan Explorer too much in my Lab – for fear of spoiling myself.

SQL Sentry’s Motivation

It doesn’t take a genius to see that SQL Sentry is trying to use Plan Explorer PRO to establish a ‘foot in the door’ with as many potential customers and clients as possible.

But a maneuver like this only works with a market when you’re providing something that users REALLY want, management can easily see the value being offered, and the tool being offered is really solid (non-buggy).

While there are tons of undocumented T-SQL commands out there, one of my all-time favorites is this little gem:

SELECT SERVERPROPERTY('ErrorLogFileName');

It’s not much, but it will show you default details on:

Where the SQL Server Binaries have been installed

Where you can find SQL Server’s log files (as .txt files)

Where the default trace (.trc) files are located

Arguably, there are better ways to retrieve some of this information (like SELECT * FROM sys.dm_server_registry;).

But SERVERPROPERTY(‘ErrorLogFileName’) works just fine when looking for low-level details.

The only real problem I have with this particular snippet of T-SQL is that I can never remember EXACTLY what the property is to ‘search’ for (i.e., ‘ErrorLogFileName’) – which is part of why I’ve blogged about it (so that I’ll be able to more easily find this snippet in the future).