WSUS hangs on Cleanup wizard for Unused Updates, then disconnects from console.

Question

I am running WSUS 3.0 SP1 on Windows 2003 and recently have found that running the Cleanup Wizard works with all of the selectable options except the "Unused Updates" option. It hangs about 1\2 way through and then disconnects from the console. Up until now it has worked.
I am using the Windows Internal Database and the size of the MDF is 3193024kb.
Everything other than this wizard is working fine. Please help.

Answer 1

It does not run much better when written without a CURSOR. I modified it to use a WHILE loop and it deletes about 1 per minute here which is the same as the old code with a CURSOR.
Not surprised. To be frank, using a WHILE LOOP just turns it into a manual CURSOR, making it no better off than using the CURSOR construct in T-SQL. The correct approach here is to write the code with a SET-BASED approach. Unfortunately, as you're about
to see.. sometimes there are scenarios just too complex to do with a set-based approach.
In order to use the set-based approach, you'll need to take the code from spDeleteUpdate and modify it to join directly to the table of GUIDs to delete. Execute the whole thing in *one* DELETE statement.
Of course, part of the other problem that contributes to the performance issues is that spDeleteUpdate *ALSO* uses CURSORs.... <sigh>, and a subprocedure. spDeleteUpdate retrieves a list of RevisionIDs, and then calls spDeleteRevision for each of those
RevisionIDs. (And as we've already seen, some updates may have a large number of RevisionIDs.) spDeleteRevision is where the real work is done.
At the crux of that proc, are deletes from these tables:
dbo.tbEventInstance (this will be a time killer as well, depending on how many clients affected a given update, and how much activity surrounded that update)
dbo.tbDeployment
dbo.tbUpdateStatusPerComputer
dbo.tbProperty
dbo.tbFlattendedRevisionInCategory
dbo.tbRevisionInCategory
dbo.tbRevisionLanguage
dbo.tbMoreInfoURLForRevision
dbo.tbSecurityBulletinForRevision
dbo.tbKBArticleForRevision
dbo.tbBundleDependency
dbo.tbBundleAtLeastOne
dbo.tbBundleAll
dbo.tbPrerequisiteDependency
dbo.tbInstalledUpdateSufficientForPrerequisite
dbo.tbPrerequisite
And all of the associated transaction wrappers and error checking for each and every deleted row from each of those tables to ensure continued data integrity in the database.
So while the code above making a simple call to spDeleteUpdate looks quite simple on the surface... underneath the covers there's a LOT of activity going on to make that one update get deleted.
If you wanted to speed it up... you'd need to use spGetObsoleteUpdatestoCleanup to get a list of UpdateIDs, then build a list of RevisionIDs from that, and then join that temp table of RevisionIDs to each of the -15- tables above, and delete from all -15-
tables simultaneously. Which would force all of those deleted records into a SINGLE transaction, and probably whatever gains you got from switching from procedural logic to set-based logic would be lost in the massive overhead of managing a transaction of
that size.
A possible compromise would be to execute a set-based DELETE by UpdateID, so you'd capture the RevisionIDs for a given UpdateID, and then delete across all -15- tables for that short list of RevisionIDs (except where that list ain't so short). But still,
this compromise might well speed things up, as the loop for UpdateIDs is likely only measured in the hundreds, where as the loop through all RevisionIDs is sometimes measured in the thousands or tens of thousands (depending on if/when the server was last purged).
Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
SolarWinds Head Geek
Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
http://www.solarwinds.com/gotmicrosoft
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.