Upgrading to SQL Server 2016

Many organizations are running older and possibly out of support versions of SQL Server, running on older versions of Windows Server, on old, slower, out of warranty hardware and storage.

SQL Server 2005 fell out of extended support on April 12, 2016. SQL Server 2008 and SQL Server 2008 R2 fell out of mainstream support on July 8, 2014, while SQL Server 2012 fell out of mainstream support on July 11, 2017. SQL Server 2012 Service Pack 4 is due to be released in September, so you should be planning on testing and deploying that when it becomes available.

Besides being out of support, these old versions of SQL Server are missing many very useful new features that can benefit your organization, and make your life as a DBA much easier. In my experience, you need to take the lead, and push your organization to start upgrading, making the business and technical case to justify the effort. I have done a lot of work and research to help you with this undertaking.

My latest Pluralsight course, SQL Server: Upgrading and Migrating to SQL Server 2016 has just been published. This is my eleventh course for Pluralsight, but the complete list of my courses is here. Speaking of Pluralsight courses, the team at SQLskills has 52 courses that we have developed and published. The complete list, along with guidance about what courses you should take depending on your interests and job role are here.

Building on this online course is a new three day class, IEUpgrade: Immersion Event on Upgrading SQL Server, taught by myself and Tim Radney. The first round of this course will be taught in Chicago from October 11-13, 2017.

In August, I will be doing a daily blog series about upgrading to SQL Server 2016/2017. Finally, I will be presenting a half-day session called Migrating to SQL Server 2017 at the PASS Summit 2017 in Seattle, WA from October 31- November 3, 2017.

CPU-Z 1.80 is Available

CPU-Z 1.80 was released on July 10, 2017. It adds support for the new Intel Skylake-X and Kabylake-X high-end desktop processors (HEDT). It also adds information about your preferred core(s) in the Clocks dialog on the About tab.

In case you are wondering what that means, some of the latest Intel processors have a new feature called Intel Turbo Boost Max Technology 3.0 that can automatically direct single-threaded workloads to the fastest core available on a processor. It requires a supported processor, BIOS support, and a special Intel driver, along with operating system support.

One processor that has this feature is the Intel Core i9-7900X processor.

image

Figure 1: CPU Tab of CPU-Z 1.80

 

If you want to investigate whether you have this feature and what it is doing, you can click on the Clocks button on the About tab, and see the preferred core information for your processor.

image

Figure 2: About Tab of CPU-Z 1.80

 

image

Figure 3: Clocks Dialog

My old Core i7-3770K processor does NOT have this new feature!

SQLskills SQL101: Creating SQL Server Databases

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all 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.

One seemingly simple task that I very often see being done in a less than optimal way is creating a new database in SQL Server. Whether it is done with the SQL Server Management Studio (SSMS) GUI, or with a T-SQL CREATE DATABASE command, many people and organizations are creating new SQL Server databases without really thinking about what they are doing, and without taking advantage of a number of beneficial options and properties.

A SQL Server database requires one data file in the PRIMARY file group and one transaction log file. A very high percentage of SQL Server databases that I see in the wild only have these two required files, which can be problematic for a number of reasons related to both manageability and performance.

You should get in the habit of creating a new file group called MAIN, that is the default file group, that contains two or more data files that are the same size, with the same auto growth increment. If you do this, only the system objects will be in the required data file in the PRIMARY file group, while all of your user objects will be in the other data files in the MAIN file group. This will let you locate your data files across multiple LUNs (either now or in the future), which will make them easier to manage and potentially give you better I/O performance (if those LUNs actually map to separate underlying storage).

When you create a new SQL Server database, it inherits most of its properties from the model system database (unless you explicitly override those properties with ALTER DATABASE commands). By default, SQL Server creates the files for the database in the default location that was specified when SQL Server was installed, unless someone has changed those default locations using the Server Properties: Database Settings dialog shown in Figure 1.

If you do change these database default locations, you should make 100% sure that the new locations actually exist in your file system (since SQL Server does not validate them when you change them). If you change them to a non-existent location, and later try to install a SQL Server Service Pack or Cumulative Update, the Database Engine portion of the installation will fail at the end of the setup process, which could be an unpleasant surprise!

image

Figure 1: Server Properties: Database Settings Dialog

Another way to change the location and properties of your database files is by explicitly specifying what you want when you create the database, or afterwards, with an ALTER DATABASE command.

If you use the SSMS GUI to create a new database as shown in Figure 2, it only requires that you enter a name for the database, and then click the OK button. Even though this will work, it is not really the best method to create a new database. Instead, you should take the time to think about what you are doing and then change a few properties and settings from their default values.

image

Figure 2: New Database: General Dialog with default values

The first thing you should change is the Owner of the database. You should change it from <default> to sa, to ensure that your login is not the owner of the database. Next, you should change the initial size of the files to a more appropriate, larger value. You should also change the Autogrowth increment size for the files to a more appropriate, larger value that is a fixed size in megabytes rather than a percentage-based value. Finally, you may want to change the location where your initial database files will be located.  Your dialog should look something like what you see in Figure 3. After all of this, don’t click OK, because you are not done yet.

 

image

Figure 3: New Database: General Dialog with modified values

Next, you should go to the Options page, as shown in Figure 4, and think about whether you want to change any of your initial database property settings. For example, you might want to change the recovery model, the compatibility level, or possibly other settings depending on your workload or SLA requirements. The point here is to carefully consider your choices and make an explicit choice rather than just blindly accepting all of the default properties

 

image

Figure 4: New Database: Options Dialog with default values

 

Next, we want to go to the Filegroups page, and make some changes. You should add a MAIN file group, and make it the default file group, as you see in Figure 5.

image

Figure 5: New Database: Filegroups Dialog with modified values

The next step is to go back to the General page and add some data files to this new MAIN file group. In Figure 6, I have added two new data files to the MAIN file group, setting their properties to appropriate values. If desired, I could change their locations in the file system. After all of this work, do not click on the OK button! Instead, use the Script dropdown to select “Script Action to New Query Window”, so you can review, edit, and save your database creation T-SQL script.

 

image

Figure 6: New Database: General Dialog with final values

As appropriate for a SQL101-level post, this covers the basic options you should consider when creating a database, as opposed to just typing a database name and clicking OK. If you take the time to do this when you first create the database, you will have a lot more flexibility in the future as your database gets larger.

SQL Server Diagnostic Information Queries for July 2017

This month, there are more minor updates to the all of the versions of the queries. I usually make additional 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 1SQL 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!

SQL101: AMD EYPC 7000 Series Processors

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all 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.

On June 20, 2017, AMD officially unveiled its new EPYC 7000 Series processor line for one and two-socket servers. These 14nm processors are based on the same Zen architecture as the recent AMD Ryzen desktop processors, with competitive single-threaded performance, along with very high core counts, memory density, and PCIe 3.0 lane counts.

These processors are a system on a chip (SoC) that includes CPU, memory controller, I/O controller and Server Controller Hub, so that no separate chipset is required. They have up to 32 physical cores per SoC, along with Simultaneous Multithreading (SMT), so you get 64 logical cores per SoC. You also get eight memory channels per socket, which means 16 DDR4 DIMMs per socket. This lets you have up to 2TB of RAM in a one-socket server, and 4TB of RAM in a two-socket server (with 128GB DIMMs). More realistically, you can easily and affordably have 512GB of RAM in a single-socket server with 32GB DIMMs.

You also get 128 PCIe 3.0 lanes per socket, which gives you a lot of total I/O capability. One very nice feature of these processors is that AMD does not cripple the lower-end SKUs when it comes to SMT, memory channels or PCIe 3.0 lanes, which is a big, welcome difference from how Intel does things with their product differentiation.

Another difference from Intel (which I actually don’t like) is that AMD does not have higher base clock speeds in their lower core count SKUs, so the existing strategy to reduce your SQL Server core license costs and also get better single-threaded performance by picking “frequency-optimized” low core count (LCC) processors, such as the Intel Xeon E5-2667 v4 is not going to work the same way.

What you can and should do, is to pick the fastest AMD EPYC SKU available at a given physical core count. For example, there are three EPYC 7000 SKUs that have 32 physical cores, the EPYC 7501, the EPYC 7551, and the EPYC 7601. Since the SQL Server core license cost will be the same, you should pick the EPYC 7601, to get the most performance possible for your license dollars.

Another important caveat is for SQL Server Standard Edition users. SQL Server 2016 Standard Edition has a license limit of four sockets or 24 physical cores, whichever is lower. This means that you need to be very careful what processor you choose for SQL Server 2016 Standard Edition. You basically have five choices to avoid exceeding these license limits.

You can get a 24-core EPYC 7401P, or a 16-core EPYC 7351P for a single-socket server. The 32-core EPYC 7551P would exceed your Standard Edition license limit. In a two-socket server, you can choose an eight-core EPYC 7251, and populate either one or two sockets. You can also choose a 16-core EPYC 7351 or a 24-core EPYC 7451 and just populate one socket of a two-socket server.

If you buy a new database server that has more than 24 physical cores, SQL Server 2016 Standard Edition will only use 24 physical cores per instance, but Microsoft will still expect you to pay for a core license for every physical core present in the machine. This could be a very expensive mistake. In a worst case scenario, you buy a two-socket server with two of the 32-core EPYC 7601 processor, and end up having to pay about $72K in extra license costs for cores that you are not allowed to use in a single instance.

Microsoft has not formally announced any change in these license limits for SQL Server 2017 Standard Edition, but hopefully they will raise these license limits to a more realistic value for modern processors from AMD (and for the upcoming Intel Skylake-SP processors).

SQL Server Diagnostic Information Queries for June 2017

This month, there are some minor updates to the all of the versions of the queries. I usually make additional 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 1SQL 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!

SQLskills SQL101: SQL Server Core Factor Table

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.

Guidance for WannaCrypt/WannaCry Attacks

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

SQL Server Diagnostic Information Queries for May 2017

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 1SQL 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!

SQLskills SQL101: Sequential Throughput

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.

The Importance of Sequential Throughput for SQL Server

A number of very common, important operations that are often executed by SQL Server are potentially performance limited by the sequential throughput of the underlying storage subsystem. These include:

  1. Full database backups and restores
  2. Index creation and maintenance work
  3. Initializing transactional replication snapshots and subscriptions
  4. Initializing AlwaysOn AG replicas
  5. Initializing database mirrors
  6. Initializing log-shipping secondary’s
  7. Running DBCC CHECKDB
  8. Relational data warehouse query workloads
  9. Relational data warehouse ETL operations

Despite this, I often see DBAs having to contend with extremely low sequential performance on their various database servers, to the detriment of their ability to meet their SLAs for things like RPO and RTO (not to mention their sanity). This being the case, what if anything can you do to improve this situation?

One thing you should do is to do some storage subsystem benchmarking with tools like CrystalDiskMark and Microsoft DiskSpd, to find out what the potential performance of each logical drive is on the underlying machine where your SQL Server instance is running.

You can also run some simple queries and tests from SQL Server itself to see what level of sequential performance you are actually getting from your storage subsystem (which is much harder for storage administrators, SAN administrators, and storage vendors to dispute). One example is running a full database backup to a NUL device, to see the ultimate sequential read performance from where your data and log files are located. Another example is running a SELECT query with an index hint to force the query to do a clustered index scan or table scan from a relatively large table.

Note: You should do these kinds of tests during a maintenance window or ideally, before a new instance of SQL Server goes into Production. Otherwise, your testing could negatively affect your Production environment or the other Production activity could skew your test results.

Beyond that, here are some general steps you can take to improve overall storage system performance:

  1. Make sure you have power management configured correctly at all levels (BIOS power management, hypervisor power policy, and Windows Power Plan)
  2. Make sure you have Windows Instant File Initialization enabled
  3. Make sure you are not under memory pressure (to reduce stress on your storage subsystem)
  4. Make sure you are using the latest version of SQL Server
  5. Make sure you have installed the latest Service Pack and Cumulative Update for your version of SQL Server
  6. Favor Enterprise Edition or Standard Edition (because it has better I/O performance)
  7. Use compression to reduce your I/O requirements (backup compression, data compression, and columnstore indexes
  8. Make sure your indexes are tuned appropriately (not too many and not too few)
  9. Keep your index fragmentation under control

You can watch my Pluralsight course SQL Server: Improving Storage Subsystem Performance to get more details about this subject. You can also read my article on SQLPerformance.com, Sequential Throughput Speeds and Feeds to get some more technical details about sequential throughput.