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.5, 10.3, 10.0
In the $CPITBASE/scheduler/log/cpit.log on the Primary Scheduler the following error is being reported:
[Tue Nov 01 09:25:30 EDT 2016] ERROR [taskid=28]- BCO_TASK_ERR103: The transactions of this hierarchy rule have been populated in both change mode and assert mode
StackTrace: com.neptuny.cpit.cmdb.exceptions.MixedModesInconsistentDataException: The transactions of this hierarchy rule have been populated in both change mode and assert mode
[Tue Nov 01 09:25:30 EDT 2016] ERROR [taskid=28]- [HierarchyManagerTask] OBJREL - Rule 275 processed with 1 errors.
Looking at the Hierarchy Manager (taskid 28) the Hierarchy Rule that is generating this error is associated with the Gateway Server ETL.
The source of this error message is that there are two different types of Object Relationship transactions:
* Assert mode
* Change mode
In 'Assert' mode the full list of relationships is included in the Object Relationship Transaction imported by the ETL. The Hierarchy Manager then compares the current relationships to the previous ones to determine which changes need to be applied to the hierarchy. In 'Change' mode only the changes to the relationships are included in the Object Relationship Transaction imported by the ETL.
A Hierarchy Rule cannot switch between these two different types of Object Relationship Transactions. If the Hierarchy Rule does switch between Assert mode and Change mode that will trigger the, "BCO_TASK_ERR103: The transactions of this hierarchy rule have been populated in both change mode and assert mode" error.
The most common way this happens with a Gateway Server ETL Hierarchy Rule is when a regular nightly data import ETL has been run in a 'Recovery mode' using an alternate run configuration. So, the scenario is an alterate run configuration is created with the 'Extractor mode' set to 'via file' and the 'Data recovery mode' flag set to 'True'. This changes the Hierarchy Rule from 'Assert' to 'Change'. Now, when the regular nightly ETL runs the ETL runs under the normal configuration and loads an 'Assert' mode Object Relationship Transaction resulting in the mode change.
To workaround this problem:
(2) In the 'OBJREL transaction queue' table, find the point where the transactions move from 'PROCESSED' to 'NEW' status. This is the point where the 'Change' mode transaction was inserted. Typically the 'Change' mode transaction will have a much smaller number of 'Loaded rows' than the regular 'Assert' mode Object Relationship transactions in the list. Note the 'Id'.
(3) As the BCO_OWN database user (the 'TSCO Database Schema Owner' user) run the following SQL:
UPDATE OBJ_REL_TRANSACTION SET STATUS = 3 WHERE OBJRELTRANID = <The 'Id' from step 2>; COMMIT;
For example, here is a screenshot showing Transaction ID 72608 halting the processing of the Hierachy Rule with this error:
(4) This screenshot shows the transaction status being changed to IGNORED for a different CHANGE mode transaction that the above SQL was run against in the TSCO Hierarchy Rule 'OBJREL transaction queue' table:
(5) Manually execute the Hierarchy Rule by clicking the 'Run Hierarchy' button in the rule. This should process the Object Relationship transaction that have been blocked by the problematic transaction.
To avoid this problem in the future:
- A 'Run Configuration' with the 'Data recovery mode' flag set to 'True' should never be created within a regular Gateway Server vis parser ETL. A Recovery mode ETL should always be created as a totally separate ETL with a separate Hierarchy Rule.