Tips for reducing instance database footprintInstructions Now Support (HI) Service Catalog Item - Database Footprint Any activities on your instance which trigger DML(INSERT, DELETE, UPDATE) on the database should be tried and tested on your SUBPROD instance for the actual Impact regarding functionality.Production instance performance while implementing this cannot be tested/benchmarked as we cannot mimic the PROD load while executing the activity on the SUB PROD instance as Subprods are instances with less transaction/traffic.Any such activities should be scheduled/planned for OOB hours on the PROD instance for minimising the impact.ServiceNow does not do data manipulation on the instance and there are various OOB ways to achieve this. A few of these are listed in this KB which provides an outline and overview of how this can be achieved by the Instance Admin - Mass-Deletion and Excess Data Management Recommendations Archiving Data archiving Archiving | General Overview - Support and Troubleshooting This is not an option to reduce to DB footprint. This will only reduce the number of records on the table from where you are archiving so the performance can be faster if OLD records are archived. As Archiving creates a new table with the ar_ prefix; there is no change happening to the DB footprint with this activity. "Archiving with Destroy Rule" will have an impact on DB footprint when the destroy rule takes place by deleting the data. ** Test on sub-prod before implementing on the production Table Cleaner Table cleaner can be set up to remove the data from the table. ** use this with caution Product Documentation How to use "Table Cleaner" to remove unwanted data Information Regarding Table Cleaner Check if table cleaner is working well and how much data a table cleaner rule deletes Options to track/contain table growth on important tables task Maintaining Task table Growth sys_audit_delete and sys_audit_relation Disable auditing of deleted records on a specific table A script to automatically clean up sys_audit_delete and sys_audit_relation records syslog* Search for any active properties with *debug on the sys_properties table and disable them if it is not needed. https://instancename.service-now.com/sys_properties_list.do?sysparm_query=nameLIKEdebug%5Evalue%3Dtrue&sysparm_view= This will reduce the logging because of this debug and reduce the Syslog data. This will not have any immediate impact on the footprint as the logging will be reduced and this should be visible from the next rotation cycle of Syslog Troubleshooting excessive logging (syslog) sys_attachment_* KB1228793 - Administering attachments KB0563399 - Managing Large Attachments - Best Practices KB0995336 - Attachments for potential deletion sys_audit data on the sys_audit table is retained forever. This table can be very huge on your instance. The best way to keep its control is to control what is Audited. This will be a purely organisational preference. sys_history* tables generate the data from the sys_audit table to show History when accessed from individual records. History sets - How are they generated Auditing and history sets | How they work together Exclusion list Auditing - How to activate/deactivate auditing for a specific table or field ** Removing data from sys_audit without a valid filter can create issues with the activity history of task records( incident, change, problem..etc) and CMDB records. So a blanket removal of sys_audit data older than a *datetime* can create data loss issues related to activity history missing. So any deletion activities for sys_audit need to be treated with caution and should be tested on a full copy of your PROD instance for impact. Also, this is one of the biggest tables on the instance and any DML on this will run for hours . Make sure you have the correct indexes in place before attempting it. cmdb@0024par1/cmdb$par* mySQL doesn't handle $ well.So instead of $, you'll see @0024 cmdb@0024par1 is cmdb$par1 cmdb$par* are the tables of cmdb used in the TPP table structure.As the data/columns grow on cmdb, cmdb$par1, cmdb$par2... cmdb$par* is created. More information on TPP is as follows:- The Table Per Partition (TPP) Extension ModelThis is a CMDB table and an integral part of the instance CMDB module. sh@0024table_name/sh$table_name ( Shadow tables) np@0024*/np$* (Snapshot table is created when a table is DELETED) When the records are deleted from a table, the sh$table_name table will be created and all the records will be saved there to be used; if you hit Rollback. Roll back and delete recovery There is a rollback expiration property(glide.rollback.delete.expiration_days) that will cleanse the table by creating a scheduled job "Clean Expired Rollback Contexts" If your instance has frequent table_name record deletion, the sh$table_name table will stay there forever as new data will be coming in before reaching its expiration and that info will be appended to the same sh$table. Deletion of that table is not a good idea if you are looking to Rollback the deleted data. You can try the steps on Remove Shadow tables Additional InformationRelated KB's How to recover deleted data from ServiceNow instance. Dataloss on sub production or non production instances