Hi Guys,
For the past few weeks I have been receiving this alert "Stale State Change Events detected in OpsMgr database" and have been executing the SQL query to clean up this manually.
But as this is looking to be a pattern I started to do some investigation on how this alert is generated and why I was getting this.
So this rule comes from Tao Young's OpsMgr Self Maintenance Pack: http://blog.tyang.org/2013/03/03/opsmgr-self-maintenance-management-pack/
I then checked the MP xml for how this was detected and found the following two SQL queries:
select DaysToKeep from PartitionAndGroomingSettings Where ObjectName = 'StateChangeEvent'
SELECT DATEDIFF(d, MIN(TimeAdded), GETDATE()) AS [Current] FROM statechangeevent
The first query gets the grooming setting (in my case 14 days) and the second returns the number of days since the oldest entry (when I ran it last I got 22 days). A comparison is done and alert is generated if there are N+1 more days of data which should have been groomed. So the alerts are legitimate.
The issue I have is that the Stale State change events are not being removed automatically until I manually removed them (using the query supplied in the alert knowledge base).
I manually run the stored procedure "Exec p_PartitioningAndGrooming" but this does not clean up the events.
My question is, what is responsible for cleaning up the state change event? Is it "Exec p_PartitioningAndGrooming" If so why wouldn't it be working?
Cheers,
Martin
Blog:http://sustaslog.wordpress.com LinkedIn:Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.