DTS Job / Resolved Alerts NOT grooming

 Hi,

We are currently seeing alerts in the Ops Console that are over 400 days in a resolved state.

The DTS job has been running successfully, however i have noticed that in the "GroomingSettings" Table, the TimeDTSLastRan is showing as 13/02/2007!!  I have also noticed that in the ReportingSettings the TimeDTSLastRan date is showing as 25/06/2008!

Where are these dates obtained from, and how is it possible for the DTS Job/stored procedures to run successfully yet these dates not get updated?

Is the grooming NOT happening BECAUSE of the dates i.e. the job itself has run without error, but is not actually performing any grooming?

If so, is it safe to manually amend these dates, or is there a safer procedure that i can run that will update this in a cleaner way?

Any help on this would be appreciated, as we currently have almost 500,000 resolved alerts in the OnePoint DB!

Thanks

Andrew

 The ReportingSettings TimeDTSLastRan value of 25/06/2008 is the date that MOM thinks the DTS package last ran succesfully. That would be about 400 day (give or take) form 30/07/2009 when you posted.

MOM won't Groom anything from OnePoint newer than this date as it "Thinks" the data has not been passed to the DW DB since this date.

It looks like your DTS is not running correctly and hasn't since 26/06/2008.

 Yeah, it would appear that running the job with a latency setting has an effect on the date recorded.

Because we had hundreds of thousands of alerts not groomed, i tried to do a latency of 400 (as we had alerts over 500 days old not groomed) in the attempt to reduce the impact, and this is the reason why the date was 400 days prior in the DB!

We usually run the DTS job with a latency of 3, and have since noticed that the date in the DB is always 3 days prior to when it was actually run.

We ended up running some other jobs that cleared out all of the alerts manually, but we also had loads of alerts that were resolved but had no resolved date, so putting dates in to these alerts also helped and then they suddenly got groomed out on the next DTS run.

Don't quite know why there were no resolved dates or resolved by data, but looks like that was also stopping them from getting groomed out.

Anyway, we are now down from 500,000 alerts awaiting grooming to around 9,000, which is about normal for 3 - 6 days worth of grooming for us.  We are monitoring 1200 servers, so it does get quite busy :-)

It now seems to only be grooming 6 days old, as i suspect it is grabbing a 3 day old run time and then also knocking off the default of 3 days also that we have set in the Admin.  Definately better than it was though!

Thanks

Andrew