Deleting orphan records after delta data migration
BMC strongly recommends that during the delta data migration (DDM) period, you not perform any administrator activities in the production environment such as creating or modifying forms and workflows or deleting data (dropping users, changing support groups, and so on). Any of these changes will affect the upgrade process. See Restrictions after restoring the database on the staging server.
When you delete records, you cannot do a hard delete. Soft deletion is the official method for all the applications. Hard delete is possible only for nonadministrative tasks that are permitted during DDM. However, with this procedure, you can hard-delete orphan records.
When deleting orphan records, consider the following:
- Searching for a record by date is difficult, because it is not possible to know when a record is deleted. You must do a full reverse compare of all the records in the form, comparing the records on the destination server with the records on the source server. The reverse compare will help you to identify records in the form that are on the destination server but are not on the source server. Those records are the only ones that you can delete.
- When you do a reverse compare, you must verify that none of the identified records are the ones created by the upgrade.
- You need not compare the records from all the forms. You can safely ignore any additional orphaned records in a back-end form that do not affect any functionality.
- You can delete data from relationship (association) forms only, by configuring a workflow to perform a hard delete. BMC has identified the following forms from which orphan records can be deleted. If required you can add more forms.
- CTM:People Permission Groups
- AST:CMDB Associations
- PBM:Known Error Associations
- PBM:Investigation Associations
- AST:Asset People
- You can delete orphan records using the Compare script, Find_orphans.xml, and Delete script which are bundled with the Find_orphans_package attached to this page.
Using the Compare script, you can do a reverse compare. The script updates the Find_orphans.xml file with list of records that are missing from the source server. The Delete script uses the updated Find_orphans.xml as input and deletes the identified records from the destination server.
The following diagram illustrates the process of deleting orphan records.
To delete orphan records after DDM
- Create a new folder under the Delta Data Migrator installation directory.
- Copy the attached Find_orphans_Package.xml and Find_orphans.xml files to that folder.
- Make a copy of the Find_orphans.xml file.
Run the Compare script. The script does a reverse comparison and overwrites the copy of the Find_orphans.xml file with all the IDs that are missing from the source production environment
Run the following command:
migratorcli -c -s "DESTINATION SERVER (new production)" -d "SOURCE SERVER" -u "Demo" -p "PASSWORD" --tcpport "TCP PORT" --dst_user "Demo" --dst_password "DEST PASSWORD" --dst_tcpport "DEST TCPPORT" -g "<MIGRATOR INSTALLED FOLDER>\migrator configuration.xml" --package "NEW FOLDER PATH>\Find_orphans_Package.xml" --layout 1 --logfile ".\orphans_compare.html" --missing
Run the Delete script with Compare report (Find_orphans.xml generated by the above step) as the input parameter. It will delete the records based on the record IDs in the Find_orphans.xml.
Run the following command:
migratorcli --delete -d DESTINATION SERVER -u Demo -p PASSWORD -t TCPPORT --difference "THE MISSING REPORT XML FILE THAT WAS GENERATED BY THE ABOVE STEP" --logfile "NEW FOLDER PATH\Find_orphans_results.html" --layout 1 --level 1