How to manually execute WorkItem Grooming in Service Manager

IMPORTANT: Allways perform a FULL Backup of the database before doing anything to it !!!

ALSO: It is advised that you open a case at Microsoft before doing this - directly editing the database is not supported and you may find yourself in an unsupported state if anything goes wrong.

There are situations where Grooming for some or all WorkItem types may fail because of the fact that there are just too many entries to delete and the job takes more than 30 minutes (Workflow TimeOut) to complete. This may happen in some situations but the most common one is where the default grooming settings for the different WorkItems was changed and set too high for the environment to handle.

In these situations you might need to manually run the Grooming Workflow (SQL Stored Procedure) for all or some WorkItems types.

The SQL Query below should be executed on the ServiceManager database and it will manually groom all WorkItem types that are older than 365 days (1 year) *and* are Closed. More on how this works here: http://blogs.technet.com/b/servicemanager/archive/2009/09/18/data-retention-policies-aka-grooming-in-the-servicemanager-database.aspx

Now if you want to adjust the Grooming Threshold in the Query (currently @ 365 days => 60 minutes * 24 hours * 365 days = 525600) then please calculate this (60 minutes * 24 hours * X days to keep) and change this in the Query for the @RetentionPeriodMinutes variable.

Also, if you don't want to do this for *all* WorkItem types in one execution, or you want to run this for different types with a different Grooming Threshold (@RetentionPeriodMinutes variable), then please feel free to remove the names of the WorkItem types from the Query below - be careful with the comma "," there after each WorkItemtype-name so that the Query remains valid.

 DECLARE
   @ManagedEntityType AS UNIQUEIDENTIFIER,
   @GroomingCriteria AS NVARCHAR(MAX),
   @RetentionPeriodMinutes AS INT,
   @BatchSize AS INT
 SET @RetentionPeriodMinutes = 525600
 SET @BatchSize = 10000
 DECLARE GroomingToExecute CURSOR LOCAL FORWARD_ONLY READ_ONLY FOR
   SELECT ManagedTypeId
   FROM ManagedType WITH(NOLOCK)
   WHERE TypeName IN (
      'System.WorkItem.ReleaseRecord',
      'System.WorkItem.Incident',
      'System.WorkItem.ServiceRequest',
      'System.WorkItem.ChangeRequest',
      'System.WorkItem.Problem'
   )
 OPEN GroomingToExecute
 FETCH NEXT FROM GroomingToExecute INTO @ManagedEntityType
 WHILE @@FETCH_STATUS = 0 BEGIN
   SET @GroomingCriteria = (
      SELECT Criteria
      FROM MT_GroomingConfiguration WITH(NOLOCK)
      WHERE TargetId = @ManagedEntityType
   )
   EXEC p_GroomManagedEntity @ManagedEntityType, @RetentionPeriodMinutes, @GroomingCriteria, @BatchSize
   FETCH NEXT FROM GroomingToExecute INTO @ManagedEntityType
 END
 CLOSE GroomingToExecute
 DEALLOCATE GroomingToExecute 

I highly recommend setting the Grooming Thresholds as low as possible/allowed in the SM Console because you have the data for these items in the Data Warehouse database for a very long time anyway.

Also, another great recommendation is to lower the Grooming Threshold for the internal JobStatus and WindowsWorkflowTaskJobStatus history data as explained and described here: http://blogs.technet.com/b/servicemanager/archive/2010/12/07/more-aggressively-grooming-the-jobstatus-and-windowsworkflowtaskjobstatus-tables.aspx

Well - the database can breathe better now, eh? :D