Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field
Hi there,
Keeping your instance database footprint tidy? Reducing instance database footprint? An important subject, though actually a subject that barely gets attention. Barely if you search for any content, hardly any replies when reaching out on ServiceNow Community/LinkedIn/Slack/etcetera, and to be honest: also if you look at customers in general... so much focus on Development, so little (or almost no) focus on Platform or System Administration. Also there is not a single ServiceNow course that goes in depth on this subject.
So why is this such an important subject? ServiceNow runs in the cloud, right? Sure (unless you are on-prem of course), though that doesn't mean ServiceNow does everything for you! Keeping your instance database footprint tidy and reducing the database footprint, will have several positive effects: Performance gain, slimmer and optimized tables, less future manageability or technical depth, shorter system clone time (or time to place backups back in case of emergencies!), avoiding licensing implications if your database footprint gets over 4 TB, etcetera.
In the upcoming weeks, I will share several blogs regarding reducing your instance database footprint and keeping your instance database footprint tidy. All based on experiences gained in the field, at several customers, after collaborating with ServiceNow Support, investigating myself, etcetera.
If you have any thoughts yourself on this subject, don't hesitate to share!
Topics in this series of blogs (I will update this section when publishing new blogs):
- Maintain Audit Delete and Audit Relation
- Maintain Attachments and Attachment Documents
- Activating/adding Table cleaners
- Reduce (over)auditing
- Lower duration Table Rotation
- Drop syslog_trans_prejakarta* tables
- Cleanup Shadow tables
Table Rotation
Tables like Log [syslog], Transaction Log [syslog_transaction], and other extends from Log can hold a massive amount of records and contribute significantly to the Database Footprint size. You might know that some tables like Log are automatically being cleaned up, or that data is at least kept for a maximum number of days. Do you actually know the exact numbers for this? What is the number of days that would suit your company, for keeping data like Log? Did your company purposely configure this or is it simply still the out-of-the-box value as it was when your instance was configured years and years ago?
For the majority of companies the number of days Log is kept for, is simply the out-of-the-box value. While actually asking around, I haven't come across many customers who mentioned a number that exactly matches the out-of-the-box value for which they would like to keep the Log for. On a LinkedIn pole I created recently, about 60% of the respondees also mentioned keeping Log for 1 or 2 weeks would be preferable.
If Table Rotation is a new subject for you, the ServiceNow Docs has a page with a high-level description:
Table rotation
Database Footprint
Here is an example of how the Database Footprint for tables like syslog, syslog_transaction, syslog_app_scope looked like for one of my customers:
Only the three syslog tables are already good for almost a Terrabyte of data. Obviously this will differ for every customer.
There are a lot more tables (also syslog extends) that are on Table rotation, though those are usually not contributing that heavily to the Database Footprint.
Lower duration Table Rotation
Out-of-the-box syslog and syslog_transaction are configured for type Rotation, with 8 Rotations, and a 7 days Duration. While one of the rotations will be offline, and one of the rotations is the upcoming one, effectively you have 6 rotations of 7 days. So the syslog and syslog_transaction is kept in your instance for a maximum number of 42 days!
If you want to lower the duration of the Table rotation, navigate to:
- System Definition > Table Rotations
- Select the Table you are after
- Update the Duration
When changing the Duration, for example by lowering it, be aware that your change will not be fully effective immediately. On the Table Rotation Schedule only the current rotation table and the upcoming rotation table are updated immediately.
For the customer the example shown was from, we lowered the duration of the Table rotation to 2 days. This ensures that at least 13 days and a maximum of 14 days of syslog records are being kept in the instance. The number of rotations was left untouched, though you can update that also.
Result
Only by adjusting the duration of the Table rotation for syslog, syslog_transaction, and syslog_app_scope for this customer, the total number of Gigabytes on the Database Footprint went down from 931.12 GB, to 243.23 GB. A reduction 687.89 GB with such a small configuration change!
Obviously you might decide to go for a different number, higher like 30 days, or even lower like 7 days. Or perhaps you want to differ this over your instances? Since all instances contribute to the Database Footprint size licensing.
---
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
4x ServiceNow Developer MVP
4x ServiceNow Community MVP
---
1 Comment
