DIY: Keep your instance tidy - Support and Troubleshooting

DIY: Keep your instance tidy Description  DIY: Keeping an instance tidy

Overview An Incident by our Support team might be received regarding disk space issue with your instance. It is case by case and a detailed plan is provided for you. To keep an instance tidy: Code cleanup Print message while developing keeps work on track and easier for troubleshooting. Once completed, cleanup the print statement such as gs.log() or gs.print(). If a loop is printing 50 lines per run, having that Business Rules run around the clock fills up log tables quickly. Similarly, with "Session Debug" turned on for troubleshooting, turn them off when done by clicking Disable All . Here is a KB to reference regardingSession Debug: https://docs.servicenow.com/csh?topicname=c_SessionDebug.html&version=latest Error message Similar to code cleanup, if an import job throws thousands of errors/warnings per run, it is best to take care of it to have an error free job, but also keeping the log tidy. Over Auditing The sys_audit_delete table holds the deleted record. It can be common to clean some tables within sys_audit_delete where those records are not required. The most common usage is a lot of deletes on audited tables due to Discovery running have been performed. Sometimes you do not realize that they have an audited table, and data can build and not be required. Normally Support initiates the cleanup for sys_audit_delete and sys_audit_relation tables but you can always check your audit requirement and take off unnecessary audits. History (sys_history_line) This table is used to cache recently accessed audit data, which provides a performance benefit against going to the sys_audit tables directly. Consider having it on Table Cleaner for 30 days. Here is a KB regarding Table Cleanup for reference: https://docs.servicenow.com/csh?topicname=c_DataManagement.html&version=latest Report Summary Line (sys_report_summary_line): This table holds data related to custom charts. When the system builds a custom chart, it dumps data into this table such as chart colors and the like. The data stored in this table is just temporary data and can be completely wiped out. This cleanup frees up space in DB and in turn helps improve performance when accessing any other large tables, such as cmdb_baseline_entry. Consider having it on Table Cleaner for 30 days as well. Report view (report_view) This table tracks the reports of who has viewed what and when, and might also cause performance issues as reports are running (especially on any home pages as well). This data is not necessary to keep. Consider having it on Table Cleaner for 30 days as well. Import Set tables These are staging tables, once the Transform Map process is done, they are just temporary data. It depends on the need/requirement, have Import Set Deleter job running on a more frequent schedule to avoid performance issues and also keep those tables small. For more information, see the product documentation topics Custom chart data generation and Custom chart rendering.