Update sets containing new columns in the CMDB hierarchy can sometimes result in storage alias corruption, where the same column is mapped to different internal column throughout the hierarchy.
The primary symptom of this issue is inconsistent data throughout the hierarchy. For example, let's say you have u_my_column on cmdb_ci_hardware. The column would be cloned to all descendant tables, including cmdb_ci_server and many others. If affected by this PRB, the column may have a different mapping on cmdb_ci_server than it does on cmdb_ci_hardware. Thus, for any given record, you may have one value in cmdb_ci_hardware.u_my_column and an entirely different value in cmdb_ci_server.u_my_column.
Steps to Reproduce
- Create a new scoped application
- In this application, create a new dictionary field on the cmdb_ci table
- Publish the application to an update set
- Retrieve and commit the update set on another instance
- Check the sys_storage_alias table and observe the mappings for the new column are highly inconsistent
Reach out to ServiceNow support for assistance on this issue. If there is no data in the affected column, or if the data in the column is not needed, there is a relatively simple solution that can be implemented. However, if important data already exists in the column, a thorough analysis will need to be conducted in order to determine the best solution.
Related Problem: PRB1320719