All Good Things Must Come to an End

By: Glenn Berry
Posted on: December 16, 2019 6:29 am

All good things must come to an end. After slightly over seven and a half great years at SQLskills, it is time for me to move on to a new adventure. My last day at SQLskills will be December 31, 2019.

I have had the privilege and honor to work with a great team over the years, including Kimberly Tripp (b/t), Paul Randal (b/t), Jonathan Kehayias (b/t), Joe Sack (b/t), Erin Stellato (b/t), and Tim Radney (b/t).

I first met Kimberly back in 2006, when I attended a weeklong Immersion Event class in Chicago. I first met Paul a few years later, while he was still at Microsoft. I enjoyed following their work as separate entities and then later when they joined forces. I truly respected their work and really appreciated their professionalism. There was also a certain energy about their collaboration that stuck with me and it was obvious that they absolutely loved what they did for a living.

Jonathan is incredibly gifted technically, and very persistent. If he doesn’t already know the answer to a problem (which is rare), he will stay on it until he figures it out. Erin is very precise and detail oriented which are great qualities for a consultant or DBA. She has also become a respected, world-class authority on Query Store. Tim is very versatile and well rounded, and has become an expert in all things Azure. They have all been great co-workers and friends over the years.

I’m leaving with a lot of great memories. My personal blog is here.



Posted in: Uncategorized
Be the first to Reply!

SQL Server Diagnostic Information Queries for December 2019

By: Glenn Berry
Posted on: December 4, 2019 12:21 pm

(New: we’ve published a range of SQL Server interview candidate screening assessments with our partner Kandio, so you can avoid hiring an ‘expert’ who ends up causing problems. Check them out here.)

This month, I have done more minor improvements, especially for SQL Server 2019.

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 eleven 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 SQL Managed Instance, Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, and SQL Server 2016:

SQL Managed Instance Diagnostic Information Queries

SQL Managed Instance Diagnostic Results

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 six related Pluralsight courses, which are Azure SQL Database: Diagnosing Performance Issues with DMVs, SQL Server 2017: Diagnosing Performance Issues with DMVs, SQL Server 2017: Diagnosing Configuration Issues with DMVs, SQL Server 2014 DMV Diagnostic Queries – Part 1,  SQL 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 91, 164, 106, 67, 77, and 68 minutes respectively. Listening to these six 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!

Posted in: DMV Queries
1 Comment

Glenn’s Technical Insights For December 3, 2019

By: Glenn Berry
Posted on: December 3, 2019 4:00 pm

(Glenn’s Technical 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 new hardware and software developments that are generally relevant for SQL Server). It also can just be other technically-oriented items that I find interesting.

Intel Releases Cascade Lake-X HEDT Processors

On November 25, Intel released their new line of 14nm high-end desktop (HEDT) processors which is the Cascade Lake-X family. This is the latest iteration of Intel’s Core X-series Processors which have traditionally been their most expensive non-Xeon processors. This release includes four SKUs, ranging from 10C/20T up to 18C/36T.

Intel Core i9-10980XE       18C/36T      $979.00

Intel Core i9-10940X         14C/28T      $784.00

Intel Core i9-10920X         12C/24T      $689.00

Intel Core i9-10900X         10C/20T      $590.00

These prices are roughly 50% lower than the previous generation Skylake-X Refresh HEDT processors. Given Intel’s poor competitive position right now, a large price cut was about they best they could do to try to make this release more attractive. Even a 50% price cut doesn’t actually seem to be enough given the benchmark results for these processors.

Intel-Cascade-Lake-Pricing

Figure 1: Intel Cascade Lake-X Details

 

Interestingly, there is no 16C/32T SKU in this generation (which would replace the previous generation Core i9-9960X). I think it is pretty likely that Intel purposely skipped that SKU because it would not compare very well to the new 16C/32T AMD Ryzen 9 3950X.

The reviews (and benchmark results) for these four new HEDT processors have been almost universally negative. These processors use the pretty ancient X299 chipset, which is lacking several modern features. What is really bad for Intel is that their new “flagship” Core i9-10980XE HEDT processor is beaten by the new AMD Ryzen 9 3950X mainstream desktop processor in many benchmarks, even though it costs about $200 more. It is also completely dominated by the new, more expensive 7nm AMD Ryzen Threadripper 3960X and 3970X HEDT processors in most benchmarks.

Here are a few reviews:

Conclusion

In my mind, there are really not too many scenarios where these processors would be a good choice for a new machine build. They do not compare well to to the less expensive mainstream desktop Ryzen 9 processors for single-threaded or multi-threaded performance (or platform features). They also do not fare very well against the more expensive 3rd Generation AMD Threadripper processors for more serious content creation workloads.

I would argue that semi-serious content creators would be better off with a 12C/24T AMD Ryzen 9 3900X or a 16C/32T AMD Ryzen 9 3950X instead of any of these Cascade Lake-X processors. If you literally make your living off of content creation tasks, it is an easy decision to step up to a 3rd Generation AMD Threadripper system.

 

 

 

Posted in: Glenn's Technical Insights
Be the first to Reply!