Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
Hi there,
"ServiceNow has created an automated workflow to request the database footprint of an Instance via a Service Catalog which is completed using end-to-end automation. Customers can view the total space occupied by the Instance along with up to the top 100 tables that contribute to the occupied space." While this database footprint could be really insightful, the vast majority of people within the ServiceNow eco-system have never seen a database footprint. Not a strange thing, since serious System Administration of ServiceNow Instances is hardly done at companies.
Through this blog, I will try to give a bit more attention to the database footprint which you can obtain from ServiceNow Support. And... it's free!
Note: The images used in this blog are slightly edited to prevent actual company information from being shared.
Enquire database footprint from ServiceNow Support
If you are granted proper access for your company to the ServiceNow Support website (customer_admin or partner_admin), you can request database footprint insight by following the below steps.
1. After logging in to the ServiceNow Support website (formerly known as "HI"), use the search bar to search for "database footprint". If you have the proper access to the company's account, one of the (top) results should list "Database Footprint".
2. From here it's a fairly simple process. Just select which company Instance you are after and how many "Number of largest tables by size" you would like to retrieve. The number varies from 10 to 100. Since this is a real-time calculation of the table size, selecting more tables will take more time to fetch results.
3. Depending on the number of selected tables, after a few seconds or a few minutes you will be prompted with a list containing table names and their size in gigabytes.
Exploring the database footprint results
The list of table names and their size in gigabytes by itself could be really insightful. Just looking at the list of table names and their size in gigabytes gives you a feeling about your Instance size, the largest tables, and unexpected tables. Though there's more to learn from this. Here are a few examples of what I encountered and customers:
- Analyzing the Attachments table, for one customer more than 30% of all Attachments concerned records with an empty and/or invalid Table name and/or Table sys ID.
- Analyzing the Audit table can be a bit painful task due to the performance involved, though could give you insights into tables being audited which aren't useful, old records for tables that have been deleted, etcetera.
- The list of table names also mentions tables like "syslog_trans_prejakarta". These are left-over tables from a rebuild ServiceNow did with the Jakarta release. Removing these tables can be addressed at ServiceNow Support.
- Analyzing the Question Answer table, there will be a few percent of records with an invalid Table name and/or Table sys ID.
- Analyzing the Question Answer table, when grouping on Table sys ID you will notice some huge numbers. This could point you to Record Producers with a very large number of Variables. In some cases the Record Producers simply need to be simplified, in some cases it might be older Record Producers which would be better off using Multi-Row Variable Sets.
- The list of table names also mentions shadow tables (starting with "sh@"). While this could be valid, in some cases these are tables that should have dropped automatically though somehow didn't. This can be addressed at ServiceNow Support to look into.
- Analyzing the Audit Delete table could show that this table never had any cleanup. The Audit Delete table is used to store information about deleted records. Unchecked, this table can grow very large and can cause wider performance issues within a ServiceNow Instance. You could wonder up to what time period this would be useful. ServiceNow Support mentions in a support article a period of two years, though this might be even shorter for your company.
- Scrolling through the list of table names, you might notice tables that are empty though do mention several gigabytes. For example old Import Set Row extended tables. Optimizing these tables or perhaps old unused Import Set Row extended tables could be deleted.
- Looking at the number of gigabytes, some tables might feel fairly large considering the purpose of the table. This could be due to tables exploding at a certain point in time due to an Incident or incorrect development, or perhaps the data was already cleaned though the tables were not optimized. For example syslog tables, or in my case the scan_finding table due to some incorrect Scan Checks 🙂
Recap
The database footprint and the list of table names and their size in gigabytes can give you more feeling about your Instance size, the largest tables, and unexpected tables. Insights that can bring severe issues on your Instance to the surface which need attention. It's up to you what you do with the database footprint.
In this blog I "only" shared nine examples of what you could take out of the database footprint. I've used these examples also to create new Instance Scan Checks which I have been able to use for several customers. Using to improve the Instance health, taking severe issues away, and eventually reducing the database footprint.
I am sure you can get even a lot more out of the database footprint than the nine examples that I have shared!
---
And 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? |
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
8x ServiceNow MVP
---
1 Comment
