The post How to Uninstall Microsoft SQL Server 2017 Reporting Services appeared first on Glenn Berry.
]]>I had to uninstall SQL Server 2017 Reporting Services (SSRS) for a client recently. It is not difficult to do, but the process is different than it was in older versions of SQL Server. Starting with SQL Server 2017, SSRS 2017 is a separate download from the rest of SQL Server that is not included on the SQL Server 2017 installation media. Because of this, you need to find Microsoft SQL Server Reporting Services under Uninstall or change a program in Control Panel. Then you simply right-click and choose uninstall.
This is different than how it used to be, and different from how Microsoft currently describes it in their documentation, which doesn’t appear to have been updated yet.
Figure 1: Microsoft SQL Server Reporting Services Entry
You will see a screen like this, which will let you do an Edition Upgrade, Repair, or an Uninstall.
Figure 2: Microsoft SQL Server 2017 Reporting Services Maintenance
Depending on your machine, the uninstall should go pretty quickly. It doesn’t typically require a reboot. It also doesn’t require a restart of the SQL Server Service, since it is a completely separate service.
Figure 3: Uninstall in Progress
It will look like this when it is done.
Figure 4: Completed Uninstall
Hopefully this will save you some time if you ever want to do this.
The post How to Uninstall Microsoft SQL Server 2017 Reporting Services 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 Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds appeared first on Glenn Berry.
]]>If you are running on the SQL Server 2014 SP3 branch, I really think you should be running the latest SQL Server 2014 SP3 Cumulative Update.
Table 1 shows the SQL Server 2014 SP3 CU builds that have been released.
| Build | Description | Release Date |
| 12.0.6205 | SP3 CU1 | December 12, 2018 |
| 12.0.6214 | SP3 CU2 | February 19, 2019 |
| 12.0.6259 | SP3 CU3 | April 16, 2019 |
| 12.0.6329 | SP3 CU4 | July 29, 2019 |
Table 1: SQL Server 2014 SP3 CU Builds
You can follow the KB article link below to see all of the CU builds for the SQL Server 2014 RTM, SQL Server 2014 SP1, SQL Server 2014 SP2, and SQL Server 2014 SP3 branches.
Like I have done for other versions and branches of SQL Server, I decided to scan the hotfix list for all of the Cumulative Updates in the SP3 branch, looking for performance and general reliability-related fixes for the SQL Server Database Engine. I came up with the list below, but this listing is completely arbitrary on my part. You may come up with a completely different list, based on what specific SQL Server 2014 features you are using.
Here are the fixes in the SP3 branch:
SQL Server 2014 SP3 Cumulative Update 1 (Build 12.0.6205), 13 total public hot fixes
FIX: Access violation when you run a query that uses the XML data type in SQL Server 2014
FIX: Overestimations when using default Cardinality Estimator to query table with many null values
FIX: I/O errors on a BPE file causes buffer time out in SQL Server
FIX: Assertion error occurs during restore of compressed backups in SQL Server 2016
FIX: Internal error messages when you update a FILESTREAM tombstone system table in SQL Server
SQL Server 2014 SP3 Cumulative Update 2 (Build 12.0.6214), 5 total public hot fixes
FIX: High CPU use when large index is used in a query on a memory-optimized table in SQL Server
FIX: Assertion occurs when a parallel query deletes from a Filestream table
SQL Server 2014 SP3 Cumulative Update 3 (Build 12.0.6259), 4 total public hot fixes
FIX: Log reader agent may fail after AG failover with TF 1448 enabled in SQL Server 2014
SQL Server 2014 SP3 Cumulative Update 4 (Build 12.0.6329), 19 total public hot fixes
FIX: Filtered index may be corrupted when you rebuild index in parallel in SQL Server 2014 and 2016
FIX: Stack Dump occurs in the change tracking cleanup process in SQL Server 2014, 2016 and 2017
FIX: Tlog grows quickly when you run auto cleanup procedure in SQL Server 2014, 2016 and 2017
FIX: Full-text search fails to remove files from \FTDATA\FilterData subfolder in SQL Server 2014
FIX: SQL batch performance drops when you enable “Force Encryption” in SQL Server 2014
FIX: Full text search auto populate stops when Availability Group goes offline in SQL Server 2014
FIX: Error 409 occurs when you back up databases by using BackuptoURL
The reason that I put these lists together is that I want to convince more people to try to keep their SQL Server instances up to date with Cumulative Updates. If you do the proper testing, planning and preparation, I think the risks from installing a SQL Server Cumulative Update are quite low (despite the occasional issues that people run into).
If you install a Cumulative Update or Service Pack on a Production system the day it is released, after doing no testing whatsoever, and then run into problems (and don’t have a plan on how to recover), then I don’t have that much sympathy for you.
On the other hand, if you go through a thoughtful and thorough testing process, and you have a plan for how you will install the CU, and how you would recover if there were any problems, then you are much less likely to have any problems. You are also much more likely to avoid the issues that are fixed by all of the included fixes in the new build of SQL Server. You have done your job as a good DBA.
Finally, Microsoft has changed their official guidance about whether you should install SQL Server Cumulative Updates. As they say, “we now recommend ongoing, proactive installation of CU’s as they become available”.
The post Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds appeared first on Glenn Berry.
]]>The post SQL Server 2014 Service Pack 3 CU1 Released appeared first on Glenn Berry.
]]>Microsoft also released SQL Server 2014 Service Pack 2 CU15 on the same day. It is Build 12.0.5605.1, and it has 7 hotfixes in the public fix list. If you are on the SP2 or an even earlier branch, you should be thinking about getting on SP3 as soon as you can.
The post SQL Server 2014 Service Pack 3 CU1 Released appeared first on Glenn Berry.
]]>The post SQL Server 2016 SP2 CU2 Available appeared first on Glenn Berry.
]]>Microsoft has also released SQL Server 2016 SP1 CU10, which is Build 13.0.4514.0. There are also 21 fixes in the public fix list, including a number of fixes in the High Availability and SQL Engine fix areas. I think you should be on The SQL Server 2016 SP2 branch by now, or as soon as possible, but the SP1 branch is still supported.
I want to convince more people to try to keep their SQL Server instances up to date with Cumulative Updates. If you do the proper testing, planning and preparation, I think the risks from installing a SQL Server Cumulative Update are quite low (despite the occasional issues that people run into).
If you install a Cumulative Update or Service Pack on a Production system the day it is released, after doing no testing whatsoever, and then run into problems (and don’t have a plan on how to recover), then I don’t have that much sympathy for you.
On the other hand, if you go through a thoughtful and thorough testing process, and you have a plan for how you will install the CU, and how you would recover if there were any problems, then you are much less likely to have any problems. You are also much more likely to avoid the issues that are fixed by all of the included fixes in the new build of SQL Server. You have done your job as a good DBA.
Finally, Microsoft has changed their official guidance about whether you should install SQL Server Cumulative Updates. As they say, “we now recommend ongoing, proactive installation of CU’s as they become available”.
The post SQL Server 2016 SP2 CU2 Available appeared first on Glenn Berry.
]]>The post SQL Server 2017 Cumulative Update 6 appeared first on Glenn Berry.
]]>Remember, there are not going to be any Service Packs for SQL Server 2017. We are still in the monthly release cycle for SQL Server 2017 Cumulative Updates which will last for the first year after release. After that the CU release cycle will change to quarterly until SQL Server 2017 falls out of Mainstream Support on October 11, 2022.
As always, my recommendation is to try to stay as current as possible with your SQL Server Cumulative Updates. That doesn’t mean that you should deploy them to Production the day they are released, with absolutely no testing, but it also doesn’t mean that you should not make any effort to stay current. Try to find a deployment cadence that makes sense for your organization.
The post SQL Server 2017 Cumulative Update 6 appeared first on Glenn Berry.
]]>The post SQL Server 2017 Cumulative Update 5 appeared first on Glenn Berry.
]]>There are quite a few fixes for performance and the database engine area in this CU. Remember, there are not going to be any Service Packs for SQL Server 2017, so you are going to want to test and deploy SQL Server 2017 Cumulative Updates as they become available.
As always, I think it is a good idea to make an effort to stay current on Cumulative Updates, as does Microsoft.
The post SQL Server 2017 Cumulative Update 5 appeared first on Glenn Berry.
]]>The post SQL Server 2017 Cumulative Update 4 appeared first on Glenn Berry.
]]>There are also quite a few updates for Columnstore indexes and for Availability Groups. Remember, there are not going to be any Service Packs for SQL Server 2017, so you are going to want to test and deploy SQL Server 2017 Cumulative Updates as they become available.
As always, I think it is a good idea to make an effort to stay current on Cumulative Updates, as does Microsoft.
The post SQL Server 2017 Cumulative Update 4 appeared first on Glenn Berry.
]]>The post Checking Your SQL Server Instance for Spectre/Meltdown Patches appeared first on Glenn Berry.
]]>SQL Server Guidance to protect against speculative execution side-channel vulnerabilities (SQL Server)
Windows Server guidance to protect against speculative execution side-channel vulnerabilities (Windows Server)
Windows Client Guidance for IT Pros to protect against speculative execution side-channel vulnerabilities (Windows Client)
The basic guidance is that depending on the environment where you are running SQL Server (on-premises or not, virtualized or not, in a cloud IaaS VM or not) and whether you are using any open extensibility interfaces or not (things like some types of CLR assemblies, some types of linked servers, etc.), you are going to want to strongly consider patching several layers of your system. These may include:
- Operating System patches
- Registry changes
- SQL Server patches
- BIOS/UEFI updates
- Possible changes in how/whether you use any open extensibility interfaces in SQL Server
The Microsoft guidance about SQL Server gives some pretty clear scenarios and guidelines for making the decision on what to patch or change.
Checking Your Operating System and Hardware
Once you have decided what to patch, the next issue is checking your patch and update status at all of these different layers of the system. Microsoft has a PowerShell script that lets you check the patch status of your operating system and your processor microcode (for Intel processors).
This Microsoft KB article explains this in more detail and has a link to download the PowerShell Module for operating systems prior to Windows Server 2016.
If you want to do a quick and easy check of a client operating system for an end-user (or your Mom) without having to deal with PoSH, you can download and run the InSpectre utility (with an easy GUI) to check the patch status of your operating system and your processor microcode.
Checking SQL Server
Finally, you need to check your SQL Server patch status. I have developed (and had a number of people help test) a T-SQL script that will check your SQL Server instance to see whether you have installed the relevant SQL Server patches or not. This script will work on SQL Server 2008 through SQL Server 2017 for on-premises instances or for Azure IaaS instances. This is not designed to work on Azure SQL Database. You can download it here.
Please let me know if you have any suggestions about this. I also want to thank the people who have tested this script and given me feedback!
The post Checking Your SQL Server Instance for Spectre/Meltdown Patches appeared first on Glenn Berry.
]]>The post Performance Effects of Meltdown and Partial Spectre Fixes on Intel Core i7-7500U Laptop appeared first on Glenn Berry.
]]>Last night, I installed the Windows 10 January 2018 Security Update (KB4056892) on this system, and then used PowerShell to check my status, with the results as shown in Figure 1. These are the relevant results:
Speculation control settings for CVE-2017-5715 [branch target injection] (This is Spectre variant 2)
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load] (This is Meltdown)
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]
Suggested actions
* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation mitigation
Figure 1: After Windows 10 Security Update, but before BIOS Update
After I had installed the Windows 10 January 2018 Security Update (KB4056892) on this system, I ran both the CPU-Z 1.82.1 CPU benchmark and the CrystalDiskMark 6.0.0 synthetic disk benchmark three times, to get a performance baseline before I installed the new BIOS (that has the microcode update to enable the Spectre variant 2 fixes). Some results from these test runs are shown in Figures 3 and 5 below.
Following Microsoft’s guidance, I located and installed the latest BIOS for my HP Spectre x360 laptop, which is version F.42. Then, I again used PowerShell to check my status, with the results as shown in Figure 2. These are the relevant results:
Speculation control settings for CVE-2017-5715 [branch target injection] (This is Spectre variant 2)
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True
Speculation control settings for CVE-2017-5754 [rogue data cache load] (This is Meltdown)
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]
Figure 2: After Windows 10 Security Update and BIOS Update
Figure 3 shows one of the CPU-Z 1.82.1 benchmark run results before the BIOS update, showing a CPU Single Thread score of 373.9, and a CPU Multi Thread score of 1000.2.
Figure 3: After Windows 10 Security Update, but before BIOS Update
Figure 4 shows one of the CPU-Z 1.82.1 benchmark run results after the BIOS update, showing a CPU Single Thread score of 317.5, and a CPU Multi Thread score of 971.8. That is about a 15.1% reduction in single-threaded CPU performance and a 2.8% reduction in multi-threaded CPU performance, at least on this quick synthetic CPU benchmark.
Figure 4: After Windows 10 Security Update and BIOS Update
Figure 5 shows one of the CrystalDiskMark 6.0.0 benchmark run results before the BIOS update.
Figure 5: After Windows 10 Security Update, but before BIOS Update
Figure 6 shows one of the CrystalDiskMark 6.0.0 benchmark run results after the BIOS update.
Figure 6: After Windows 10 Security Update and BIOS Update
What these limited synthetic benchmark test results show is that installing the CPU microcode updates (which are a required part of the Spectre variant 2 fix) seems to have a pretty significant effect on single-threaded CPU performance in the CPU-Z benchmark. We also see a very significant effect on random I/O performance in CrystalDiskMark 6.0.0 using the default test settings with a 4GB test file.
Microsoft’s Terry Myerson has a pretty detailed post on this subject
Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems
Intel has published some client benchmark results for 6th, 7th, and 8th Generation Core processors, as shown here:
Intel Security Issue Update: Initial Performance Data Results for Client Systems
The post Performance Effects of Meltdown and Partial Spectre Fixes on Intel Core i7-7500U Laptop appeared first on Glenn Berry.
]]>