Mark Roethof
Tera Patron
Tera Patron

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Hi there,

 

Instances where Event Management is installed might be using the Impact Graph table [em_impact_graph]. This table is for "Impact tree of CIs containing CI hierarchy and impact rules to be used for impact calculation." Depending on your instance usage, since the Utah release this table is growing very rapidly. For one customer I even noticed a daily increase of 5-6 GB. Since upgrading to the Utah release, the table grew from almost nothing up to 400 GB in just over two months!

 

Good news, the rapid growth of the Impact Graph table was caused by an out-of-the-box issue. For this there is a workaround and even better, it's fixed with Utah Patch 5. Be aware though... the fix does not fix everything!

 

Description

- "It is observed that there is a huge number of records present in the em_impact_graph table with the status as Deleted but the actual record is not getting deleted."

- "The number of records is getting added regularly thus causing issues. This is seen after the introduction of a new scheduled job "Event Management - Clean Impact Graph Table" in Utah version."

 

The Related ServiceNow Problem is PRB1676869.

 

Workaround

While the issue is fixed with Utah Patch 5, your instance might not be on this Patch yet. If so, in order to fix this issue you can add a new System Property. After adding the System Property, slowly the number of records in the Impact Graph table will be cleaned up. 

 

Name: evt_mgmt.impact_calculation.cleanup_age_seconds.em_impact_graph
Value: 7200

 

"The fix does not fix everything"

I'm not writing a short article for every ServiceNow Problem that gets fixed. So why doing so now? The actual reason why writing an article this time, is to try to make customers facing the above issue aware that the origin issue is fixed (or you can apply a workaround), and that the data is cleaned up, though... you do need to have the table optimized! Without doing so, the table will still have a poor performance and the table size in gigabytes will stay unnecessarily big (and if you exceed the contractual number of gigabytes, it might involve costs).

 

In theory you can rebuild the table yourself in a few ways (I've mentioned those in earlier articles/blogs). Better though, involve ServiceNow Support to have the table optimized. Most likely ServiceNow Support will actually opt for rebuilding the table.

 

So again: you do need to have the table optimized! Do so, by raising a ServiceNow Support Case.

---

 

That's it. Hope you like it. If any questions or remarks, let me know!

 

C

If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful.

 

Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in?
- Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

 

Kind regards,


Mark Roethof

Independent ServiceNow Consultant
4x ServiceNow Developer MVP

4x ServiceNow Community MVP

---

LinkedIn

Version history
Last update:
‎07-30-2024 09:53 AM
Updated by:
Contributors