SQLskills SQL101: SQL Server Core Factor Table

By: Glenn Berry
Posted on: May 26, 2017 1:18 pm

Over the past couple of months, SQLskills has embarked on a new initiative to blog about basic topics, which we’re calling SQL101. We’ll all be blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

Back in the SQL Server 2012 release time-frame, Microsoft published a SQL Server Core Factor Table document that essentially provided a 25% discount for most AMD Opteron processors with six or more physical cores. This document was updated for the SQL Server 2014 release.

Even with this discount, it was not really cost-effective to use AMD Opteron processors for SQL Server usage, because of their extremely poor single-threaded performance. You could easily get more total capacity, better single-threaded performance, and lower SQL Server licensing costs with an appropriate, modern Intel Xeon E5 or E7 processor.

For the SQL Server 2016 release, there was no update for the SQL Server Core Factor Table. In fact, Microsoft has a useful new document, entitled “Introduction to Per Core Licensing and Basic Definitions” where they explicitly state that the Core Factor Table is not applicable to SQL Server starting with SQL Server 2016. So far, there has been no word of any change in this stance for SQL Server 2017.

Despite this, there is still some confusion and misinformation about the SQL Server Core Factor Table, such as this example:

Using the Core Factor Table

The SQL Server Core Factor Table is not necessary for SQL Server 2008 R2 (which used processor licensing instead of core licensing), and it does not apply to SQL Server 2016 and newer. It is only valid for SQL Server 2012 and SQL Server 2014.

It will be interesting to see whether the upcoming AMD Epyc “Naples” server processors will perform well with SQL Server workloads. They certainly will have enough memory density and PCIe 3.0 lanes to be very interesting for some types of SQL Server workloads, such as DW/Reporting. AMD is also pitching the idea that a single-socket server using an AMD Epyc processor will be a good alternative to a two-socket Intel server.

Posted in: AMD, Hardware, SQL101
Be the first to Reply!

Guidance for WannaCrypt/WannaCry Attacks

By: Glenn Berry
Posted on: May 16, 2017 10:48 am

There has been quite a bit of media coverage about the WannaCrypt/WannaCry ransomware over the past several days. Microsoft has a new page with information about this particular issue and steps that can be taken to protect your systems. I have also collected some more detailed background information about this and about SQL Server security patching in general.

Just to be clear, there is no known threat to SQL Server from this method, but there was an out of band security update for SQL Server 2012, 2014, and 2016 that was released on November 8, 2016. Here are the most current cumulative updates for SQL Server 2012, 2014, and 2016 (which will include that security update).

SQL Server 2012              SQL Server 2012 SP3 CU9            11.0.6598.0                      May 15, 2017

SQL Server 2014              SQL Server 2014 SP2 CU5            12.0.5546.0                      April 17, 2017

SQL Server 2016              SQL Server 2016 SP1 CU3            13.0.4435.0                      May 15, 2017

 

WannaCrypt/WannaCry Information

Here are some links to useful resources about this outbreak. Making sure your servers and client machines are current with their Microsoft Update hotfixes and possibly disabling SMB v1 are the best defenses.

Alert (TA17-132A) Indicators Associated With WannaCry Ransomware

Microsoft Security Bulletin MS17-010 – Critical

MS17-010: Description of the security update for Windows SMB Server: March 14, 2017

Windows Update Catalog Download Links

 

SMB v1 Information

Another mitigation measure for this vulnerability is to disable Server Message Block (SMB) v1 (which has been deprecated since Windows Server 2012). Depending on what version of Windows Server you are running, you may be able to do this using various methods.

The Deprecation of SMB1 – You should be planning to get rid of this old SMB dialect

Stop using SMB1

How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server

 

SQL Server Security Update Information

Microsoft now recommends proactively installing SQL Server Cumulative Updates as they become available. The most recent, specific security update (MS16-136) for SQL Server 2012, 2014, and 2016 was released on November 8, 2016. If you are up to date with your SQL Server Service Packs and Cumulative Updates, you will already have that SQL Server security update. Just to be clear, there is no indication that SQL Server is vulnerable to WannaCry. It is merely a best practice to stay current with SQL Server security and other updates.

Announcing updates to the SQL Server Incremental Servicing Model (ISM)

Where to find information about the latest SQL Server builds

MS16-136: Security update for SQL Server: November 8, 2016

 

Finally, there are a number of other good reasons to make an effort to keep your SQL Server instances up to date with the latest Service Pack and Cumulative Update. I highlight some of the more important hotfixes for every cumulative update in the blog posts linked below:

Performance and Stability Related Fixes in Post-SQL Server 2012 SP3 Builds

Performance and Stability Related Fixes in Post-SQL Server 2014 SP1 Builds

Performance and Stability Related Fixes in Post-SQL Server 2014 SP2 Builds

Performance and Stability Related Fixes in Post-SQL Server 2016 SP1 Builds

Posted in: Cumulative Updates, Security, SQL Server 2012, SQL Server 2014, SQL Server 2016
3 Comments

SQL Server Diagnostic Information Queries for May 2017

By: Glenn Berry
Posted on: May 1, 2017 10:19 am

This month, there are two new queries for SQL Server 2017, along with more minor updates for several of the SQL Server 2012 and newer version queries. I have also made some minor updates to the SQL Server 2005, 20087, and 2008 R2 queries. I usually make minor updates to the queries 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 seven 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 Server 2017, 2016, 2014 and 2012:

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 Diagnostic Information Queries

SQL Server 2016 Blank Results Spreadsheet

SQL Server 2014 Diagnostic Information Queries

SQL Server 2014 Blank Results Spreadsheet

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

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

Since SQL Server 2008 R2 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.  I started this policy a while ago, and so far, I have not heard any complaints. I did update these queries slightly in January 2017 though.

SQL Server 2008 R2 Diagnostic Information Queries (CY 2017)

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries (CY 2017)

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries (CY 2017)

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 three related Pluralsight courses, which are 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 three of these courses are pretty short and to the point, at 67, 77, and 68 minutes respectively. Listening to these three 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, SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017
6 Comments