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 11.x, 10.x
There are two different ETLs importing data from a data source and sharing Entity catalogs. So, for example, there is a Solaris LDOM Server which is also a Database server and there is an OEM ETL configured to get database metrics related to the partitions where the database instances are installed. Also, there is a VIS parser ETL collecting performance metrics from the same Solaris LDOM server.
Due to this configuration, the machines lose their primary system type (Solaris LDOM machine) when the OEM ETL is run afterwards because it overwrites the system type to Database. This caused that Solaris machines and partitions cannot be accessible from specific "Servers" View in TSCO as it cannot recognize the systems as a Solaris Ldom machines.
Is there a way to maintain the system type previously set by the first ETL without allowing the second ETL to change the entity_type?
The second ETL 'wins' by modifying the system_type when it runs, so it changes the type to its nature in order to pull the data into TSCO
The reason for the above mismatch is caused due to hierarchy transaction. The name of an entity is set by the OBJREL (Object Relationship) dataset. When processed by the Hierarchy Manager the OBJREL checks for the difference between the current transaction and all other transactions for both the entities that have been asserted and the relationships. It compares them to the previous entities that have been asserted in the relationships and if something is changed it in the entities, it applies to the hierarchy. To resolve the issue the system types A and B designated by the last ETL executed has to be retained. The system type doesn't bounce between the type being set by the two ETLs, it is only set when there is a type change within the OBJREL transaction for a hierarchy so the entity type gets set to the type of the last ETL that ran and stays set to that.
In order to force the system type to be retained and not overwritten by the last executed ETL, you can use the ‘Authoritative Mode’ setting in the Object relationship hierarchy rule.
Navigate to Administration >DATA WAREHOUSE >Hierarchy rules
Find the hierarchy rule associated with the ETL that you want to keep the system type and select it.
Click edit and select YES for ‘Authoritative mode’ (See image below)
Perform a restore relationship on this rule to restore system type for historical dataType declared by ETL will be forced. This closes all the object-relationships and it rebuilds the entire relationship tree based on the current and latest object-relationships that have been imported. (For additional information about Restore Relations refer to the official documentation)
Execute the ETL again to update the name of the systems.
Note: OEM ETL
For the OEM ETL there is a parameter which needs to be added to accomplish the change for using Authoritative mode when a user wants another ETL like the 'BMC - TrueSight Capacity Optimization Gateway VIS file Parser' and have the OEM ETL not to update the entity type after its hierarchy runs.
To allow this change for the OEM ETL improperly updating the entity type we have added an ETL property which the user can specify in the OEM ETL and set the value to false.
Add ETL property - extract.specify.databaseserver.entity.type
Set the value of the property to false.
Note that Database server type is deprecated for the OEM ETL.