Best practices for purging/archiving 800M records from the sys_audit table?

[AbhishekK010747]

Hello ServiceNow experts,

We are currently facing a massive data volume challenge in our production instance. Our sys_audit table has grown to approximately 800 million records, and it is severely impacting our database performance and storage.

We need to purge/clean up this table, but given the sheer volume, we want to ensure we do it safely without locking the database or crashing the instance.

I have a few questions for the community:

1. What is the safest, recommended approach to purge or archive data from sys_audit at this scale?
2. Should we use standard Archive Rules, Table Cleaners, or request a backend deletion from ServiceNow HI Support?
3. What are the performance implications or risks we should watch out for during this process?

Any step-by-step guidance, scripts, or lessons learned from anyone who has tackled audit data at this scale would be greatly appreciated!

Thanks in advance!

Abhishek Kannawar

[RobbertT]

With 800M+ sys_audit records, I'd avoid bulk deletes directly in production. The safest approach is to review your data retention policy, test archiving/purging in a sub-production instance first, and then work with ServiceNow HI Support for a backend strategy if needed.

[Pavan Srivastav]

The sys_audit table logs all field-level changes, which quickly scales in environments auditing high-volume records (task tables, CMDB). Improper removal (e.g., large SQL deletes) can lead to database lock, severe performance degradation, or system-wide outages.

---

✅ Supported Cleanup Strategy

ServiceNow strongly recommends using built-in, throttled tools, rather than backend deletions or manual scripts:

1. Use Table Cleaning Jobs (Preferred)

• Configure OOB job for sys_audit with a retention policy (e.g., keep last 90–180 days).
• Jobs execute in batches, minimizing locking risk.
• Run during off-peak hours.

2. Use Archive Rules (Optional)

• Moves older records to archive tables for compliance.
• Note: Archiving does not immediately reduce DB size—purging does.

3. Test in Sub-Production First

• Validate purge job runtime.
• Monitor DB locks and I/O behavior before running in production.

---

✅ Important Precautions

• Do NOT request backend deletions:
  ServiceNow cannot perform mass removal due to complex data relationships and compliance.
• Expect gradual space recovery:
  Actual DB shrink occurs during maintenance, not immediately after purge.
• Cleanup may span weeks or months for large datasets due to throttling.

---

✅ Performance Risks

• Direct DELETE operations on sys_audit can:
  • Lock tables permanently.
  • Cause instance downtime.
• Always use OOB scheduled jobs for safe execution.

---

✅ Recommended KBs

• KB0623054 – Release Support Lifecycle
• KB0717987 – Managing Audit Data Growth
• Archive Rules and Table Cleaner Best Practices