Clean up sys_upgrade_history

[Karine_M]

Hi,

After updating a plugin, I can find the changes applied in the sys_upgrade_history table. It is then possible to process the changes_skipped in the same way as during an upgrade.
I realize that this information is deleted after X days. Only the information related to the plugins or the application of update set is deleted. The data related to version upgrades remains available.

Do you know what process deletes this data? (I would like to at least extend the retention period of this data on our non production instance).

Regards,

Karine

[a5hubh]

In ServiceNow, the retention period for data in the sys_upgrade_history table, particularly data related to plugins or the application of update sets, is controlled by a scheduled job that periodically cleans up old records. The specific process responsible for deleting this data is typically a scheduled script execution or a scheduled job.

To manage or extend the retention period of this data, you need to identify and modify the scheduled job responsible for cleaning up the sys_upgrade_history table. Here’s how you can do that:

Identify the Scheduled Job

1. Log in to ServiceNow with an account that has admin privileges.
2. Navigate to Scheduled Jobs:
   • Go to System Definition > Scheduled Jobs.
3. Search for Cleanup Jobs:
   • In the search bar, type keywords like "cleanup," "sys_upgrade_history," or "history" to find the relevant scheduled jobs.
4. Identify the Relevant Job:
   • Look for scheduled jobs that are responsible for cleaning up the sys_upgrade_history table. Commonly, the job might be named something like "Upgrade History Cleanup" or similar.

Modify the Scheduled Job

1. Open the Scheduled Job:
   • Click on the name of the scheduled job to open its details.
2. Modify the Schedule:
   • Adjust the schedule to run less frequently if you want to retain the data for a longer period.
3. Adjust Retention Period:
   • If the scheduled job uses a script, inspect the script to find the retention period. Look for lines of code that specify conditions for deleting records, such as records older than a certain number of days.
   • Modify the retention period as needed.

Example of Adjusting Retention in Script

Here’s an example of what a cleanup script might look like and how you can adjust the retention period:

var gr = new GlideRecord('sys_upgrade_history');
var retentionPeriod = 30; // retention period in days
var dateThreshold = new GlideDateTime();
dateThreshold.addDays(-retentionPeriod);
gr.addQuery('sys_updated_on', '<', dateThreshold);
gr.query();
while (gr.next()) {
    gr.deleteRecord();
}

To extend the retention period to 60 days, you would change:

var retentionPeriod = 30;

to

var retentionPeriod = 60;

Save and Test

1. Save the Changes:
   • After making the necessary adjustments, save the scheduled job or script.
2. Test the Changes:
   • Verify that the changes are effective by checking if the sys_upgrade_history records are retained for the new period.
3. Monitor for Issues:
   • Ensure that the system continues to perform well and that no unexpected issues arise from retaining the data longer.

Additional Considerations

• Non-Production Instances: Since you are concerned about a non-production instance, ensure that any changes do not negatively impact the performance or storage capacity of your instance.
• Documentation: Document any changes you make for future reference and for the benefit of other administrators who might manage the instance.

By following these steps, you can extend the retention period of the data in the sys_upgrade_history table on your ServiceNow instance, ensuring that you have access to historical data for a longer duration.

If the above information helps you, Kindly mark it as Helpful and Accept the solution.

[Mark Manders]

Instead of posting an AI generated answer without validating if it's correct, can you please check it before you post it? The question was how this is done OOB and you provide a way to search for how it could be done, which doesn't lead to any script that is handling this. 

Please don't present AI answers without checking it yourself.

[James Fricker]

Goto this table

sys_job

And lookup this name

"Upgrade History Cleaner"

It is a java job (not javascript). So the source is not available to owners of cloud instances.

There is a schedule for it in sys_trigger

Look for

job_id.name=Upgrade History Cleaner

/sys_trigger_list.do?sysparm_query=job_id.name%3DUpgrade History Cleaner

One thing you can do is create a clone cleanup script to disable the schedule on sub-prod instances. So the only time it will be cleaned is when the instance is cloned again.

[James Fricker]

Here is the clone cleanup script I have just written. As I would like to retain all upgrade history on a sub-prod instance between clones.

new global.GlideQuery("sys_trigger")
    .where("job_id.handler_class", "com.glide.update.UpgradeCleaner")
    .deleteMultiple();