This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
TrueSight Capacity Optimization
TrueSight Capacity Optimization 10.7
This document covers three different platforms: AIX, Standalone, and VMware entities missing relationships. The underlying root causes of each of these three problems are different but the symptoms in TrueSight Capacity Optimization (TSCO) are the same and the solution is the same (install the latest Cumulative Hot Fix package which includes the fix) so this document covers all 3 problems.
All TSCO VersionsThe following KA describes the general reason that entities end up in the Unassigned list:
000026929: In TSCO, what causes systems to appear in the Newly Discovered, Unassigned, and Dismissed systems lists? ( https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000026929)
But sometimes entities will be in the unassigned list when they should be associated with a workspace domain hierarchy.
That generally means:
* The entity is active (it has reported data in the most recent ETL data load)
* Looking at the contents of the latest hierarchy rule transaction (typically with assistance from Technical Support) there is a relationship defined for the entity
If that happens it is the indication that there was a problem in the past updating the workspace domain hierarchy. The problem might not be current (it may have been a transient error or it may have been fixed in a subsequent Cumulative Hot Fix (CHF) package) but due to the way the hierarchy works the missing relationship will persist.
To fix the problem it is often a good idea to run a 'Restore Relations' against the Hierarchy Rule associated with the ETL that imports the data for the machine in the Unassigned list that is actively reporting current data. It is a best practice for the TSCO Adminnistrator to keep track of when they have run a Restore Relations against a particular Hierarchy Rule so that can be referenced in the future if entities are missing from the workspace domain hierarchy again. Although running the Restore Relations again every time an entity is not in the appropriate place in the hierarchy will likely workaround the problem it isn't a long term solution for a recurring problem and thus the problem should be researched to root cause.
TSCO 11.3.01In TSCO 11.3.01 was found an issue with the VMware reconcile task. This issue caused that the relationship of the Destination entities is not being updated and added to the Hierarchy Rule. So, at the end child entities are associated to the previous source parent entities and also they have broken relationships. The problem could be that some reconciled entities are left into unassigned folder
This has been identified as Defect DRCOZ-21269: Reconciliation task: entities can remain into unassigned bucket after reconciliation
The issue is fixed on TSCO 11.3.01 CHF (11.3.01.001.C00015).
TSCO 11.0 and 10.7.01There are two different defects fixed in the TrueSight Capacity Optimization (TSCO) 10.7.01 CHF #16 and later package which will correct the problem across AIX, Standalone, and VMware entities. These fixes are available in the TSCO 11.0 CHF package.
For AIX and Standalone entities the following defect is related:
DRCOZ-16926: In OBJREL dataset, entries with different hash values but linked to the same logical entities could generate unwanted relation changes
See important information in the 'Additional information' section related to AIX.
For VMware entities the following defect is related:
DRCOZ-17122: VMware entities are being left in the Unassigned domain even through they are in the current OBJREL transaction for an active Hierarchy Rule
Both of these have been addressed in the TSCO 10.7.01 CHF #16 and later package available for download from the BMC FTP site.
The following KA describes how to obtain the latest TSCO 10.7.01 CHF package:
000097159: Cumulative Hot Fixes for TrueSight Capacity Optimization (CO), CO Gateway Server, and CO Agent, and CO Perceiver ( https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000097159)
For all of these workspace domain hierarchy missing relationships issues it is necessary to run a Restore Relations against the Hierarchy Rule associated with the workspace domain that is missing the relationships. The patch addresses the missing relationships in the future but does not address relationships which have already failed to have been established by a perviously imported object relationship (OBJREL) transaction.
AIXFor the issue with AIX entities not being reported properly as the child of an AIX frame it is necessary to implement a configuration property change in the environment to enable the alternate code path provided in this fix. For information on this property change (which can be enabled via a one-off hot fix patch) contact TSCO Technical Support.
For the AIX case, the fix for “DRCOZ-16926” included in next CHF for 10.7.01 will solve the issue. In order to “activate” the fix, please ask to run also the following SQL statement on the BCO schema (you can run in before or after the CHF installation, it’s the same).
This SQL will add the property loader.objrel.resolve.identifiers for AIX ETLs.
insert into task_pset_props (taskpsetid, name , value)
distinct taskpsetid, 'loader.objrel.resolve.identifiers' as name , 'true' as value
taskpsetid in (
taskid in (
etlmodid = 120
and taskpsetid not in (
select taskpsetid from task_pset_props where name = 'loader.objrel.resolve.identifiers'
and name = 'bpa.extract.platform.list'
value like '%;AIX;%'
or value like '%;AIX'
or value like 'AIX;%'
or value = 'AIX'
VMwareThe issue occurs when a VMware guest moved multiple times in a short period from and then to the same VHC.
The scenario that causes the problem is the Hierarchy Manger being unable to detect changes when the same relationship is declared both with an end date and then subsequently with a 'forever' end date.
So, the scenario is:
Day1: VM1 starts under VHC1
Day2: VM2 moves to VHC2. This hierarchy change is handled properly by the Hierarchy Manager
Day3: VM3 added and then removed from VHC3 within same day. The end date of the relationship is set in the OBJ_REL_STAGE and this hierarchy change is handled properly and
Day4: VM3 is re-added to VHC3 with no end-date. This is the change the Hierarchy Manager doesn't handle properly. It doesn't detect the "end date" change for the relationship so the VM isn't re-added to the VHC.
So, the first two days cover scenarios handled properly by the Hierarchy Manager, Day 3's change is handled properly but sets the stage for the failure and then Day 4 covers the hierarchy failure.