Archiving many cmdb_ci distinct tables can lead to slow cmdb_ci list loading, such as affected CI's in change_request.

Steps to Reproduce

1) Activate the data archiving plugin.

2) Create a change request and add affected CI's that are records in the cmdb_ci_aix_server and cmdb_ci_spkg tables, for example OOB demo records "SAP AppSRV01" and "3Com DMI Agent" respectively.

3) Create two archive rules on the two distinct cmdb_ci* hierarchy tables each added to the change request from 2 above. The "SAP AppSRV01" and ""3Com DMI Agent"" records should get archived so you can use the "name" field to archive these records.

4) Run the archive job.

Observe several "Get for non-existent record" in the localhost log. This will grow rapidly the more cmdb_ci distinct table records you archive.


This problem is under review and targeted to be fixed in a future release. You can Subscribe to this article to receive notifications when more information will become available.

As a workaround, set the "System Settings/Forms/Related list loading" to "On demand". That will defer the loading of the slow related list, so the main form can be visualized quicker.


Related Problem: PRB1184294

Seen In

SR - ITOM - CMDB CI Class Models - 201907
SR - ITOM - Discovery and Service Mapping - v1.0.35
SR - ITOM - Fundamentals Istanbul Jakarta Kingston r1 - v5.99.6
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3

Fixed In

Orlando Patch 2

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-08-26 11:52:12