DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 for Linux, UNIX, and Windows
The following table summarizes the important differences between the DB2® load and import utilities.
| Import Utility | Load Utility |
|---|---|
| Slow when moving large amounts of data. | Faster than the import utility when moving large amounts of data, because the load utility writes formatted pages directly into the database. |
| Limited exploitation of intra-partition parallelism. Intra-partition parallelism can only be achieved through concurrent invocations of the import utility in ALLOW WRITE ACCESS mode. | Exploitation of intra-partition parallelism. Typically, this requires symmetric multiprocessor (SMP) machines. |
| No FASTPARSE support. | FASTPARSE support, providing reduced data checking of user-supplied data. |
| Supports hierarchical data. | Does not support hierarchical data. |
| Creation of tables, hierarchies, and indexes supported with PC/IXF format. | Tables and indexes must exist. |
| No support for importing into materialized query tables. | Support for loading into materialized query tables. |
| No BINARYNUMERICS support. | BINARYNUMERICS support. |
| No PACKEDDECIMAL support. | PACKEDDECIMAL support. |
| No ZONEDDECIMAL support. | ZONEDDECIMAL support. |
| Cannot override columns defined as GENERATED ALWAYS. | Can override GENERATED ALWAYS columns, by using the generatedoverride and identityoverride file type modifiers. |
| Supports import into tables, views and nicknames. | Supports loading into tables only. |
| All rows are logged. | Minimal logging is performed. |
| Trigger support. | No trigger support. |
| If an import operation is interrupted, and a commitcount was specified, the table is usable and will contain the rows that were loaded up to the last COMMIT. The user can restart the import operation, or accept the table as is. | If a load operation is interrupted, and a savecount was specified, the table remains in Load Pending state and cannot be used until the load operation is restarted, a load terminate operation is invoked, or until the table space is restored from a backup image created some time before the attempted load operation. |
| Space required is approximately equivalent to the size of the largest index plus 10%. This space is obtained from the temporary table spaces within the database. | Space required is approximately equivalent to the sum of the size of all indexes defined on the table, and can be as much as twice this size. This space is obtained from temporary space within the database. |
| All constraints are validated during an import operation. | The load utility checks for uniqueness and computes generated column values, but all other constraints must be checked using SET INTEGRITY. |
| The key values are inserted into the index one at a time during an import operation. | The key values are sorted and the index is built after the data has been loaded. |
| If updated statistics are required, the runstats utility must be run after an import operation. | Statistics can be gathered during the load operation if all the data in the table is being replaced. |
| You can import into a host database through DB2 Connect™. | You cannot load into a host database. |
| Import files must exist on the client from which the import utility is invoked. | Depending on the options specified,
load files or pipes can reside either on the database partition(s)
that contain the database, or on the remotely connected client from
which the load utility is invoked. Note: LOBs
and XML data can only be read from the server side.
|
| A backup image is not required. Because the import utility uses SQL inserts, the activity is logged, and no backups are required to recover these operations in case of failure. | A backup image can be created during the load operation. |