Has CMDB re-parenting and flattening/TPP migration happened?Description<!-- div.margin{ padding: 10px 40px 40px 30px; } table.tocTable{ border: 1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); padding-top: .6em; padding-bottom: .6em; padding-left: .9em; padding-right: .6em; } table.noteTable{ border:1px solid; border-color:#E0E0E0; background-color: rgb(245, 245, 245); width: 100%; border-spacing:2; } table.internaltable { white-space:nowrap; text-align:left; border-width: 1px; border-collapse: collapse; font-size:14px; width: 85%; } table.internaltable th { border-width: 1px; padding: 5px; border-style: solid; border-color: rgb(245, 245, 245); background-color: rgb(245, 245, 245); } table.internaltable td { border-width: 1px; padding: 5px; border-style: solid; border-color: #E0E0E0; color: #000000; } .title { color: #D1232B; font-weight:normal; font-size:28px; } h1{ color: #D1232B; font-weight:normal; font-size:21px; margin-bottom:-5px } h2{ color: #646464; font-weight:bold; font-size:18px; } h3{ color: #000000; font-weight:BOLD; font-size:16px; text-decoration:underline; } h4{ color: #646464; font-weight:BOLD; font-size:15px; text-decoration:; } h5{ color: #000000; font-weight:BOLD; font-size:13px; text-decoration:; } h6{ color: #000000; font-weight:BOLD; font-size:14px; text-decoration:; } ul{ list-style: disc outside none; margin-left: 0; } li { padding-left: 1em; } --> 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. VersionApplication TablesSQL TablesExtended 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_ciA '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.doFilter on Name is cmdb or cmdb_ciIf 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.doFilter on Name is cmdb or cmdb_ciIf 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.