Glenn’s Tech Insights For July 15, 2019

(Glenn’s Tech Insights… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can get more visibility. It covers interesting new hardware and software developments that are generally relevant for SQL Server).

July Release of Azure Data Studio

On July 11, 2019, Microsoft released Azure Data Studio 1.9.0. This release has a number of new features and improvements, as detailed in the Release notes. So far, Microsoft is keeping pretty close to a monthly release cycle.

New features and improvements include:


image

Figure 1: Azure Data Studio 1.9.0


SQL Server Security Updates Released

On July 9, 2019, Microsoft released a GDR Security Update for all supported Service Packs for SQL Server 2014 and newer. This is for CVE-2019-1068, which is a remote code execution vulnerability. This is the complete description:

A remote code execution vulnerability exists in Microsoft SQL Server when it incorrectly handles processing of internal functions. An attacker who successfully exploited this vulnerability could execute code in the context of the SQL Server Database Engine service account.

To exploit the vulnerability, an authenticated attacker would need to submit a specially crafted query to an affected SQL server.

The security update addresses the vulnerability by modifying how the Microsoft SQL Server Database Engine handles the processing of functions.

There are updates for SQL Server 2014 SP2, SQL Server 2014 SP3, SQL Server 2016 SP1, SQL Server 2016, and SQL Server 2017 RTM. For each SP level, there are two separate branches that each get a separate update. There is the GDR branch, which only gets Security Updates, and there is the CU branch, which gets all of the fixes and improvements in each CU (including security updates).

I think most organizations are better off on the CU branch, since they will get many more bug fixes and actually get product improvements and new features. The GDR branch will require less patching (since only security issues are fixed), so it may be a better choice for some organizations. If you are on the GDR branch, you need to be careful to only install GDR-only updates. If you install a CU on a GDR-branch instance, that will move you to the CU branch from then on.

You should also be aware that Microsoft is pushing this update out if you are running Microsoft Update on your machine. Microsoft Update is a superset of Windows Update, which will automatically download and install things like SQL Server security updates. This is not something you want happening on most Production SQL Server instances! It is much better to do a manual installation, at a time of your choosing, after you have tested the update on a non-production instance.

You should also be aware that Microsoft Update will probably trigger multiple reboots when it installs these SQL Server security updates. This is because the Windows OS updates will be installed first (which causes a pending reboot). Then, the SQL Server update will be installed (which may cause a pending reboot). Finally, if you have named instances on a machine, with different versions of SQL Server, you may have to reboot after the SQL Server update for each version. This is what you see in Figure 2.


Windows Update

Figure 2: Microsoft Update Dialog


Incredibly, I wrote one of these without talking about hardware or AMD!


Presenting at PASS Summit 2019

I am honored to have been selected to present two sessions at the PASS Summit 2019 in Seattle, WA. This year, I have a half-day session and a regular, general session.

image

My half-day session is Dr. DMV’s Troubleshooting Toolkit, and here is the abstract:

Dr. DMV’s Troubleshooting Toolkit

Dynamic Management views and functions allow you to easily see exactly what is happening inside your SQL Server instances and databases with a high level of detail. You can discover your top wait types, most CPU intensive stored procedures, find missing indexes, and identify unused indexes, to name just a few examples. This session presents, demonstrates, and explains a complete set of diagnostic DMV queries that you can easily use to detect and diagnose configuration and performance issues in your SQL Server instances and databases. This session goes into exhaustive detail on how to interpret the results of each of the diagnostic queries, including relevant background information on how to properly configure your hardware, storage subsystem, operating system, SQL Server instance, and databases in order to avoid performance and scalability issues.

This is a topic that I have presented and taught multiple times, and it is something I am quite passionate about. I use my Diagnostic Information Queries on a daily basis in my consulting work, and they are extremely useful. Having 2.5 hours to go through them gives me plenty of time to cover them in detail without having to rush through them.

My general session is Hardware 301: Choosing Database Hardware for SQL Server 2019, and here is the abstract:

Hardware 301: Choosing Database Hardware for SQL Server 2019

Microsoft made some sweeping changes to their software licensing model for SQL Server 2012; moving from socket-based licensing to core-based licensing. This new licensing model alters much of the conventional criteria for hardware selection for database servers that will be running SQL Server 2012 and newer. This change still causes a significant amount of angst, with fears of huge increases in SQL Server licensing costs compared to older versions of the product. This session will cut through the uncertainty and hype to show you how to properly evaluate and choose your database hardware for usage with SQL Server 2016 and newer. You will learn how to choose hardware for different types of workloads and how to get the best performance and scalability for the lowest licensing cost, whether you are running in a physical or virtualized environment.

I will be talking about the latest developments with AMD and Intel server processors, and how they affect you as a data professional. With the upcoming release of the AMD EPYC “Rome” server processors (which I am 100% sure will be released by early November) the landscape of the server market has drastically changed. The old guidance about always buying an Intel-based server is not going to be a slam dunk any longer. This session is relevant for all versions of SQL Server, whether you are running virtualized or not.

Hopefully I will see you at both of my sessions and at PASS in general!

SQL Server Diagnostic Information Queries for July 2019

This month, I have just done minor updates to most of the query sets.

I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.

I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.

Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.

Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, and SQL Server 2016:


Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

SQL Server 2019 Diagnostic Information Queries

SQL Server 2019 Blank Results Spreadsheet

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 SP2 Diagnostic Information Queries

SQL Server 2016 SP2 Blank Results Spreadsheet

SQL Server 2016 Diagnostic Information Queries

SQL Server 2016 Blank Results Spreadsheet

 

Here are links to the most recent versions of these scripts for SQL Server 2014 and older:

Since SQL Server 2014 and older are out of Mainstream support from Microsoft (and because fewer of my customers are using these old versions of SQL Server), I am not going to be updating the scripts for these older versions of SQL Server every single month going forward.  SQL Server 2008 R2 and older are also now out of extended support from Microsoft.

I started this policy a while ago, and so far, I have not heard any complaints.

SQL Server 2014 Diagnostic Information Queries

SQL Server 2014 Blank Results Spreadsheet

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

SQL Server 2008 R2 Diagnostic Information Queries

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries

SQL Server 2005 Blank Results Spreadsheet

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results (and my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have quite a few comments and links in the script on how to interpret the results after each query.

After running each query, you need to click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet.

About half of the queries are instance specific and about half are database specific, so you will want to make sure you are connected to a database that you are concerned about instead of the master system database. Running the database-specific queries while being connected to the master database is a very common mistake that I see people making when they run these queries.

Note: These queries are stored on Dropbox. I occasionally get reports that the links to the queries and blank results spreadsheets do not work, which is most likely because Dropbox is blocked wherever people are trying to connect. I am not planning on moving these to Github any time soon.

I also occasionally get reports that some of the queries simply don’t work. This usually turns out to be an issue where people have some of their user databases in 80 compatibility mode, which breaks many DMV queries, or that someone is running an incorrect version of the script for their version of SQL Server.

It is very important that you are running the correct version of the script that matches the major version of SQL Server that you are running. There is an initial query in each script that tries to confirm that you are using the correct version of the script for your version of SQL Server. If you are not using the correct version of these queries for your version of SQL Server, some of the queries are not going to work correctly.

If you want to understand how to better run and interpret these queries, you should consider listening to my five related Pluralsight courses, which are SQL Server 2017: Diagnosing Performance Issues with DMVs, SQL Server 2017: Diagnosing Configuration Issues with DMVs, SQL Server 2014 DMV Diagnostic Queries – Part 1SQL Server 2014 DMV Diagnostic Queries – Part 2, and SQL Server 2014 DMV Diagnostic Queries – Part 3. All five of these courses are pretty short and to the point, at 164, 106, 67, 77, and 68 minutes respectively. Listening to these five courses is really the best way to thank me for maintaining and improving these scripts…

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!