Recovering from a failed import or export

A file import or export operation can stop because of client or server failures, device failures, or operator errors. When a file import or export stops unexpectedly, you can continue the operation by reissuing the original command with the appropriate -continue option. This option allows you to resume the import or export or to restart the process from the beginning.

When an import or export operation fails, SFS issues an error message indicating where the failure occurred and where the operation will resume. The following is an example of the error output displayed: 

      1 W  Call to cie_Import failed with status
      ENC-sfs-0076:  A communication error occurred.
              (0x54048c27) : sfs_admin
   Status Information:
   Version number: 0
   Export id: 002EBDB4-F474-1B84-81BE-C037CF450000
   Number of tries: 1
   In progress: no
   End position:
          Directory number: 0   
          File number: 1
          File offset: 6834
   Restart position:
          Directory number: 0
          File number: 1
          File offset: 5104

If you want to restart the import or export from the beginning, specify restart as the argument to the -continue option. Any import or export in progress is ignored and the existing (partial) SFS file is removed.

If you have not modified the file while the import or export was stopped, you can continue the import or export by specifying resume as the argument to the -continue option.

Finally, you can continue an import or export from the position where it ended by specifying force as the argument to the -continue option. The force argument continues the import or export even though data was possibly modified while the operation was stopped.

Note: A user who attempts an export or import has A (administer) permission on the checkpoint file that is created. To successfully resume a failed export or import (using the -continue option), the administrator must perform the export/import. To successfully restart a failed export or import, either the original user must perform the export/import (using the -continue option), or the checkpoint file must be deleted so that a new user can restart the export/import.

SFS resumes an import or export after the last checkpoint taken. When it resumes, if SFS cannot determine whether or not a record has been transferred, a permanent error log file named target.IE.IMP.log for imports and source.IE.EXP.log for exports is created. The error log file is identical in structure to the SFS file being exported or imported, except that secondary indices are not created.

Some records might not be exported if (and only if) all the following conditions are met:
  • The last checkpoint was taken within a sequence of duplicate keys.
  • Between the failure and continuation, records within this same sequence of duplicates are deleted.
  • The export is continued with the force option.

This situation can be avoided by not allowing modifications to the SFS file between the failure and continuation. Because SFS cannot always determine whether a file has been modified, it might create and populate an error log file even when no changes have taken place. Such an error log file can simply be ignored.

If these conditions are satisfied, SFS might be unable to determine whether some records have already been placed in the target file. Such records are inserted into the error log file. The error log file can then be imported along with the source file. After both imports are complete, you can manually merge the two and eliminate redundant entries.

Similarly, some records might be imported twice if (and only if) the following conditions are met:
  • The last checkpoint is taken within a sequence of duplicate keys
  • The import is continued with the force option

In such a situation, SFS can possibly be unable to determine how many of the records with duplicate keys have been imported. All records between the last checkpoint and the next checkpoint will be inserted into the error log. Check the target SFS file manually to see that none of the records in the error log are repeated in the SFS file.