Archive for the ‘rants’ 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.

Blockbuster treated its customers with contempt, so it was only natural that we all bolted as soon as any other options came our way.

Unfortunately, it sometimes feels like some of Blockbuster’s corporate leadership ended up working at Microsoft on the Windows 10 Update Team – where they’re driving a corporate culture of treating Windows 10 customers with contempt.

But even Windows 10 Pro users get crapped on as well – as they’re gradually trained to schedule or execute reboots for minor security fixes or patches, only to find that one day, when they go for a ‘quick reboot’, they’re stuck for 20 – 60 minutes (depending upon hardware) while Windows 10 reinstalls itself from scratch with absolutely NO WARNING at all.

If that’s isn’t a big ‘screw-you’ from Microsoft I really don’t know what is. It assumes that Windows 10 users might never need to shut-down right before heading to an important meeting (or presentation) or zip off to the airport (or maybe even just have lost power during a storm) – and it assumes that a long and scary re-install is exactly what customers need – without giving them a single heads-up.

Even if you try to take a cautious approach and review what might be pending as part of a reboot, it’s not like you’ll get the feeling that Microsoft really gives a crap about letting you know what might be getting pushed. Here, for example, are the exact details captured on my box before a ‘reboot’ was required to push a 25 minute update on me to roll-out Windows 10 Anniversary Edition (Build 14393) – where there are NO details provided what so ever.

Thanks Microsoft.

And you’ll forgive me if some aspects of working with you bring back memories of what it was like to be treated by Blockbuster.

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.