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

Issues can occur if you change the Class Name [sys_class_name] for certain CIs in the CMDB (for example, cmdb_ci_linux_server to cmdb_ci_solaris_server

Cause

Note the following important things to know when running this task:

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

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

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:

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

Notifications