CMDB Data Manager Archive Policy stuck at 93.95% / Sub-tasks pending
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago - last edited 2 hours ago
Hi all,
I am running a CMDB Data Manager Archive policy in our DEV environment to archive retired Network Adapter CIs. The initial target scope was approximately 900,000 records.
The policy is processed automatically through the out-of-the-box scheduled job “CMDB Data Manager Archive/Delete Policy Processor.”
What We Tried
To improve performance , we modified the system property glide.db.archive.chunk_size and increased its value to 25,000.
However, after running the processor , no records appeared in the Archive Job Execution Chunks (sys_archive_run_chunk) table related to this Archive data manger poilicy. The execution successfully archived the vast majority of records but stopped at 93.95% completion, leaving approximately 2,100 records in the live table. In the backend Policy Execution Instance (cmdb_data_management_policy_execution), the execution appears to be stuck, with five sub-tasks remaining in a Pending state in the Policy Tasks (cmdb_data_management_task) table.
We would like to understand whether this behavior is related to the chunk size configuration, stuck policy tasks, or another issue within the archive processing mechanism.
Please help me with the following:
What is the recommended approach for implementing and successfully completing a CMDB Data Manager Archive policy when processing a large volume of CIs (approximately 800,000 records)?
What troubleshooting steps should we follow to identify why approximately 2,100 CIs remain unarchived? How can we determine whether the issue is related to individual CI records, policy conditions, data inconsistencies, or stuck policy tasks?
What could be the possible reasons for no new records appearing in the Archive Job Execution Chunks (sys_archive_run_chunk) table when the scheduled archive processor runs? How can we identify the underlying cause?
What is the safest, ServiceNow-supported approach to recovering a policy execution instance when some policy tasks remain in Pending status? How can we resume processing without compromising the existing execution history or causing duplicate archive operations?
If we revert glide.db.archive.chunk_size to its default value of 1,000, how can we safely trigger the Data Manager engine to re-evaluate and process the remaining 2,100 CIs and complete the existing execution?
Are there any documented platform limitations, recommended chunk size values, database transaction limits, or timeout considerations when processing large archive volumes? Could increasing the chunk size significantly affect archive execution?
Any guidance on the recommended troubleshooting and recovery steps would be highly appreciated.
Thanks in advance!
