Initial CrystalDiskMark Results for Intel Optane 900p

I have been building a new desktop workstation based on an AMD Ryzen Threadripper 1950X processor (which I will be describing in much more detail in a subsequent blog post). I am planning on using one of the brand new 480GB Intel Optane SSD 900p PCIe cards as my boot drive. Initially, I installed Windows 10 Professional, Version 1709 on a pretty lackluster OEM 256GB Toshiba M.2 NVMe drive that I had lying around. My plan is to clone that drive to the Intel Optane 900p.

I also have a couple of 1TB Samsung 960 PRO M.2 NVMe cards in this machine, so I thought I would run a couple of quick CrystalDiskMark tests on the two drives. One thing to keep in mind is that CrystalDiskMark is not the best synthetic benchmark to use to show off the strengths of the Optane 900p.

Traditional NAND-based SSDs excel at very high queue depths that are not usually encountered outside of synthetic benchmarks (especially for random read performance). Optane 900p SSDs perform extremely well for random reads at low queue depths. This gives you outstanding responsiveness and performance where it is going to be most noticeable in daily usage.

You can see part of this effect in the bottom row of CDM test results for reads, where the Optane 900p is doing about 4.3X more 4K IOPS than the Samsung 960 PRO at a queue depth of 1. A better test for this will be Microsoft DiskSpd, which can also measure the latency during the test run.

Here are some of the primary advantages of the Intel Optane 900p compared to current NAND flash storage.

 

    • High random read and write performance
    • High performance at low queue depths
    • High simultaneous read and write performance
    • High read and write performance at small capacity points
    • High performance maintained as the drive fills with data
    • Higher endurance than current NAND technology

 

image

Figure 1: 1TB Samsung 960 PRO with Samsung NVMe driver

 

image

Figure 2: 480GB Intel Optane 900p with Intel NVMe driver

 

SQL Server Diagnostic Information Queries for November 2017

This month, there are more minor updates to the all of the versions of the queries, primarily in the comments and documentation. 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 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 Azure SQL Database, SQL Server 2017, 2016, 2014 and 2012:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

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 have made some updates to these queries periodically since January.

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

Presenting Two Sessions at the PASS Summit 2017 in Seattle

I’ll be presenting two sessions at the PASS Summit 2017 in Seattle, WA. There will be a half-day session called Migrating to SQL Server 2017 on Wednesday, November 1 in Room 6A, starting at 3:15PM, and then a regular session called Improving SQL Server Performance on Thursday, November 2 in Room 612, starting at 4:45PM.

Here are the abstracts:

Migrating to SQL Server 2017

How do you design and implement a safe and successful migration from an older version of SQL Server to SQL Server 2017 with no data loss and virtually no downtime? What if you have a limited hardware budget for the upgrade effort and you are worried about the core-based licensing in SQL Server 2017? How can you choose your hardware wisely in light of the new licensing model? How can you convince your organization that the time is right to upgrade to SQL Server 2017? This session will cover several different methods for migrating your data to SQL Server 2017 while meeting these objectives and minimizing your hardware and licensing costs. You will also learn how to help make the case that a complete data platform upgrade makes excellent sense from a business perspective. You will also learn how to do effective capacity planning for the new environment to ensure that you have the best performance possible with a manageable SQL Server 2017 licensing cost.

 

Improving SQL Server Performance

Has anyone ever told you that your SQL Server database or instance was running too fast? Probably not, but it is all too common to hear complaints about poor performance. As a database professional, you need to have the right tools and techniques for finding and correcting performance bottlenecks at all layers of your SQL Server instance. Starting with your hardware and storage, including virtualization, operating system considerations, instance-level configuration settings, database properties, and concluding with index and query tuning, we will cover all of the layers of common performance bottlenecks. You will learn detailed and practical information for improving SQL Server performance at every layer in the system.

 

My SQLskills colleague, Erin Stellato will also be at the PASS Summit 2017, presenting a pre-conference session called Solving Common Performance Problems Using Query Store on Monday, October 30, and then two regular sessions: Query Store and Automatic Tuning in SQL Server and Data Systems at Scale – A Panel Discussion on November 1 and November 2, respectively.

 

The PASS Summit is always a fun and useful conference, where you can connect and reconnect to people in the SQL Server Community. I hope to see you there, in my sessions and in the hallways and escalators!

Update: Just to make it easier to find, here are links to my Migrating to SQL Server 2017 session, Migrating to SQL Server 2017 demos, Improving SQL Server Performance session, and Improving SQL Server Performance demos.

 

 

 

SQL Server 2017 CU1 is Available

On October 24, 2017, Microsoft released SQL Server 2017 Cumulative Update 1, which is Build 14.0.3006.16. This CU has 68 hot fixes by my count, which is a fairly high count. This shows that Microsoft has been busy fixing issues that have shown up since the RTM build. I think this is a good thing.

Keep in mind that Microsoft has revised their servicing model for SQL Server 2017, with what they are calling the Modern Servicing Model for SQL Server, as I discussed here.

The gist of this new servicing model is that there will be no Service Packs for SQL Server 2017. Cumulative Updates will be released every month for the first year after GA, on the 3rd Tuesday of each month. After that, they will be released every three months, for the next four years, until SQL Server 2017 falls out of Mainstream support on October 11, 2022.

This means that hot fixes will be available more quickly during the first year, when most of the issues are discovered and corrected. You don’t have to install every single CU when it is released, but you should make a habit of looking at the fix list for each CU, to see if anything that might be affecting you is included. Once you do install the latest CU (which Microsoft recommends you do proactively), you will have all of the hotfixes since RTM, since they are actually cumulative in nature, as the name suggests.

 

 

Windows Server Servicing Model Changes

Microsoft has announced some changes to the release schedule and servicing model for Windows Server. The new Semi-Annual Channel is a twice-per-year feature update release with an 18 month servicing timeline (meaning that Mainstream support ends 18 months after that Semi-Annual Channel release becomes available).

The current release in this channel is Windows Server, version 1709, which became available on October 17, 2017. This release will fall out of Mainstream support on April 18, 2019, and there is no Extended support period. In this new model, Windows Server releases are identified by the year and month of release: for example, in 2017, a release in the 9th month (September) would be identified as version 1709.

Microsoft describes the Semi-Annual Channel below:

“The Semi-Annual Channel provides opportunity for customers who are innovating quickly to take advantage of new operating system capabilities at a faster pace, both in applications – particularly those built on containers and microservices – and in the software-defined hybrid datacenter.”

You also have the option of staying on the Windows Server 2016 Long-Term Servicing Channel (LTSC) with the traditional five years of Mainstream support, five years of Extended support, and the option to purchase Premium Assurance, for six more years of support. The current release in this channel is Windows Server 2016, version 2016 which became available on October 12, 2016. This release will fall out of Mainstream support on January 11, 2022, and it will fall out of Extended support on January 11, 2027. The LTSC is scheduled to have new releases every two to three years.

The Semi-Annual Channel will be available to volume-licensed customers with Software Assurance, as well as via the Azure Marketplace or other cloud/hosting service providers and loyalty programs such as Visual Studio Subscriptions.

The Semi-Annual Channel can be installed as a Nano Server or Server Core, but is not available as Server with Desktop Experience. The Long-Term Servicing Channel can be installed as a Server with Desktop Experience or Server Core, but is not available as Nano Server.

 

Implications for SQL Server Usage

If you want to use the Semi-Annual Channel, you will have to be comfortable running SQL Server on Server Core (with no integrated GUI). You can either start using Powershell or you can use tools like Project Honolulu, which is a locally deployed, browser-based, management tool set that enables on-premises administration of Windows Servers with no Azure or cloud dependency.

The two most interesting new features for SQL Server in Windows Server, version 1709 are Storage-Class memory support for Hyper-V VMs and Virtualized Persistent Memory (vPMEM) for Hyper-V VMs.

Storage-class memory support for VMs enables NTFS-formatted direct access volumes to be created on non-volatile DIMMs and exposed to Hyper-V VMs. This enables Hyper-V VMs to leverage the low-latency performance benefits of storage-class memory devices. Virtualized Persistent Memory (vPMEM) is enabled by creating a VHD file (.vhdpmem) on a direct access volume on a host, adding a vPMEM Controller to a VM, and adding the created device (.vhdpmem) to a VM. Using vhdpmem files on direct access volumes on a host to back vPMEM enables allocation flexibility and leverages a familiar management model for adding disks to VMs.+

Virtualized Persistent Memory (vPMEM) is enabled by creating a VHD file (.vhdpmem) on a direct access volume on a host, adding a vPMEM Controller to a VM, and adding the created device (.vhdpmem) to a VM. Using vhdpmem files on direct access volumes on a host to back vPMEM enables allocation flexibility and leverages a familiar management model for adding disks to VMs.

Using Storage-class memory in a VM will let you use the Persisted Log Buffer feature (aka “tail of the log caching”) that was introduced in SQL Server 2016 SP1, as described here.

 

 

 

SQL Server Diagnostic Information Queries for October 2017

This month, I have added a set of diagnostic queries for Azure SQL Database. These are very much a work in progress, and they will be changing (and hopefully improving) quite a bit over the next few months

There are more minor updates to the all of the versions of the queries, primarily in the comments and documentation. 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 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 Azure SQL Database, SQL Server 2017, 2016, 2014 and 2012:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

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 have made some updates to these queries periodically since January.

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

 

 

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

Modern SQL Server Servicing Model

Microsoft has announced a pretty big change for how they are going to service SQL Server, starting with SQL Server 2017. I am very much in favor of the changes in this new model.

 

Background

Historically, Microsoft has used a combination of General Distribution Releases (GDRs), Cumulative Updates (CUs), and Service Packs (SPs) to update major SQL Server releases (which Microsoft refers to as servicing SQL Server). When a new major version of SQL Server reaches the general availability (GA) milestone, the servicing sequence for the original RTM branch begins. Typically, CUs are released every eight weeks, and they are a rollup of hotfixes and minor new features or feature improvements. GDRs only contain security hotfixes, and they are meant for organizations who want less software churn from SQL Server

Roughly a year after GA, Microsoft would release SP1 for that version of SQL Server. Organizations had the choice of staying on the RTM branch (which would continue to get CUs for about another year) or moving to the newer SP1 branch of the product (which would get its own CUs every eight weeks, and GDRs as needed). Roughly two years after GA, Microsoft would release SP2 for that version of SQL Server, which would start a new servicing branch with GDRs and CUs. The release of SP2 would halt the servicing of the RTM branch, which would then become an “unsupported SP”.

This has been the pattern since SQL Server 2005, so organizations should be pretty familiar with this old model.

 

Modern Servicing Model

The new servicing model will only use CUs and GDRs, there will be no more SPs. CUs will now have localized content (which was a big differentiator between CUs and SPs in the past). There will be a CU released every month for the first twelve months after GA, then changing to a new CU release every quarter for the next four years. New CUs will be delivered the week of the 3rd Tuesday of the month where they are released. About every twelve months, a slipstream-media CU will be released, which will let you install something like SQL Server 2017 with CU12 in one install instead of having to install SQL Server 2017 GA and then doing a separate install of SQL Server 2017 CU12.

Organizations will have to choose whether they will be on the “GDR Train” or the “CU Train”. If they are on the GDR Train and decide to install a CU, there is no going back to the GDR Train. Personally, I think it will be much better for most organizations to be on the CU Train, so that they get the benefit of hotfixes and feature improvements that will show up in CUs. Microsoft also advises organizations to proactively deploy CUs after they become available (after suitable internal testing).

You will need to be on a CU that is less than roughly 24 months old to be in a fully supported state from Microsoft (which is pretty similar to the current support window). Five years after GA, CU servicing will end as that version of SQL Server falls out of mainstream support, with only security fixes being available for the next five years, until that version of SQL Server falls out of extended support.

 

Premium Assurance 

After that, you can extend support for six more years with SQL Server Premium Assurance. Premium Assurance is somewhat pricey, with a sliding price scale that increases depending on when you purchase it. For SQL Server Enterprise Edition, it would currently cost $394.00 per core license, going up to $675.00 per core license if you purchased it after July 2019. Premium Assurance is available for SQL Server 2008 and later.

In most cases, I would much rather have moved to a newer version of SQL Server long before I ever had to think about using Premium Assurance, but for those situations where you have a mission critical legacy application that requires an ancient version of SQL Server, it is nice to at least have the option for a longer support period.

Microsoft’s official announcement about this change is covered in even more depth here.

 

SQLskills SQL101: Azure SQL Database Monitoring

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.

If you are ready to start working with Azure SQL Database, which is Microsoft’s Platform as a Service (PaaS) offering for SQL Server, you will want some good diagnostic queries to use to help you better understand how your databases are performing and to give you more information than is exposed by the Azure Portal. After much delay and procrastination on my part, I have finally developed a version of my SQL Server Diagnostic Information Queries that are tailored for use with Azure SQL Database.

Azure SQL Database Diagnostic Information Queries

Azure SQL Database 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.

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

SQL Server Diagnostic Information Queries for September 2017

On September 1, 2017, Dropbox turned off the sharing feature that I was previously using to host these scripts, which broke hundreds of existing links on my blog. I will be switching to their new sharing method, at least temporarily, until I decide what to do.

This month, there are more minor updates to the all of the versions of the queries, primarily in the comments and documentation. 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 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 have made some updates to these queries periodically since January.

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

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

Upgrading SQL Server– Intel Xeon-W Family

On August 30, 2017, Intel released their new Intel Xeon Processor W Family of one-socket workstation processors (hence the W) based on the Skylake-SP Xeon server processors. These processors are meant as a replacement for the older one-socket Intel Xeon E5-1600 v4 series that had up to eight physical cores. The Xeon-W processors will have between four and eighteen physical cores, support up to 512GB of RAM and have 48 PCIe 3.0 lanes.

These processors are essentially Xeon versions of the Skylake-X Core i9 HEDT processors with all of the professional features enabled such as extended memory support, vPro, Intel’s AMT, and the standard enterprise Reliability, Serviceability and Availability (RAS) features. They will require a new C422 chipset, and they will not work in existing X299 chipset motherboards.

These processors give you another possible choice for buying or building a powerful, professional level workstation. Value-wise, a system based on one of the AMD Ryzen Threadripper processors is going to be a much better option for most people. Anandtech is a decent write-up here.

 

Additional Resources

My new 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.

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.

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. You can use this code: BL150GG to register for the PASS 2017 Summit to get a $150 discount.

Here is a link to the complete series about upgrading SQL Server.