The ssadbcopy utility has the following known limitations:
You cannot use wildcards for the schema and table name.
You cannot migrate multiple databases (archive folders) at the same time. But you can migrate multiple databases at one time by running several ssadbccopy commands concurrently.
You cannot use FTP transfer mode from a Windows source to a Windows target. You can use the FTP transfer mode to a Unix target from a Unix or Windows source.
If the table structure in the source has changed, you must use the drop/create mode when you import the data in the target.
There are no run-time checkpoints. If the process fails, you must start the export and import from the beginning after you validate and fix the problem.
If the selected database, schema, or table has materialized views, the respective SCT files will be created in the local file system (mviewdir).
If the migration is performed at the schema or table level using the ssadbcopy utility, before migrating the database (from one Data Vault instance to the other), the SCT files of different tables should be present in only one storage type.
If the migration is performed at the table level using the ssadbcopy utility, all the SCT files of that particular table should be present in only one storage system. SCT files of other tables can be present in other storage systems.
Informatica supports the same version of the ssadbcopy utility for both export and import. For example, if you exported data with the ssadbcopy utility from version 6.4.3HF1, do not use the ssadbcopy utility from version 6.4.4 to import the same TAR file.
The ssadbcopy utility cannot be used on different operating systems. For example, you cannot export on one operating system and import on another operating sytem.
If you use the ssadbcopy utility for export on tables that have logically deleted rows, the ssadbcopy import fails with a check metadata error. You can ignore this error because the data is still migrated.