Reconciliation best practices

CI attributes

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. 

When you configure reconciliation, consider the following recommendations:

• Do not rename the out-of-the-box reconciliation jobs, because other products could be using the default names given to those jobs.
• After discovering data, normalize the data, and reconcile it into your production data set immediately after your discovery application loads data into BMC CMDB.
• Do not create jobs that simultaneously identify the same data set or merge data into the same target data set. Simultaneous reconciliation can either overwrite data you wanted to keep from the other job or create duplicate CI instances.
• If you need to create multiple jobs to merge data into the same production data set, use the Execute activity to run the jobs sequentially or set the jobs as continuous and run them in parallel by selecting the View Other Datasets for Parallel Continuous Jobs option. You can configure this option from Configurations > Core Configurations > Reconciliation.
• Always perform the identify activity against the source datasets and never against the production datasets. The production dataset is the result of the reconciliation activities. Do not specify the production dataset as a source dataset while performing the identify activity because the CIs in the production dataset are already identified. The following image shows the field to select the source dataset:
  

• 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.
• (Not applicable for BMC Helix Subscribers) 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.
• (Not applicable for BMC Helix Subscribers) To improve performance, define a private queue on the Remedy AR System serverfor use only by the Reconciliation Engine. Make sure you use RPC socket 390698 or 390699.

• 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.
• Do not run more than one Atrium Integrator, Normalization Engine, and Reconciliation Engine jobs at the same time because they might query or update the same data and might have an impact on system resource availability.
• Run the reconciliation jobs in a sequence.
• Avoid running multiple jobs in parallel. If you must run the jobs in parallel, make sure that one job is a batch job and the other one is a continuous job.
• For a large amount of data, such as an initial load, run separate identify and merge jobs to allow for better diagnostics.
• For incremental updates, run identify and merge activities in one job. For new CIs, the identify and merge activities may take more time to run. For modified CIs, the identify activity runs quickly because the CIs have reconciliation IDs.

• In a reconciliation job, the Identify and Merge activities are run sequentially, based on the Sequence ID given in the reconciliation job which means that the instances start merging into the target data set only after all instances are identified. For a large amount of data, you can create separate identify and merge jobs and configure the merge job to run in a continuous mode. When the continuous merge job runs at the specified interval, all identified instances with the  ReconciliationMergeStatus attribute set to Ready to Merge are merged into the target data set. This configuration ensures that identified instances can begin merging into the target data set while the Identify activity is still running on the remaining unidentified instances.

  • When you make customizations, for example, add filters to the out-of-the-box job forms, if you face issues with the performance for these customizations, check the server-side AR API, SQL, and Filter logs. You can access the logs from AR System Management Console > AR System Server Group Console > Logs > View Logs as shown in the following figure:
    

  • For issues that occur when you run Reconciliation or Atrium Integrator jobs, for example, jobs that are stuck or reconciliation jobs are queued for a long time, verify the information in the respective job logs and take necessary action. You can view the logs in the following locations:

    Reconciliation logs	(Windows)<AR System installation directory><\ARSystem\Arserver\Db\re> (UNIX)<AR System installation directory></ARSystem/db/re>
    Atrium integrator logs	(Windows) <AR System installation directory><\ARSystem\Arserver\Db> (UNIX) <AR System installation directory></ARSystem/db>

    Important

    If you are BMC Helix Subscriber, you can access the logs in the View Logs page in AR System Management Console. For accessing any other logs, contact BMC Support.

  • Make sure that your QA environment is same as the production environment in terms of volume of data and configurations.
  • If you change any settings, or make customizations, test the changes in the QA environment. Only after you consistently get the expected results, promote the changes to the production environment.