Reconciliation best practices
For reconciliation to be effective, you must be aware of the following best practices. You must follow some of these guidelines to prepare your data, and follow other guidelines throughout the process.
Import data sets
Make sure that each data provider has its own import data set.
Verify that the CI (configuration item) attributes used in the identification rules of identify activity have unique values and are populated consistently.
If you use a standard job with the standard identification rules, you can verify the classes and identifying attributes on the Standards tab in Configurations > Manage Reconciliation Rules > Identification Rules.
Do not populate the
TokenID attribute unless you know the formulae that BMC discovery products use to populate it. The Token ID is reserved for use by some BMC discovery applications and is one of the primary attributes for identifying a computer system.
The identify activity and reconciliation IDs
To set up a reconciliation job, you must configure identification activities that match instances across datasets. The Identify activity reviews all incoming data, determines similar CIs across more than one data set, and marks where these data set instances seem to be the same CI.
The reconciliation engine marks CI and relationship instances with reconciliation IDs that are unique to individual CIs within a data set.
This initial marking step is critical to enable the compare and merge activities without causing conflicts from overlapping data that could potentially corrupt your CMDB with unreliable CI data.
Do not change the value of the
ReconciliationIdentity attribute for unidentified and identified CIs or relationships.
Changing the value of the
ReconciliationIdentity attribute for unidentified and identified CIs or relationships to some other character causes inconsistent results. The reconciliation engine looks for a value of 0 for unidentified CIs in the
The reconciliation ID is stored in the
ReconciliationIdentity attribute of the
In the CMDB dashboard user experience, you can use the following setting to modify the reconciliation ID at Jobs > Manage Reconciliation > Create Job > Add Activity > Identify.
If this option is enabled, the reconciliation engine searches for CIs in the production data set that have a reconciliation ID of 0 and sets the ID to a non-zero value that is unique across all data sets.
Reconciliation in a server group
In response to server status changes, the reconciliation engine automatically executes reconciliation jobs on a primary or secondary server in a server group. A server group is two or more servers that share the same database and provide failover operations.
The AR System server notifies the reconciliation engine for a status change. If the primary server status changes to suspended, the reconciliation engine stops reconciliation jobs on the primary server and resumes them on another server from the point where it stopped on the primary server. If the primary server status changes to running, reconciliation jobs on secondary servers are paused and resumed on the primary server.
The reconciliation engine assigns the SGPaused status when a job is paused while the job switches from one server to another in the server group. For example, when a job is running on one server (server 2) and a higher ranking server (server 1) comes up, the reconciliation engine pauses the job on server 2 and updates the job run status to SGPaused.
- To exclude a server that has no rank assigned or a user facing server from running reconciliation jobs, comment out the reconciliation engine entry (arrecond.exe) in the armonitor.cfg file.
- To exclude a ranked server from running reconciliation jobs, remove rank of the server and comment out the reconciliation engine entry (arrecond.exe) in the armonitor.cfg file.
The AR System server transfers control from one server to another depending on the Rank value specified in the AR System group operation ranking form. The reconciliation engine requires three iterations of 60 seconds each (180 seconds total) to transfer a job from one server to another so that the first server properly pauses the running jobs and the second server resumes the jobs. This process avoids running the same job on both servers simultaneously.
For more information about AR System and server groups, see the BMC Remedy AR System Documentation .
When you configure reconciliation, consider the following recommendations:
- Always perform the identify activity against the source datasets and never against the production datasets. Do not specify the production dataset as a dataset while performing the identify activity because the CIs in the production dataset are already identified.
The production dataset is the result of the reconciliation activities.
- Use a standard identification and a merge job, if possible.
- Test with a small amount of representative data by using a qualification.
- Do not run during prime (heavy use) hours.
- Consider indexing attributes used in Identify rules. Consult your database administrator to determine what indexes would help you.
- Create all your reconciliation definitions at the highest class level possible to take advantage of inheritance.
- After the initial data load into BMC CMDB, perform an Identify activity on the data, selecting the option to auto-identify the master dataset. This makes sure that your production data has an identity the first time it is identified against another dataset.
- Take advantage of Reconciliation Engine multithreading by breaking up large jobs into smaller ones and running them concurrently, but limit your number of concurrent threads to twice the number of CPUs in the server.
- To avoid redundant processing, make all Merge activities incremental by setting Force Attribute Merge to No.
- To improve performance, define a private queue on the BMC Remedy AR System server for use only by the Reconciliation Engine. Make sure you use RPC socket 390698 or 390699.
- Reconcile discovered data into your production dataset immediately after your discovery application loads data into BMC CMDB.
- Regularly review your Identify rules to make sure that they are still appropriate for your environment, and spot-check instances to confirm that they are being identified correctly.
- Instead of merging multiple discovery sources directly into your production dataset, merge them into a "consolidated discovery" dataset first. You can compare this against your production dataset and use the results to generate change requests or exception reports for any discrepancies.