SQL 2016 Enhancements to In-Memory OLTP

SQL2014's introduction of In-Memory OLTP was GREAT, until you read the small print. SQL 2016 has enhanced the technology somewhat, making it a little better! 

Details here from Aaron Bertrand over on sqlserverperformance.com :

http://sqlperformance.com/2015/11/sql-server-2016/in-memory-oltp-enhancements

SP3: Improvements to troubleshooting

Improvements for troubleshooting are in the latest service pack for SQL Server 2012. 

Applying service pack 3 for SQL Server 2012 means that the query statistics DMV (dm_exec_query_stats) will now report on memory grant, parallelism and thread information. 

For a full list of new columns and further information look here: https://support.microsoft.com/en-us/kb/3107398

More information on the service pack can be found here: http://blogs.msdn.com/b/sqlreleaseservices/archive/2015/11/24/sql-server-2012-service-pack-3-is-now-available.aspx

SQL 2012 Service Pack 3 is now available.

Service Pack 3 for SQL Server 2012 is now available. 

Obtain it here: https://support.microsoft.com/en-us/kb/3072779

Information on the service pack and its improvements can be found at the following link:

http://blogs.msdn.com/b/sqlreleaseservices/archive/2015/11/24/sql-server-2012-service-pack-3-is-now-available.aspx

Simple SQL?

I'm not sure how often you have encountered the comment, "SQL Server is easy. All you have to do is click next, next and finish". Well I'm good friends with quite a few Oracle DBA's (with no real sense of humour) so I hear it a lot, I hear it all the time!

Of course, it isn't true, not by a long way but it did make me wonder. Is the simplicity of SQL Server also one of it's downfalls?

It is of course wonderfully easy to use. Microsoft's user interface is second nature to most if not all of us and yes there are wizards, lots and lots of wizards. Installing SQL Server is that easy that anyone could do it, really. You want a new database? Easy, right click over there, select new and done. Brilliant, isn't it?

You see the problem I have is that anyone can do it. I am sure that everyone reading this has had to fix a SQL Server at some point and all of its default settings are intact, left completely unaltered. You also know the specific one's that I am talking about here because these are the one's that can cause you all kinds of pain (and we'd change them)! Parallelism, maximum memory, tempdb, autogrowth etc etc. I haven't even mentioned maintenance yet!

For the non database person all of that simply doesn't matter. They've got their instance. The application is connecting wonderfully, queries are running beautifully and all is fantastic. 

It's just that it isn't...

Sure in the beginning things are great but after a while strange things start to happen. Those queries start to run a heck of a lot slower than before. The OS comes under pressure, the CPU usage has gone through the roof and what the heck is a CXPACKET wait...is it the network?!?!

The person who set it all up is not to blame. We are all familiar with the term "accidental DBA" but what about the seriously reluctant one? They didn't ask for this and now they are doing all kinds of weird and wonderful things to rectify a problem they probably don't even understand.

This is an all too common scenario and it might be in part because the role is often misunderstood (seriously, we don't just look at graphs all day!). But the way I see it, the main reason is that there are often seemingly easier alternatives to bringing in a DBA to handle everything. And you know why? Because they believe SQL is simple, and anyone can do it. Right?

We know better.

SQL Server Misconceptions - The Remote Query Timeout Setting

So this is the first post in a little series I’m doing about misconceptions within SQL Server. I’m going to be looking at a number of items that don’t work as you might think they do and a few of things that might look a good idea…but they’re really not.

So the particular setting that I am discussing today is the Remote Query Timeout option and you can find what this is currently set to by running the following bit of code in Management Studio:

sp_configure 'remote query timeout (s)'

Or, because SSMS is clever we could just use sp_configure 'remote query' instead and in both cases we'll get results similar to the following depending on your setting:

Now the common misconception with this option is probably because of the following screen within SQL Server Management Studio (Server Properties -> Connections) where we see the following.

So the first checkbox allows remote connections to the server so we could assume that the remote query timeout value underneath (here set to 600, the default) is for incoming connections to the server. We might think that we could change this because we're getting timeout errors within a client application when calling SQL and maybe changing this will help prevent the errors.

But we’d be wrong!

Here’s TechNet to explain why:

Use the remote query timeout option to specify how long, in seconds, a remote operation can take before Microsoft SQL Server times out. The default is 600, which allows a 10-minute wait. This value applies to an outgoing connection initiated by the Database Engine as a remote query. This value has no effect on queries received by the Database Engine.

That last line pretty much says everything we need to know, the value has NO EFFECT on queries RECEIVED by the Database Engine. None whatsoever, it is used purely for outgoing connections.

You can read more about this option here

Paying SQL Inheritance Tax

It is an all too common scenario.

You’ve just started as a DBA at a new organisation. Your first task (after locating important things as coffee, toilets and vending machines), will be to go through the SQL Estate familiarising yourself with all the new instances that you’ve inherited. 

Hopefully someone will have taken the time to carefully put together documents ensuring that you have all the right information that you require to get up to speed quickly.

But of course this won't be the case!

If you’re lucky you’ll get a handwritten list of SQL servers and now you need to go off and gather all the important pieces of information that you need to administer these instances correctly. Now just to add, I’m not talking maintenance here. It's very common that the first thing we do is login and check that all the relevant tasks like backups and consistency checks are up to date, and that is good, but we’re at a much more important step before that.

The very first thing you need to do is to find out what each server is, what it is for, what it is doing, who owns it (and its databases) and what its recovery objectives are.  

It is imperative that you get this information because all of those things will determine many of the technical processes that you will be either implementing, or certainly looking after. Take DR/HA for example; technical terms yes but the business rules determine the strategy for both.

And you cannot simply script this from SQL or get a 3^rd party tool to retrieve the information. It is absolutely impossible to do this in an automated manner. No, you're going to have to speak to people to find out what you need. You're even going to have to ask people who the right people are to ask!

It can be an extremely long winded and painful task. New SQL instances will seemingly be popping up from nowhere over the next few days, weeks even! With each new discovery, the whole information gathering process starts again. 

Now here is the most frustration thing.  It could have all been done before you even stepped through the door. But it wasn't, and you're now paying for these gifts you've inherited. Inheritance Tax.

So please take the time to do this. Do it now if you haven't already done so. It isn’t just going to save your bacon (and it will) but it is going to save the next person an awful lot of pain, and you can bet they’ll thank you for it.

Hello!

Hi and many thanks for visiting my blog!!

This blog is all about my day to day job as a Microsoft SQL Server DBA, and all the fun and games that go with it!

A little bit about me.

I'm a Microsoft Certified Technology Specialist and have worked with SQL Server for quite a few years now and I have the hair loss to prove it!  

I started out in IT life many moons ago as a Software Developer working with Visual Basic 5/6 and from there I moved on to the .NET revolution which involved a fair chunk of SQL development.  I refer to this phase of my career as the "bad habit" years.

Eventually I was given the opportunity to take up the position of DBA and despite not really knowing what it entailed took on the challenge of looking after a handful of SQL Server 2005 instances.

Not surprisingly I found the role quite overwhelming at first.  There were so many new and exciting things to learn and quite a lot of broken things to fix too and of course there was lots and lots of advice on the internet about how best to look after my SQL Servers.  Some of it was good and some of it not so good, and a little bit of it was quite frankly dangerous!  

So that's where the SQL Clarity title came from.  What I want to do with this blog is to give an accurate insight into what DBA's do on a daily basis.  So I'll be sharing real world examples and scenarios, from setting up a clustered SQL instance to performance tuning.  I'll be posting the scripts that I use, hints and tips that I've picked up along the way and some of the other bits and pieces that I find useful.

I'll also be keeping up to date with the world of SQL Server sharing updates and information from many of the experts out there in the SQL community.

Happy reading.

D