Verifying over merges

Verification for over merges uses the data that is gathered in the ALIASES_JN table to find and report GUIDs with large numbers of master alias changes.

The ALIASES_JN table contains history of changes to the ALIASES table. Over merge is a situation when a few objects change their parent to the same model object. Child objects are then clustered around some number of parent objects. Over merges that occurred before the TADDDM 7.2.1 Fix Pack 3 was installed cannot be found because there is no required data in the ALIASES_JN table. Verification does not have the repair option because it might find and report false positive results.

By default, the detailed tracking is enabled for the ComputerSystem, AppServer, and Operating System classes, and all other classes that inherit from them. If you want to enable tracking for different classes, you can edit the following property in the collation.properties file: 
com.ibm.tivoli.namereconciliation.service.overmergeClasses
The following is the example of the property that is specified to look for the ComputerSystem, AppServer, and Operating System classes: 
com.ibm.tivoli.namereconciliation.service.overmergeClasses=
ComputerSystem,AppServer,OperatingSystem
Meaning of the actions that are used to run the command:

  • s1s2s1 - Verification looks for CIs that change their naming attributes values in a loop. For example, a computer system with a signature A, then signature B, and then again signature A would be detected.

    There is a scenario that appears like an s1s2s1 verification type, but not an actual over merge. For example, a VM is hosted in ESX A, then moved to ESX B, and again moved back to ESX A.

    To avoid this scenario, configure the following property in the collation.properties file: com.collation.overmerge_exclusion_al_name_rule_guid = 8125A88D7F7E3CD38E9639955DD19383

    While fetching s1s2s1verification type data, this property excludes the scenario discussed previously.

  • s1s2s3 - Verification looks for CIs that contain a number of changes for given naming attributes.

  • m1m2m1 - Verification looks for CIs which GUIDs changed their master GUID many times. For example, an alias A with a master GUID B that was later reassigned to master GUID C, and then again reassigned back to master GUID B would be detected.

  • m1m2m3 - Verification looks for CIs which GUIDs changed their master GUIDs a few times.

  • WinCSLinCSWinCS - Verification looks for CIs that changed their type a few times. For example, a computer system that was initially stored as WindowsComputerSystem, and later updated to LinuxUnitaryComputerSystem, and then again updated to WindowsComputerSystem would be detected.

To verify over merges, run one of the following commands:

  • verify-data.sh -v om [-a <action>] [-p <class>] [-from <time stamp>] [-to <time stamp>]
  • verify-data.bat -v om [-a <action>] [-p <class>] [-from <time stamp>] [-to <time stamp>]
    where:
    • <action>: s1s2s1, s1s2s3, m1m2m1, m1m2m3, WinCSLinCSWinCS
    • <class>: any class from the TADDM model, for example, ComputerSystem.
    • <time stamp>: time stamp in the YYYY-MM-DD HH24:MI:SI format.