TrueSight Capacity Optimization (TSCO ) - When is it required to use the 'Restore Relationships' button of the Hierarchy Rules?  What is necessary to restore the TSCO domain hierarchy in the workspace after a 'mass delete' of data from TSCO?

Version 6
    Share This:

    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


    COMPONENT:

    Capacity Optimization


    APPLIES TO:

    All version



    QUESTION:

    In TrueSight Capacity Optimization (TSCO) the Restore relationships button (the picture of the broom) takes the latest hierarchy rule information and restores it back to a previous date range (replacing whatever previous relationships were defined).

    The Restore relationships button describes what it does as:

       
        
    • stop all object relationships at the Restore Date you specify
    •   
    • substitute them with the last relationships imported (re-process last OBJREL transaction imported as it was the first)
    •  


    In the TSCO console, what you see is the current hierarchy rule relationships so the historical relationships aren't important in relation to what you see in the CO console (although they could be important in relation to historical reporting -- particularly in a dynamic VMware environment).

    In general you'd be using the restore relationship option within the hierarchy to either force a current 'good' hierarchy back to a historical time period to fix previous problems with the hierarchy. The other time you use it is if systems are missing from the current hierarchy and you just want to rebuild the hierarchy from scratch based upon the current list of systems (ignoring past system moves into and out of the hierarchy).

     


    ANSWER:

     

    Here is some basic information related to the TrueSight Capacity Optimization (TSCO) Hierarchy Rule Restore relationships:

      
       
    1. If all you care about is that the current TSCO Hierarchy represents the full set of computers imported by the most recent ETL execution, you can run the Hierarchy Rule Restore relationships with a setting of Yesterday (recommended) would be fine. In a test environment where you aren't concerned about historical relationships you can run that Restore relationships without any negative impact.
    2.  
    3. If your current hierarchy doesn't look correct (you think there should be more systems) and your goal is to build the current hierarchy based upon the latest imported data (the full set of computers imported by the most recent ETL execution) then you can run the Hierarchy Rule Restore relationships with a setting of Yesterday (recommended).
    4.  
    5. If you've Dismissed all of the entities imported by an ETL that should blank out the hierarchy associated with that ETL in TSCO (since all the objects have been deleted from CO).  If you then re-run the ETL the Hierarchy should be re-created from scratch as if this is your first import of data from the ETL (since after a dismiss of all objects this really is the first import of data for what is once again a clean ETL).  In this case you shouldn't need to do anything with the Restore relationships.  If your hierarchy isn't being properly constructed in this scenario we'd want to investigate that further.
      


    The key thing about the Hierarchy Rules is that they are always executed as a 'diff' (object add/remove) from the previous hierarchy.

    So, if you have the following 3 hierarchy rule OBJREL table updates:

    Day 1:

    Domain:
      * Computer A
      * Computer B
      * Computer C

    Day 2:

    Domain:
      * Computer A
      * Computer B
      * Computer D

    When the hierarchy rule runs it will see that Computer C has been deleted and that Computer D has been added.  So, the 'diff' events it will apply to the hierarchy are:
      DELETE Computer C
      ADD Computer D

    Day 3:

    Domain:
      * Computer A
      * Computer B
      * Computer D
      * Computer E

    When the hierarchy rule runs it will see that Computer E has been added.  So the 'diff' event it will apply to the hierarchy is:
      ADD Computer E

    The problem you run into with the Hierarchy Rules is when TSCO thinks that a hierarchy has been properly processed but then either (a) Entries have been manually deleted from/moved in the hierarchy tree via the TSCO console or (b) It really hasn't been successfully processed.

    So, In the above example, if we assume that 'Day 2' wasn't properly processed (but was marked as successful) then on Day 3 (and all days moving forward) 'Computer D' will be missing from the hierarchy.

    The reason is that the only time an "ADD Computer D" event would be executed on the Hierarchy is the day that the computer was newly added to the hierarchy.  In future executions the 'diff' of the previous OBJREL data and the current would conclude that 'Computer D' doesn't need anything done to it because there has been no change between the two OBJREL imports.

    When you use the Restore relationships option within the Hierarchy Rule what you are saying is, "Ignore the previous OBJREL data that has been imported and rather than applying a 'diff' between that and the current data, just rebuild the hierarchy based upon the current data (and then the time interval selection decides to which time periods the current hierarchy configuration will be applied).  That is why the 'restore relations' fixes problems where systems that were imported by the most recent ETL import but were missing from the hierarchy.  What that means is that some previous hierarchy execution failed to properly ADD the system (even though there was an entry for it in the OBJREL table) and after that subsequent hierarchy rule executions don't even attempt to add the system because they just assume it is already there or if it is isn't then someone must have had a good reason to manually remove it.

      

    Q: When using the 'Dismiss Entities imported by a specific task' Maintenance Activity when, if ever, would it be necessary to run the 'restore relationships' to properly re-create the hierarchy after the first set of new data is imported by the ETL after the delete and dismiss of objects?

      

    To delete all of the data imported by an ETL you would use the 'mass delete' maintenance interface.  That would flag the systems as 'Dismissed'.  Next to actually delete the data from CO you would then go into the Dismissed items list and click the 'Clean up all dismissed objects' button.  This would remove the systems from the CO database.

    At this point, if you were to check the domain tree none of the systems would be listed.  The 'Clean up all dismissed objects' button will have deleted both the objects from the database and the hierarchy.  When you re-run the ETL to import new data (regardless of whether you have changed the hierarchy that will be created by the ETL or not) the new import of data will trigger the Hierarchy Manager once the OBJREL_STAGE table is imported and the hierarchy will automatically be re-created.

    When using the 'mass delete' option you should never need to use the 'restore relationships' button in the Hierarchy interface.  The hierarchy should be automatically restored and should be complete when the data is next imported by the ETL after using the 'mass delete' maintenance interface.

    The 'restore relationships' option is generally only used when something has gone wrong with the hierarchy creation (objects you think should be there aren't) and you don't want to debug why -- you just want to apply the latest hierarchy information from the last import of data to the tree (or back in time).

      

    Q: If an ETL run on day 1 succeeds and then run on day 2 fails, why is EVERYTHING removed from the hierarchy?

      

    If an ETL fails the hierarchy should not be updated.

    The problem you run into is when an ETL successfully imports only a small subset of the systems that had been imported the last time the ETL ran.

    So, take this scenario:

    Day 1:
      ETL A imports computers A, B, C, ..., AA, AB, AC, ..., BA, BB, BC, ..., ZZ

    Day 2 there has been a population failure in the BPA database affecting most computers:
      ETL A imports computers A, B, C and that is it.

    When that happens the Hierarchy Rule will 'diff' the two days and it will assert a hierarchy DELETE event for all of the servers that weren't imported the 2nd day.  When you look at the hierarchy after the 2nd import the only servers you'll see are A, B, and C.  Everything else will be moved to unassigned.

    Day 3 the population problem has been resolved:
      ETL A imports computers A, B, C, ..., AA, AB, AC, ..., BA, BB, BC, ..., ZZ

    When this happen the Hierarchy Rule will 'diff' the two days and it will assert a hierarchy ADD event for all of the servers that appeared that 3rd day.  So, that would be an ADD for all servers except A, B, and C (because in theory they were already in the hierarchy).

    So, an ETL totally failing (no data imported) or an ETL not running shouldn't change the hierarchy.  But, an ETL importing a very small subset of data will result in existing machines being expelled from the existing hierarchy and sent the unassigned.

      

    Q: If that same ETL than succeeds day 3, why is NOTHING added to the hierarchy?  Is it that it thinks it is already there when it is not?  Or will it not accommodate add/remove/then add again?

      

    When everything is working properly the hierarchy should be correct.  So, on day 3 when the systems are re-imported they should be added back to the hierarchy.  The problem happens when for some unexpected reason (that should be debugged on a case by case basis) the day 3 hierarchy runs, thinks it succeeded, but then doesn't actually update the hierarchy.  At that point the damage is done and the missed systems will remain missing even though day 4, 5, 6, and so on import the same full set of systems.

    When that happens it is a defect that needs to be investigated and corrected.

      

    Q: If everything is running properly in an environment, would it ever be necessary to run the hierarchy rule restore relationships?

      

    If everything is working correctly you would never need to run the hierarchy rule restore relations event.

      

    Q: Does running the hierarchy rule restore relationship require that one knows something is wrong with the hierarchy first?  Put another way, could re-running the restore relationships negatively impact the accuracy of the hierarchy?

      

    If you haven't manually adjusted the hierarchy, then after the current import of data, running the 'restore relations' with the "Yesterday (recommended)" option selected should result in the hierarchy constructed being identical to what was constructed by the hierarchy rule and if the hierarchy rule had failed at any point then running the 'restore relations' for "Yesterday (recommended)" would correct the problem.

      

    Q: In a test environment, if I'm not happy with the results from a version of an ETL being tested what is the 'best practice' recommendation to ensure that subsequent data imports result in a good version of the hierarchy?  Should I purge all the imported data and start again?

      

    If you have dismissed all the systems from the ETL and are running from a 'clean' ETL (so the Lookup table was empty before you ran it) then you shouldn't have to do anything to the Hierarchy Rule -- it should just come out right.

    One key point about the Hierarchy Rules is that they are associated with an ETL and they expect data from the same full list of systems to be imported with each ETL execution.  So, one way to get a messed up hierarchy is to run ETL 1 against systems A, B, C and then re-run ETL 1 against systems X, Y, Z.  Doing that will yield a hierarchy with just systems X, Y, Z (and A, B, C will have moved to unassigned).

    Legacy ID:KA381108

     


    Article Number:

    000239517


    Article Type:

    FAQ/Procedural



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