A while back i got an alert that system drive on one of our monitored servers was full. When examining what was consuming disk space I noticed that HealthServiceStore.edb, located in the agent’s Health Service State folder was way to large.
HealthServiceStore.edb is where the result of every workflow that runs on this agent is stored and sent to your Management Server(s). An agent running a lot of performance counters (Exchange, SQL etc) will probably have a larger database file than your average file server.
At first, i tried to flush the agents cache wich did not work. The next thing i tried was to run the “online store maintenance” task from OpsMgr console, this task will run a de-fragmentation of the database file.
You can follow the result in the event log, HealthService (7404) Health Service Store: Online defragmentation is beginning a full pass on database ‘<C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\HealthServiceStore.edb>’.
Did this work? No, my database file was still huge.
The next thing to do, is to perform a “Dirty Defrag” on the DB file. To do this,
- open your favorite shell and navigate to C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store
- Stop Healthservice.exe (Microsoft Monitoring Agent)
- Run esentutl /r edb (recovery mode)
- Start defragmentation by running esentutl /d HealthServiceStore.edb
Your healthservicestore.edb should now have a normal size.
Do you have anything to include, please comment.
*All post are personal
Latest posts by Martin Ehrnst (see all)
- Using OMS and Azure Functions to restart Azure Web App - 16/06/2017
- SCOM 2016 migration – Transfer alert Ticket ID - 12/06/2017
- Update: SCOM web API - 02/06/2017