Re-parenting of cmdb_ci to cmdb during an upgrade to pre-Kingston can cause data loss on unique composite indexes that span fields that end up separated after the reparenting. An example:

  • pre-upgrade > unique index cmdb_ci(column a, column b) exists
  • during upgrade cmdb_ci is reparented leaving column a on cmdb (base table) and column b on cmdb_ci
  • the unique index is no longer applicable as the columns are not on the same table and this process can lead to data loss

Example of an affected unique composite index is: cmdb_ci(serial_number, model_id)

Steps to Reproduce

1. Zboot fuji
2. Add unique index on cmdb_ci(serial_number, model_id)
3. Add rows that have the same serial number
4. Upgrade to Geneva or a later version pre-Kingston
 > You'll be missing some rows, and should be able to find the missing rows via:
select sys_id from cmdb where sys_id not in (select sys_id from cmdb_ci)


To prevent this issue on pre-Kingston instances:

  • Contact Customer Support!  They will need to drop any affected unique composite indexes on cmdb_ci before the upgrade from Fuji (or earlier) to a later release
  • To restore the index after the upgrade Customer Support will need to ensure that the targeted columns are both on the same table.  If they were separated during the upgrade the columns will need to be promoted to the same table (this action will require Customer Support)

Is there any impact when this index is dropped? There is no performance impact while dropping an index.  Additionally, unique indexes are put in place to ensure uniqueness of the combination of fields involved, not to provide performance value for queries running. After the upgrade, the index that was dropped should be re-added.

Related Problem: PRB672996

Seen In

Eureka Patch 11 Hot Fix 2
Eureka Patch 13 Hot Fix 2
Geneva Patch 7
Helsinki Patch 1
Helsinki Patch 2

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-05-21 11:35:43