How to Uninstall Microsoft SQL Server 2017 Reporting Services

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.

Uninstall Reporting Services

SSRS Uninstall 1

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.

SSRS Uninstall 2

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.

SSRS Uninstall 3

Figure 3: Uninstall in Progress

It will look like this when it is done.

SSRS Uninstall 4

Figure 4: Completed Uninstall

Hopefully this will save you some time if you ever want to do this.

Glenn’s Tech Insights For June 13, 2019

(Glenn’s Tech Insights… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can get more visibility. It covers interesting new hardware and software developments that are generally relevant for SQL Server).

AMD Announcements at the E3 Conference

On June 10, 2019 AMD President and CEO, Dr. Lisa Su delivered a presentation at the E3 Expo 2019 in Los Angeles. During this presentation, Dr. Su announced more architectural details about the 7nm Ryzen 3000 series mainstream desktop processors,including a new 16C/32T, Ryzen 9 3950X SKU. AMD also demoed the upcoming 7nm AMD EYPC “Rome” server processors, along with the upcoming 7nm AMD Radeon RX 5700 “Navi” video cards. The updated Ryzen 3000 SKU list is shown in Figure 1.

AMD Ryzen 3000 Series

Figure 1: AMD Ryzen 3000 Lineup



One of the more interesting bits of new information is the fact that AMD has been working closely with Microsoft to develop improvements to how scheduling and thread allocation is handled on AMD Zen2 architecture processors on Windows 10 Build 1903. They are moving from a hybrid thread expansion strategy (where active cores are placed as far away from each other as possible) to thread grouping, where new threads are allocated  as close as possible to already active cores, hopefully on the same CCX. This improves thread to thread communication by speeding up memory access. This is designed to improve the apparent scheduling issues seen on Windows with some AMD Zen processors. You will need an updated AMD chipset driver to get this improvement.

It is not yet clear how well this will work on more heavily threaded workloads like you typically see on a database server. I am also not yet 100% certain that this fix is in Windows Server 2016 and Windows Server 2019 yet. The upcoming AMD EPYC “Rome” processors use the same Zen 2 architecture, so it is possible they will benefit from this change with some workloads.

Figure 2: Topology Awareness

Another Windows 10 Build 1903 improvement that will definitely help AMD Zen architecture processors is a feature that AMD calls faster clock ramping. It is actually UEFI Collaborative Power Performance Control 2 (CPPC2), which lets the processor and operating system cooperate more closely (and quickly) to increase the clock speed of individual cores more rapidly under a load. This feature moves P-state control from the OS to the processor, so the processor can “throttle up” much more quickly than before. AMD is claiming a clock ramp time of 1-2ms with this improvement compared to about 30ms before. This will also require a UEFI/BIOS update and a new AMD chipset driver before it will work.

This feature is very similar to Intel Speed Shift, which was introduced with their Skylake processors, and improved with Kaby Lake. Intel Speed Shift requires Windows 10 v10586 or Windows Server 2016 or newer. Intel Speed Shift takes 15-30ms to ramp up, so it is not as responsive as AMD’s implementation. AMD also revealed that the Zen 2 architecture processors will have hardware level mitigations for Spectre and Spectre v4. Keep in mind that AMD processors are not vulnerable to Meltdown, or newer exploits such as Foreshadow or Zombieload.

These architectural improvements in the Zen 2 architecture will also show up in the upcoming (Q3 2019) 7nm AMD EPYC “Rome” server processors, which is very exciting from a SQL Server perspective.

SQL Server Diagnostic Information Queries for June 2019

This month, I have added some new columns in some of the queries in most of the query sets. I have also been working on the Azure SQL Database version of the queries some more lately.

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

Azure SQL Database Blank Results Spreadsheet

SQL Server 2019 Diagnostic Information Queries

SQL Server 2019 Blank Results Spreadsheet

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 SP2 Diagnostic Information Queries

SQL Server 2016 SP2 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

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 2012 Blank Results Spreadsheet

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 five related Pluralsight courses, which are SQL Server 2017: Diagnosing Performance Issues with DMVs, SQL Server 2017: Diagnosing Configuration Issues with DMVs, 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 five of these courses are pretty short and to the point, at 164, 106, 67, 77, and 68 minutes respectively. Listening to these five 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!