Symptoms

Data loss or performance issues might occur when changing the class of a configuration item or reclassifying a configuration item.

Release

Current versions and patches.

Issue Details

Cause

• If you change the Class of a CI, you might lose some field data that does not exist on the target table. For example, a Linux server has a field called Kernel Release that does not exist on the Solaris server table. If you change a CI from cmdb_ci_linux_server to cmdb_ci_solaris_server, any data in this Kernel Release field will be lost. You need to be aware of and account for issues like this before you make this sort of change.

• If you perform the Class change from the UI, due to Transaction Quota limits [sysrule_quota], the transaction might get canceled, which could lead to a loss of data.

Resolution

1. Choose a limited number of CIs to change the class in each step. (~20 to 40 CIs)

2. Write a scheduled job [sysauto_script] and properly fill in and execute the following script as an admin.

   Sample code:

   ChangeCIClass();
   function ChangeCIClass() {
     var lv_limit = 40; // We can have some restricted values like 20-40
     var lv_temp = 1;
   
     var gr = new GlideRecord('<<old_ci_class_name>>'); // Must not be cmdb or cmdb_ci
     gr.addEncodedQuery("<<custom_query>>"); // Your query that gives you the records for which you wanted to change the class.
     gr.setLimt(lv_limit);
     gr.query();
     while(gr.next() && gr.isValidRecord() && lv_temp &lt; lv_limit) {
       gr.sys_class_name = 'new_class_name';
       gr.update();
       lv_temp++;
     }
   }

    

Additional Information

For more information about transaction quota rules, see the following product documentation topics:

• Transaction quotas

• Configure a transaction quota rule

For more information about changing classes, see the product documentation topic Reclassify a CI.