In TSCO relationships for entities are missing from the workspace domain hierarchy

Version 3
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    TrueSight Capacity Optimization


    APPLIES TO:

    TrueSight Capacity Optimization 10.7



    PROBLEM:

    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.


    SOLUTION:

     

    All TSCO Versions

    The 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.0 and 10.7.01

    There 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.  

    Additional Information

      

    AIX

    For 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)
             select
                   distinct taskpsetid, 'loader.objrel.resolve.identifiers'   as   name , 'true'   as value
             from
                 task_pset_props
             where
                 taskpsetid in (
                          select
                               taskpsetid
                          from
                               task_pset
                          where
                               taskid in (
                                        select
                                            taskid
                                        from
                                            task
                                        where
                                            etlmodid = 120
                               )
                 )
                   and taskpsetid not   in (
                          select taskpsetid from task_pset_props where   name = 'loader.objrel.resolve.identifiers'
                 )
                   and   name = 'bpa.extract.platform.list'
                   and (
                        value like   '%;AIX;%'
                          or value like   '%;AIX'
                          or value like   'AIX;%'
                          or value = 'AIX'
                 );
      
    commit;  

    VMware

    The 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. 

      

     


    Article Number:

    000154029


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles