Description
Description
Since the introduction of N-2 and N-1 support policies all instances should have had both these migrations happen automatically. Some Oracle database and on-premise customers may have been given the option to defer this, and some performance issues may also have delayed this on a few instances, however for the sake of supportability all should now aim to migrate. If you were not one of those exceptions then something may have gone wrong in the upgrades.
| Version | Application Tables | SQL Tables | Extended Table/Flattening Method |
|---|---|---|---|
| <= Fuji | cmdb_ci, and all extending tables | cmdb_ci, cmdb_ci_hardware, cmdb_ci_computer, etc. | Table-Per-Class |
| >= Geneva | cmdb, and all extending tables, including cmdb_ci A 'cmdb' table was slotted in above 'cmdb_ci' to become the new parent table. | cmdb, cmdb_ci, cmdb_ci_hardware, cmdb_ci_computer, etc. | Table-Per-Class |
| >= Jakarta | Unchanged | cmdb + cmdb$par1 [ + cmdb$par2 ] | Table-Per-Partition |
Some CMDB feature-related code in more recent versions expects this to have happened. Unexpected behaviour can in theory occur if this is not done. Please open a Case in HI with Customer Support if you notice this has not happened in your instance.
Procedure
Did Geneva Re-Parenting happen?
If cmdb_ci lists lots of records, and cmdb lists none, or doesn't even load a list view, then Geneva Re-Parenting has probably not happened.
This can be confirmed by looking in the sys_db_object table:
- Open a list for the 'sys_db_object' table
/sys_db_object_list.do - Filter on Name is cmdb or cmdb_ci
- If the cmdb_ci record shows Extends Table = Base Configuration Item, then Re-Parenting has happened.
Did Jakarta TPP Migration happen?
This can also be confirmed by looking in the sys_db_object table:
- Open a list for the 'sys_db_object' table
/sys_db_object_list.do - Filter on Name is cmdb or cmdb_ci
- If the cmdb record's Extension Model = Table per Partition, then TPP Migration has happened.
Applicable Versions
Post Geneva and/or Jakarta.
Additional Information
Multiple apparently duplicate Dictionary Records existing for the same CMDB field is a sign that TPP Migration has happened. This is part of the TPP design.
You may or may not see a sys_db_object record for the additional partition table named cmdb$par1 after TPP migration. This is not there on some instances, and does not cause any functional issues.
Ghost/Orphan records are only possible with Table-Per-Class. TPP migration will delete any existing orphan records, where the sys_id is missing from the top level cmdb table.