The post SQL Server 2019 Standard Edition Licensing appeared first on Glenn Berry.
]]>SQL Server 2017 Standard Edition License Limits
SQL Server 2017 Standard Edition has a 128GB limit (per instance) for the Database Engine, plus an additional 32GB per database for in-memory OLTP, and an additional 32GB per instance for Columnstore index usage. These license limits were the same for SQL Server 2016 with Service Pack 1.
SQL Server 2017 Standard Edition is also limited to the lesser of four sockets or 24 physical cores on non-virtualized instances. On virtualized instances, it is limited to the lesser of four sockets or 24 virtual cores (which may map to logical or physical cores).
SQL Server Standard Edition Licensing History
These Standard Edition license limits have slowly risen over the years. SQL Server 2008 Standard Edition was limited to four sockets, but could use the operating system limit for RAM. SQL Server 2008 was still using processor licensing, so there were no core-based license limits. SQL Server 2008 R2 Standard Edition was also limited to four sockets, but was limited to 64GB of RAM (per instance). SQL Server 2008 R2 still used processor licensing, so there were no core-based license limits.
SQL Server 2012 Standard Edition was limited to 64GB of RAM (per instance). It was also limited to the lesser of four sockets or 16 physical cores. Microsoft raised memory limit for SQL Server 2014. SQL Server 2014 Standard Edition was limited to 128GB of RAM (per instance). It was still limited to the lesser of four sockets or 16 physical cores.
Microsoft raised the core limit for SQL Server 2016. SQL Server 2016 RTM Standard Edition was still limited to 128GB of RAM (per instance). It was limited to the lesser of four sockets or 24 physical cores. There were no license limit increases for SQL Server 2017 Standard Edition. This means we haven’t had a license limit increase for SQL Server Standard Edition since June 2016.
Recent Hardware Advances
In June 2016, Intel Broadwell processors had a maximum of 24 physical cores, which meant that you could hit the SQL Server 2016 core license limit on one socket. It was also very easy to exceed the SQL Server 2016 core license limit with many, lower core count SKUs on a two-socket server. This was a more common scenario.
In May 2019, we now have Intel Cascade Lake-SP processors that have a maximum of 28 physical cores. We will soon have AMD EPYC “Rome” processors that have a maximum of 64 physical cores. These hardware advances mean that there is a good argument that the core license limit should be increased to a higher number. If Microsoft increased the core limit to 64, you would be able to use a two-socket server with two flagship Intel 28-core processors. You would also be able to use a one-socket server with one flagship 64-core AMD EPYC “Rome” processor.
I also believe that the per instance memory limit should raised to a higher value. My suggestion would be to go to 256GB, which would double the current limit. Server-class DDR4 memory prices have gone down to about $7.00/GB for 32GB DIMMs, so it is feasible and affordable to purchase more RAM than people might have used in the past.
SQL Server 2019 Enterprise Edition Value Proposition
The obvious argument for why Microsoft should NOT raise these hardware license limits is that it might cause more people to use SQL Server 2019 Standard Edition rather than SQL Server 2019 Enterprise Edition, which would reduce Microsoft’s revenues. I think this change would actually encourage more people to finally upgrade from legacy versions of SQL Server Standard Edition to SQL Server 2019 Standard Edition. Being able to use higher core count processors and more memory would be an attractive combination which would increase revenues from SQL Server 2019 Standard Edition.
Microsoft could (and really should) do a better job of demonstrating the value of SQL Server 2019 Enterprise Edition for performance, scalability, and useful Enterprise-only features. They could use KB articles, whitepapers, and blog posts to discuss the low level optimizations that are already in Enterprise Edition but not in Standard Edition. Putting all of this information together would be extremely valuable.
For example, running a common benchmark like DBHammer on SQL Server 2019 Standard Edition, and then doing an Edition Upgrade and re-running the benchmark on the exact same system would be a pretty simple way to confirm performance increases. This could be extended by making easy configuration or database/code changes to fully leverage Enterprise Edition and rerunning the benchmark.
Doing a good job of explaining the value of Enterprise Edition would protect Enterprise Edition sales, and actually encourage more people to do Edition upgrades. I have done some work in this area, such as this article:
SQL Server 2016 Enterprise Edition Performance Advantages
Conclusion
I don’t have any illusions that Microsoft will just do what I say here. I really do hope they raise these license limits for SQL Server 2019 in order to help create an even more compelling upgrade story. What do you think? Is 128GB of RAM and 24 cores enough?
The post SQL Server 2019 Standard Edition Licensing appeared first on Glenn Berry.
]]>The post Avoiding SQL Server Upgrade Performance Issues appeared first on Glenn Berry.
]]>When you upgrade to a modern version of SQL Server, there are some critical things you should do to help avoid any SQL Server performance issues.
SQL Server 2008 and SQL Server 2008 R2 are rapidly approaching the end of Extended support from Microsoft on July 9, 2019. SQL Server 2014 is also falling out of Mainstream support on July 9, 2019. SQL Server 2012 fell out of Mainstream support on July 11, 2017. Because of this, I am seeing an increasing number of organizations that have been migrating to a modern version of SQL Server. I define a modern version of SQL Server as SQL Server 2016 or later.
I see this as a positive development overall, since SQL Server 2016 and newer actually have many useful new features that make them much better products than their predecessors. Migrating to a modern version of SQL Server also usually means using new, faster hardware and storage, running on a current version of Windows Server, which is also very beneficial, as long as you choose your new hardware and storage wisely.
SQL Server Upgrade Performance Issues
Despite all of this, I have seen a decent number of cases where organizations have migrated from a legacy version of SQL Server to a modern version of SQL Server on new hardware and a new operating system, and then be unpleasantly surprised by SQL Server performance issues once they are in Production. How can these performance regressions be occurring, and what steps can you take to help prevent them?
The main culprit in most of these performance regressions is a combination of lack of knowledge, planning, and adequate performance testing. Unlike legacy versions of SQL Server, modern versions of SQL Server have several important performance-related configuration options that you need to be aware of, understand, and actually test with your workload. Most people who run into performance regressions have done what I call a “blind migration” where they simply restore their databases from the older version to the new version of SQL Server, with no meaningful testing of the performance effects of these different configuration options.
Key Configuration Options
So, what are these key configuration options that you need to be concerned with from a performance perspective? The most important ones include your database compatibility level, the cardinality estimator version that you are using, your database-scoped configuration options, and what trace flags you are using. Since SQL Server 2014, the database compatibility level affects the default cardinality estimator that the query optimizer will use. Since SQL Server 2016, the database compatibility level also controls other performance related behavior by default. I have written more about this subject here:
The Importance of Database Compatibility Level in SQL Server
You have the ability override many of these database compatibility level-related changes with database scoped configuration options and query hints. There are actually a rather large number of different combinations of settings that you have to think about and test. So, what are you supposed to do?
Microsoft Database Experimentation Assistant
In my ideal scenario, you would use the free Microsoft Database Experimentation Assistant (DEA) to capture a relevant production workload. This involves taking a full production database backup, then capturing a production trace that covers representative high priority workloads. While this is going on, I would run some of my SQL Server Diagnostic Queries to get some baseline metrics from your legacy instance.
Once you have done that, you can then restore that backup to your new environment, and replay the production trace multiple times in your new environment. Each time you do this (which also includes a fresh restore from that original full production database backup), you will use a different combination of these key configuration settings. You have to make the database configuration/property changes after each restore, but before you replay the DEA trace.
Configuration Combinations to Test
The idea here is to see which combination of these configuration settings yields the best performance with your workload. Here are some relevant, likely combinations:
-
- Use the default native database compatibility level of the new version
- Use the default native database compatibility level of the new version and use the query optimizer hotfixes database-scoped configuration option
- Use the default native database compatibility level of the new version and use the legacy cardinality estimator database-scoped configuration option
- Use the default native database compatibility level of the new version and use the legacy cardinality estimator database-scoped configuration option and use the query optimizer hotfixes database-scoped configuration option
- Use the existing database compatibility level of the old version
- Use the existing database compatibility level of the old version and use the query optimizer hotfixes database-scoped configuration option
This level of DEA testing may not be practical if you have a large number of databases, but you should really try to do it on your most mission critical databases. Barring that, I would try to do as much testing of your most important stored procedures and queries as possible, using these different configuration settings.
Microsoft’s Recommended Upgrade Sequence
Finally, if no adequate testing is possible you can follow Microsoft’s recommended upgrade sequence (in your new production environment, after you go live), which is:
-
- Upgrade to the latest SQL Server version and keep the source (legacy) database compatibility level
- Enable Query Store, and let it collect a baseline of your workload
- Change the database compatibility level to the native level for the new version of SQL Server
- Use Query Store (and Automatic Plan Correction on SQL Server 2017 Enterprise Edition) to fix performance regressions by forcing the last known good plan
You also have all of the other new “knobs” of database-scoped configuration options, query-level hints, and trace flags available to you. You may have to do some additional work on some queries with USE HINT query hints. Ideally, you would have done enough testing so that you already have a pretty good idea of the “best” combination of these settings for your workload, but many organizations don’t actually do that.
Keep in mind that for each of the new QP features over the last two versions (Adaptive Query Processing in SQL Server 2017 and Intelligent Query Processing in SQL Server 2019), Microsoft exposes the ability to disable specific behavior at the database scoped configuration or query USE HINT scope. Microsoft generally recommends that if you do find regressions related to a specific feature, try disabling it at lower granularities first, so you can still benefit from all of the rest of the improvements you get from the latest database compatibility level.
Query Tuning Assistant
Microsoft is shipping a new tool called Query Tuning Assistant (QTA) in SSMS 18.0. QTA can guide you through the recommended database compatibility level upgrade process in a wizard-fashion, collecting the baseline workload in Query Store, bumping up the database compatibility level, and then comparing performance with the post-upgrade workload collection. At the end of this process, if performance regressions are detected, rather than moving back to the previously known good plan, the QTA will actually suggest hint-based improvements that can be deployed for individual queries (using plan guides), without having to necessarily move back to the legacy CE. It will also gives you some ideas (indirectly) for how you can modify problematic queries that have CE-related regression issues, when you have that option.
The post Avoiding SQL Server Upgrade Performance Issues appeared first on Glenn Berry.
]]>The post The Importance of Database Compatibility Level in SQL Server appeared first on Glenn Berry.
]]>Prior to SQL Server 2014, the database compatibility level of your user databases was not typically an important property that you had to be concerned with, at least from a performance perspective. Unlike the database file level (which gets automatically upgraded when you restore or attach a down-level database to an instance running a newer version of SQL Server, and which can never go back to the lower level), the database compatibility level can be changed to any supported level with a simple ALTER DATABASE SET COMPATIBILITY LEVEL = xxx command.
You are not stuck at any particular supported database compatibility level, and you can change the compatibility level back to any supported level that you wish. In many cases, most user databases never had their compatibility levels changed after a migration to a new version of SQL Server. This usually didn’t cause any issues unless you actually needed a new feature that was enabled by the latest database compatibility level.
With SQL Server 2012 and older, the database compatibility level was mainly used to control whether new features introduced with a particular version of SQL Server were enabled or not and whether non-supported old features were disabled or not. The database compatibility level was also used as a method to maintain better backwards application compatibility with old versions of SQL Server. If you didn’t have time to do full regression testing with the newest compatibility level, you could just use the previous compatibility level until you could test and modify your applications if needed.
Table 1 shows the major versions of SQL Server and their default and supported database compatibility levels.
SQL Server Version Database Engine Version Default Compatibility Level Supported Compatibility Levels
SQL Server 2019 15 150 150, 140, 130, 120, 110, 100
SQL Server 2017 14 140 140, 130, 120, 110, 100
SQL Server 2016 13 130 130, 120, 110, 100
SQL Server 2014 12 120 120, 110, 100
SQL Server 2012 11 110 110, 100, 90
SQL Server 2008 R2 10.5 100 100, 90, 80
SQL Server 2008 10 100 100, 90, 80
SQL Server 2005 9 90 90, 80
SQL Server 2000 8 80 80
Table 1: SQL Server Versions and Supported Compatibility Levels
New Database Creation
When you create a new user database in SQL Server, the database compatibility level will be set to the default compatibility level for that version of SQL Server. So for example, a new user database that is created in SQL Server 2017 will have a database compatibility level of 140. The exception to this is if you have changed the compatibility level of the model system database to a different supported database compatibility level, then a new user database will inherit its database compatibility level from the model database.
Database Restore or Attach
If you restore a full database backup that was taken on an older version of SQL Server to an instance that is running a newer version of SQL Server, then the database compatibility level will stay the same as it was on the older version of SQL Server, unless the old database compatibility level is lower than the minimum supported database compatibility level for the newer version of SQL Server. In that case, the database compatibility level will be changed to the lowest supported version for the newer version of SQL Server.
For example, if you were to restore a SQL Server 2005 database backup to a SQL Server 2017 instance, the database compatibility level for that restored database would be changed to 100. You will get the same behavior if you detach a database from an older version of SQL Server, and then attach it to a newer version of SQL Server.
This general behavior is not new, but what is new and important is what else happens when you change a user database to database compatibility level 120 or newer. These additional changes, that can have a huge impact on performance, don’t seem to be widely known and understood in the wider SQL Server community. I still see many database professionals and their organizations just doing what I call “blind upgrades” where they go from SQL Server 2012 or older to SQL Server 2014 or newer (especially SQL Server 2016 and SQL Server 2017), where they don’t do any serious performance regression testing to understand how their workload will behave on the new native compatibility level and whether the additional configuration options that are available will have a positive effect or not.
Database Compatibility Level 120
This was when the “new” cardinality estimator (CE) was introduced. In many cases, most of your queries ran faster when using the new cardinality estimator, but it was fairly common to run into some queries that had major performance regressions with the new cardinality estimator. Using database compatibility level 120 means that you will be using the “new” CE unless you use an instance-wide trace flag or a query-level query hint to override it.
Joe Sack wrote the classic whitepaper “Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator” that explains the background and behavior of this change back in April of 2014. If you saw performance regressions on some queries with the new CE, SQL Server 2014 did not have that many options for alleviating the performance issues caused by the new CE. Joe’s whitepaper covers those options in great detail, but essentially, you were limited to instance-level trace flags or query-level query hints to control which cardinality estimator was used by the query optimizer, unless you wanted to revert back to database compatibility level 110 or lower.
The reason I called it the “new” CE in quotes is because there is now no single “new” CE. Each new version of SQL Server since SQL Server 2014 has CE and query optimizer changes tied to the database compatibility level. The new, more accurate terminology that is relevant on SQL Server 2016 and newer is CE120 for compatibility level 120, CE130 for for compatibility level 130, CE140 for for compatibility level 140, and CE150 for for compatibility level 150.
Database Compatibility Level 130
When you are on SQL Server 2016 or newer, using database compatibility level 130 will use CE130 by default, and will enable a number of other performance related changes. The effects of global trace flags 1117, 1118, and 2371 are enabled with database compatibility level 130. You will also get the effect of global trace flag 4199 for all query optimizer hotfixes that were released before SQL Server 2016 RTM.
SQL Server 2016 also introduced database scoped configuration options, which give you the ability to control some behaviors that were formerly configured at the instance level, using an ALTER DATABASE SCOPED CONFIGURATION command. The two most relevant database scoped configuration options for this discussion are LEGACY_CARDINALITY ESTIMATION and QUERY_OPTIMIZER_HOTFIXES.
LEGACY_CARDINALITY ESTIMATION enables the legacy CE (CE70) regardless of the database compatibility level setting. It is equivalent to trace flag 9481, but it only affects the database in question, not the entire instance. It allows you to set the database compatibility level to 130 in order to get the other functional and performance benefits, but use the legacy CE database-wide (unless overridden by a query-level query hint).
The QUERY_OPTIMIZER_HOTFIXES option is equivalent to trace flag 4199 at the database level. SQL Server 2016 will enable all query optimizer hotfixes before SQL Server 2016 RTM when you use the 130 database compatibility level (without enabling trace flag 4199). If you do enable TF 4199 or enable QUERY_OPTIMIZER_HOTFIXES, you will also get all of the query optimizer hotfixes that were released after SQL Server 2016 RTM.
SQL Server 2016 SP1 also introduced the USE HINT query hints that are easier to use and understand than the older QUERYTRACEON query hints that you had to use in SQL Server 2014 and older. This gives you even more fine-grained control over optimizer behavior that is related to database compatibility level and the version of the cardinality estimator that is being used. You can query sys.dm_exec_valid_use_hints to get a list of valid USE HINT names for the exact build of SQL Server that you are running.
Database Compatibility Level 140
When you are on SQL Server 2017 or newer, using database compatibility level 140 will use CE140 by default. You also get all of the other performance related changes from 130, plus new ones as detailed here. SQL Server 2017 introduced the new adaptive query processing features, and they are enabled by default when you are using database compatibility level 140. These include batch mode memory grant feedback, batch mode adaptive joins, and interleaved execution.
Database Compatibility Level 150
When you are on SQL Server 2019 or newer, using database compatibility level 150 will use CE150 by default. You also get all of the other performance related changes from 130 and 140, plus new ones as detailed here. SQL Server 2019 is adding even more performance improvements and behavior changes that are enabled by default when a database is using compatibility mode 150. A prime example is scalar UDF inlining, which automatically inline many scalar UDF functions in your user databases. This may be one of the most important performance improvements for some workloads.
Another example is the intelligent query processing feature, which is a superset of the adaptive query processing feature in SQL Server 2017. New features include table variable deferred compilation, approximate query processing, and batch mode on rowstore.
There are also sixteen new database scoped configuration options (as of CTP 2.2) that give you database-level control of more items that are also affected by trace flags or the database compatibility level. It gives you even more fine-grained control of these higher level changes that are enabled by default with database compatibility level 150.
Conclusion
Migrating to a modern version of SQL Server (meaning SQL Server 2016 or newer) is significantly more complicated than it was with legacy versions of SQL Server. Because of the changes associated with the various database compatibility levels and various cardinality estimator versions, it is actually very important to put some thought, planning, and actual testing into what database compatibility level you want to use on the new version of SQL Server that you are migrating your existing databases to.
Microsoft’s recommended upgrade process is to upgrade to the latest SQL Server version, but keep the source database compatibility level. Then, enable Query Store on each database and collect baseline data on the workload. Next, you set the database compatibility level to the latest version, and then use Query Store to fix your performance regressions by forcing the last known good plan.
You really want to avoid a haphazard “blind” migration where you are blissfully unaware of how this works and how your workload will react to these changes. Changing the database compatibility level to an appropriate version and using the appropriate database scoped configuration options, along with appropriate query hints where absolutely necessary, is extremely important with modern versions of SQL Server.
Another thing to consider (especially for ISVs) is that Microsoft is starting to really push the idea that you should think about testing and certifying your databases and applications to a particular database compatibility level rather than a particular version of SQL Server. Microsoft provides query plan shape protection when the new SQL Server version (target) runs on hardware that is comparable to the hardware where the previous SQL Server version (source) was running and the same supported database compatibility level is used both at the target SQL Server and source SQL Server.
The idea here is that once you have tested and certified your applications on a particular database compatibility level, such as 130, you will get the same behavior and performance if you move that database to a newer version of SQL Server (such as SQL Server 2017 or SQL Server 2019) as long as you are using the same database compatibility level and you are running on equivalent hardware.
The post The Importance of Database Compatibility Level in SQL Server appeared first on Glenn Berry.
]]>The post SQL Server Diagnostic Information Queries for December 2018 appeared first on Glenn Berry.
]]>I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.
I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.
Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.
Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, SQL Server 2016, and SQL Server 2014:
Azure SQL Database Diagnostic Information Queries
SQL Server 2019 Diagnostic Information Queries
SQL Server 2017 Diagnostic Information Queries
SQL Server 2016 SP2 Diagnostic Information Queries
SQL Server 2016 Diagnostic Information Queries
SQL Server 2014 Diagnostic Information Queries
Here are links to the most recent versions of these scripts for SQL Server 2012 and older:
Since SQL Server 2012 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.
SQL Server 2012 Diagnostic Information Queries
SQL Server 2008 R2 Diagnostic Information Queries
SQL Server 2008 Diagnostic Information Queries
SQL Server 2005 Diagnostic Information Queries
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 four related Pluralsight courses, which are 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 four of these courses are pretty short and to the point, at 106, 67, 77, and 68 minutes respectively. Listening to these four 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!
The post SQL Server Diagnostic Information Queries for December 2018 appeared first on Glenn Berry.
]]>The post IEPUM2017: Immersion Event on Planning and Implementing an Upgrade/Migration to SQL Server 2017 appeared first on Glenn Berry.
]]>I think this is a very interesting and useful class that is especially relevant during 2019 because of the end of extended support for SQL Server 2008/2008 R2, the end of mainstream support for SQL Server 2014, the release of Windows Server 2019, the upcoming release of SQL Server 2019, new processor releases from both Intel and a newly competitive AMD, and many new memory and storage-related developments that affect SQL Server. I wrote about some of these factors here.
Here is the module list:
- Module 1: Upgrade Planning
- Module 2: Hardware and Storage Selection
- Module 3: SQL Server 2017 Installation and Configuration
- Module 4: Upgrade Testing
- Module 5: Migration Planning
- Module 6: Production Migration Methods
This class is relevant for upgrade/migrations to SQL Server 2016, SQL Server 2017, and SQL Server 2019. I think a lot of organizations are going to be upgrading/migrating to a modern version of SQL Server during 2019-2020, and I want to teach as many people as possible how to avoid doing a “blind migration”, where they don’t do the necessary planning, analysis, and testing, and end up having poor upgrade/migration experience.
You can jump right to the registration page here. I hope to see you in this class!
The post IEPUM2017: Immersion Event on Planning and Implementing an Upgrade/Migration to SQL Server 2017 appeared first on Glenn Berry.
]]>The post SQL Server Diagnostic Information Queries for November 2018 appeared first on Glenn Berry.
]]>I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.
I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.
Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.
Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, SQL Server 2016, and SQL Server 2014:
Azure SQL Database Diagnostic Information Queries
SQL Server 2019 Diagnostic Information Queries
SQL Server 2017 Diagnostic Information Queries
SQL Server 2016 SP2 Diagnostic Information Queries
SQL Server 2016 Diagnostic Information Queries
SQL Server 2014 Diagnostic Information Queries
Here are links to the most recent versions of these scripts for SQL Server 2012 and older:
Since SQL Server 2012 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.
SQL Server 2012 Diagnostic Information Queries
SQL Server 2008 R2 Diagnostic Information Queries
SQL Server 2008 Diagnostic Information Queries
SQL Server 2005 Diagnostic Information Queries
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 four related Pluralsight courses, which are 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 four of these courses are pretty short and to the point, at 106, 67, 77, and 68 minutes respectively. Listening to these four 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!
The post SQL Server Diagnostic Information Queries for November 2018 appeared first on Glenn Berry.
]]>The post SQL Server Diagnostic Information Queries for October 2018 appeared first on Glenn Berry.
]]>I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.
I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.
Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.
Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, SQL Server 2016, and SQL Server 2014:
Azure SQL Database Diagnostic Information Queries
SQL Server 2019 Diagnostic Information Queries
SQL Server 2017 Diagnostic Information Queries
SQL Server 2016 SP2 Diagnostic Information Queries
SQL Server 2016 Diagnostic Information Queries
SQL Server 2014 Diagnostic Information Queries
Here are links to the most recent versions of these scripts for SQL Server 2012 and older:
Since SQL Server 2012 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.
SQL Server 2012 Diagnostic Information Queries
SQL Server 2008 R2 Diagnostic Information Queries
SQL Server 2008 Diagnostic Information Queries
SQL Server 2005 Diagnostic Information Queries
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 four related Pluralsight courses, which are 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 four of these courses are pretty short and to the point, at 106, 67, 77, and 68 minutes respectively. Listening to these four 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!
The post SQL Server Diagnostic Information Queries for October 2018 appeared first on Glenn Berry.
]]>The post PASS Summit 2018 appeared first on Glenn Berry.
]]>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.
I will also be covering some SQL Server 2019 considerations in this session.
This is a fun session that I really enjoy presenting. I think this subject is especially relevant with the upcoming end of extended support of SQL Server 2008/SQL Server 2008 R2 and end of mainstream support for SQL Server 2014, which both happen on July 9, 2019.
I honestly believe that CY 2019 is going to be an ideal time for many organizations to migrate from legacy versions of SQL Server (SQL Server 2014 and older) to a modern version of SQL Server (SQL Server 2016 and newer).
This is because you will have the opportunity to upgrade your entire data platform stack with significant new releases, including new processor families from Intel and AMD, wider availability of Intel Optane DC Persistent Memory, a new server operating system release (Windows Server 2019), and a new SQL Server release (SQL Server 2019).
BTW, if you are going to a Tuesday pre-con session at PASS, you should strongly consider Kimberly’s Query Performance Problems from Estimates, Statistics, Heuristics, and Cardinality. I have more information about why this session will be a great choice here.
You can register for the PASS Summit 2018 here.
The post PASS Summit 2018 appeared first on Glenn Berry.
]]>The post SQL Server Diagnostic Information Queries for September 2018 appeared first on Glenn Berry.
]]>I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.
I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea.
Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.
Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, SQL Server 2016, and SQL Server 2014:
Azure SQL Database Diagnostic Information Queries
SQL Server 2019 Diagnostic Information Queries
SQL Server 2017 Diagnostic Information Queries
SQL Server 2016 SP2 Diagnostic Information Queries
SQL Server 2016 Diagnostic Information Queries
SQL Server 2014 Diagnostic Information Queries
Here are links to the most recent versions of these scripts for SQL Server 2012 and older:
Since SQL Server 2012 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.
SQL Server 2012 Diagnostic Information Queries
SQL Server 2008 R2 Diagnostic Information Queries
SQL Server 2008 Diagnostic Information Queries
SQL Server 2005 Diagnostic Information Queries
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 four related Pluralsight courses, which are 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 four of these courses are pretty short and to the point, at 106, 67, 77, and 68 minutes respectively. Listening to these four 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!
The post SQL Server Diagnostic Information Queries for September 2018 appeared first on Glenn Berry.
]]>