Troubleshooting delta migration

• Why can I not export the delta data in some tables?

  To export the delta data from a table, a field to record the last modification time is necessary. For most tables in Service Manager, this field is sysmodtime.

  However, some tables (especially custom tables) contain no such field, or the field name is not sysmodtime. In both cases, the tool cannot find or export the delta data, and you therefore need to migrate the data manually. For example, you can export all the data in these tables to another UNL file, and deploy this UNL file on the new system.

• Why is the delta data in some tables not suggested for the import operation?

  There are potential risks if the table structures of the new and the original Service Manager system are different. For example, if the table for interaction in the new Service Manager system contains more fields than the original Service Manager system, the new columns will be left blank when you try to migrate data in this table by using UNL files. More seriously, if one of the new fields is inserted between the original fields instead of at the end of table, then importing the table may cause unexpected behavior.

  Before the delta data is imported, the tool checks the table structure. If the structure is different, the tool will provide a risk estimation, and you can decide whether to import the data or not. If you decide not to import a table, see How can I handle skipped tables?.

• Where can I check the status of the background export/import tasks?

  During the import and export operations, there is a real-time report Overall Export Status Report.html / Overall Import Status Report.html report located under the specified folder. Open the file and check the overall status at the top of it. If your browser warns you about the script or ActiveX controller on the webpage, allow it. When the overall status changes to 100%, all the background export/import tasks have finished.

• What files are included as the output materials?

  After a successful export operation, the materials in the user specified folder should include the following files.

  File name	Description
  readme.txt	Records of the basic information of this folder This file includes the time range of the exported UNL files.
  Overall Export Status Report.html	A real-time report for the export operation
  Overall Import Status Report.html	A real-time report for the import operation Note This file only appears during the import operation.
  <SM table name>_unload_result.txt	A record of how many UNLs are to be exported for a specified table
  <SM table name>_unload_structure.txt	A description of the table structure of the original Service Manager system This information is used for comparison with the table structure in the new Service Manager system, and to help to decide if the delta data in table should be migrated here.
  <SM table name>_unload_structure_new.txt	Describe the table structure of the new Service Manager system Note These files only appear during the import operation.
  <SM table name>_<start time>_<end time>.UNL	Unloaded UNL files The format of the start and the end time is "yyyymmdd_hhMMss"
  table_exported.txt	A list of tables for which the delta data is exported The timestamp field in each table is also recorded in this file

• Why do I receive an error from the background scheduler?

  If you try to migrate the delta data by using background tasks and receive the following error message of, you must start the scheduler:

  background scheduler 'dmt_unload_load*' not started, …

  To start theschedule, follow these steps:

  1. Log in to Service Manager as an administrator.
  2. Click System Navigator >System Status> Start Scheduler.
  3. Click dmt_unload_load to start the five background schedulers.

  If you have already started the schedule, return to the previous step in the wizard. Wait for one minute and then try again.

• Why do I receive a file writing error during the export operation?

  If you receive a "can’t write files into output folder" error message during the export operation, follow these steps:

  1. Check if the specified folder exists.
  2. Check if Service Manager has the right to add and modify files in the folder, especially when Service Manager is installed on a non-Windows-based server.

• Why do I receive an "empty folder" error message during the import operation?

  If you receive a "selected folder is empty, or ‘readme.txt’ missing" error message during the import operation, follow these steps:

  1. Check if the specified folder exists.
  2. Check if the specified folder contains everything that was generated during the export operation.

  3. Check if Service Manager has the right to access the files in the folder, especially when Service Manager is installed on a non-Windows-based server.

• Why do I receive a "trigger disabled" error message from the background scheduler?

  All triggers will be disabled to avoid unexpected behavior during the import operation. It may take no more than one minute for each background session to disable the triggers. If you receive the following error message, wait for a while, and then return to the previous step to try again:

  background scheduler 'dmt_unload_load*' are trying to disable triggers, …

• How can I decide if the data in a specified table should be unloaded/loaded or not?

  If the table has a sysmodtime field, and if the structure of the table is the same in the original system and in the new system, then the delta data can be migrated without problem. Simply migrate the data according to the suggestions made by the tool.

  If a table has no sysmodtime field, the tool will suggest that you do not migrate the data in it. If the information in the table is not time-sensitive or is not changed very often, you can migrate all data in it to the new system by using a Service Manager unload script or by using the database functions.

  If a table structure has changed, but the tool reports no risk to the import operation, then you can migrate the table. However, if the tool reports risks, do not import the table. For more information, see How can I handle skipped tables?.

• How can I handle skipped tables?

  All the information in the original Service Manager system should be migrated to the new Service Manager system, except the information that belongs to a feature or function that is no longer valid in the new Service Manager system.

  • If a table is skipped during the export operation because it contains no delta data, then no additional work is needed.
  • If a table is skipped during the export operation because the sysmodtime field missing, migrate all the data in the table to the new system by using the Service Manager unload script.

  • If a table is skipped during the import operation because of structure changes, write a script to perform the migration. The script should include a field mapping to ensure that all fields in the table of the new Service Manager system will be prepared, just as if these delta data were created or modified in the new Service Manager system.

• What if there is a lot of delta data to be migrated, and the operation takes a long time?

  If there is a lot of delta data to migrate, the operation may take several hours. This leads to several hours’ downtime, and new delta data is generated during this downtime. You can run the tool multiple times to resolve this issue.

  For example, you have a delta time range from 00:00:00 on Jan 1st to 16:00:00 on Feb 2nd (the present). If you set the delta data time range from 00:00:00 on Jan 1st to 00:00:00 on Feb 2nd, it may take several hours to migrate the data. You can then run the tool again and set the delta data time range from 00:00:00 on Feb 2nd to the present time. This time, the operation may take several minutes only. These several minutes are the only downtime and after that, the new Service Manager system will function as a production system.