Data Collector: Remove Data Collector to Remove Associated Objects - by Lara Rubbelke

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 334180 Comments
Status Resolved Workarounds
Type Suggestion Repros 3
Opened 3/24/2008 11:47:48 AM
Access Restriction Public


After the data collector is configured, the data collector can be disabled but not removed.  This means that all objects created by the data collector will remain on the instance and certain objects cannot be removed.  

When the data collector is disabled, the associated SQL Server Agent jobs and system data collection sets cannot be removed.  The jobs will appear as disabled, but SQL Server will not allow you to remove the jobs through T-SQL or through SSMS.

Database Administrators have no option to remove these jobs.  If an environment chooses to stop using data collection in the future, they will always have to look around jobs which will never be used on the instance in the future.
Sign in to post a comment.
Posted by Brian Callaghan on 8/16/2016 at 10:30 PM
Getting this error on SQL 2016 CU1 on a named clustered instance.
exec msdb.dbo.sp_syscollector_cleanup_collector @collection_set_id = xx
the work around in
both worked
Posted by Sethu Srinivasan on 12/29/2015 at 1:13 PM
You can use the following store procedure to remove associated agent jobs and then you could drop the collection sets

-- Cleanup all agent jobs associated with collection set id -- 6
exec msdb.dbo.sp_syscollector_cleanup_collector @collection_set_id = 6

-- Cleanup all agent jobs associated with all collection sets
exec msdb.dbo.sp_syscollector_cleanup_collector

Sethu Srinivasan [MSFT]
SQL Server
Posted by hot2use on 9/22/2015 at 5:29 AM
Had the same issue on a test server (lucky me). I had previously activated the MDW solution due to a vendor recommendation and then wanted to delete everything.
That is when I started sweating profoundly...

I then found an article from Aaron Bertrand (MVP) [...thanks a million...] on a website titled:

"Removing the SQL Server Management Data Warehouse"

Posted by Adam Bean on 9/20/2013 at 12:15 PM
Two releases later, and the problem still exists. I was hesitant setting this up after being burnt years ago in 2008, but I assumed in 2012 it would have been fixed.

Negative, still broke.
Posted by RickGot on 2/19/2013 at 2:34 PM
So it looks as though you've created a product, then sold it to DBA's, who subsequently discovered that it provides very little usable information and would like to uninstall but can't. MSFT responses below seem to indicate that you never considered a rollback strategy for this type of implementation. I suppose that indicates that the team that planned and built this invasive product for MS SQL Server probably had very little DBA experience. Sad that MSFT never considered adding a DBA or two to a team building products for use by DBAs. I suppose that's par for the course in Redmond.
Posted by cv2 on 10/26/2012 at 5:19 AM
Sethu, I used the script for SQL versions prior to SQL 2012 and it worked! Thank you very much. -Cindy (cv2)
Posted by Sethu Srinivasan on 7/10/2012 at 12:25 PM
Hello cv2,
New stored procedure is added in SQL 2012,

For SQL versions prior to SQL 2012, please refer to

SQL 2012 -

You can also read through customer feedback in this thread. customers have used the approach mentioned in above blog articles to cleanup collector jobs on their SQL 2008 R2

Sethu Srinivasan [MSFT]
SQL Server
Posted by cv2 on 7/6/2012 at 7:40 AM
Is there a cleanup job for SQL 2008 R2?
Posted by Sethu Srinivasan on 2/9/2012 at 10:34 AM
We have added a stored procedure sp_syscollector_cleanup_collector in msdb in SQL 2012.
SQL 2012:

Sethu Srinivasan[MSFT]
SQL Server
Posted by David N Nguyen on 1/18/2012 at 1:48 PM
Thanks Team.
Your script works perfect with no regrettable incident in Test as well as in Production.
But of course, my case at my company may be different than other cases.
I appreciate your effort and genius.
Many thanks.
David N Nguyen.
Posted by Sethu Srinivasan on 7/23/2011 at 10:26 AM
Were you able to cofigure data collection again after cleaning up?

Sethu Srinivasan [MSFT]
SQL Server
Posted by eckcessive on 7/22/2011 at 8:19 PM
Thanks Sethu... I ran this on a test server (SQL 2008 R2) with no issues, then I ran it in Production (SQL 2008 R2) with no issues. Thanks for sharing.
Posted by Sethu Srinivasan on 7/22/2011 at 6:28 PM
Hello all,
I have posted a blog entry in our team blog related to this issue. Could you please validate this on your test systems and keep us posted?

Sethu Srinivasan [MSFT]
SQL Server
Posted by ShishirGS on 7/12/2011 at 9:40 PM
I setup the DCU-08 in our environment. I was able to disable the jobs but not able to Remove it completly. I created a ticket with MS. When we tried to remove it from MSDB db, it results in corruption of the msdb db and finally end up with re-installation of SQL server. So, I will suggest to wait untill MS finally confirmed the Functionality is able to Remove from SQL Server (mostly Sql-2011).
Posted by Geert Vanhove DCOD on 6/27/2011 at 8:01 AM
What is the status of this 2 years after the last post of Microsoft on this?
Is SQL2008r2 not a mojor release?
As many others, I won't even try to test this unless I know I can uninstall it.
Pity, because this was exactly what we needed.
Posted by Chandan jha on 6/23/2011 at 12:08 AM
Do not touch the system tables or views which are used in data collection. I deleted them manually and then when I refreshed the 'management' node in management studio, I was not able to see SQL Server logs, database mail features etc. as the data collection feature got corrupted and started throwing weird errors.
I somehow managed to fix it by using some chunks of scripts from instmsdb.sql which were just related to data collection feature.

Please wait till Microsoft announces the fix in their release. Even if you feel suffocated with the data collection jobs or packages that got created, please leave them.They wont cause any harm and will just sit there in disabled state which is better rather than corrupting msdb.
Posted by Adam Bean on 2/14/2011 at 10:47 AM
Finally decided to give a shot. The workaround was close, but simply the wrong table. This is the query I ran and I was able to successfully drop the jobs:

UPDATE [msdb].[dbo].[syscollector_collection_sets_internal]
SET [collection_job_id] = NULL
,[upload_job_id] = NULL

I do not yet know what if anything this will do in the long run should you want to re-create the process, but I personally don't plan on trying to use it again after this experience. However, I don't believe it will cause an issue as these columns are NULL in this table on a 2008 instance without this enabled.
Posted by baal32 on 1/31/2011 at 10:19 AM
Come on, is this a joke? Two years without being able to provide a simple unisntallation procedure or accepted work-around?

You guys hiring?
Posted by Adam Bean on 10/13/2010 at 1:10 PM
The name posted in the work around is the FK name, not the table name (FK_syscollector_collection_sets_collection_sysjobs). Still do not feel comfortable modifying the system tables. Shame that this was posted over 2 1/2 years ago and no resolution yet.
Posted by Adam Bean on 10/13/2010 at 1:01 PM
Well, doesn't appear that SP2 fixed this issue ... the workaround posted does not appear to be valid either as there is no table by that name.
Posted by FozzieKev on 6/15/2010 at 8:51 AM
This is pretty poor, reminds me of certain brans of Anti-Virus software leaving in hooks all round the system.

Why is there no workaround?
Posted by Kendra Little on 6/2/2010 at 9:51 PM
Also adding my vote for this. I really enjoy the feature, but as with anything it is necessary to be able to uninstall and reinstall it. I currently have an installation of data collector on an R2 server which failed halfway through-- one of the first steps I wanted to take was cleaning up the feature/uninstalling before attempting to reinstall. Very odd not to have that option. A KB with instructions as a workaround would be great.
Posted by cbentle on 3/30/2010 at 12:15 PM
Just wanted to add my vote. I will not be testing Data Collector until there is a resonable process to remove it. And it has been TWO YEARS!!! And it's not in R2???
Posted by Manuel Burggraf on 3/10/2010 at 6:49 AM
a MS Sales Man just presented this feature to us, I gave it a try and wanted it to be removed... doh.
When reading this here I couldn't believe my eyes.
embarrassing, shame, incompetence, brainless, angry - just a few words on my mind.
I go and reinstall the system.
Thanks a lot - live up to your name
Posted by Adam Bean on 2/23/2010 at 1:18 PM
Is there any update on this? I now have two environments with these jobs that I can not remove because of this error.

Posted by Microsoft on 5/29/2009 at 9:29 AM
Lara -

I've resolved this bug duplicate of the work item tracking this work for SQL11. We do plan to make the uninstall experience better for Data Collector in our next major release.


Amy Lewis
Posted by Michael Hotek on 12/16/2008 at 7:32 PM
Same here. We are re-purposing a machine and do NOT want data collection on this machine anymore. The only options I have is to either hack tables in msdb or reinstall the instance. I'm fairly certain that you don't want to send the message to a customer that if you ever turn feature X on, that you can never, ever, remove it without blowing the entire instance away and reinstalling.
Posted by TiborK on 8/25/2008 at 9:41 AM
I fully agree. I now have three instances with DC installed and I will have to clean these up in a week. If that doesn't work, I'm in for a rebuild sys databases situation - not fun. I strongly encourage that a KB is produced with instructions on how to do this. I do not look forward to either doing the rebuild dance or hacking system tables in msdb (being with TSQL or undocumented procedures).
Posted by Kalen Delaney on 4/21/2008 at 4:32 PM
I think the ability to remove a component is crucial. Especially during testing, users are going to want to try out the Data Collection capabilities. and they may decide they don't want it. Right now, there seems to be no way to get rid of all the hooks into the product. This is a bad thing, to leave such clutter lying around. I thought it was just a problem in my pre-release build and that it would be fixed in RTM, but seeing that it won't even be in RTM makes me very uncomfortable and much less likely to recommend this feature set to my customers.

I got a VPC with SQL08 post-CTP6 from a Dev at the MVP Summit, and the name of the Collection Database had been mistyped as MSW instead of MDW. I tried to create a new database and drop the old one, and all my jobs started breaking. I then tried recreating a db of the original misspelled name and it still didn't fix things. That's when I started looking for a way to just remove Collection entirely and found there was no way to do it. This is not good.

Kalen Delaney
Posted by Microsoft on 4/10/2008 at 7:38 AM
Hi Lara,
     Thank you for submitting the connect issue for cleaning up the DC components, but we denied the request for the 2008 arelease. We will put together once we have all the data in place so that we can instruct users how to remove the components without causing future problems when users want to trurn it back on. We are defering the real fix until our next major release.
Thanxk you,
Bill Ramos