DB2 Version 9.

5
for Linux, UNIX, and Windows

Version 9 Release 5

Data Movement Utilities Guide and Reference

Updated December, 2010

SC23-5847-03
DB2 Version 9.5
for Linux, UNIX, and Windows

Version 9 Release 5

Data Movement Utilities Guide and Reference

Updated December, 2010

SC23-5847-03
 Note
Before using this information and the product it supports, read the general information under Appendix F, “Notices,” on
page 473.

Edition Notice
This document contains proprietary information of IBM. It is provided under a license agreement and is protected
by copyright law. The information contained in this publication does not include any product warranties, and any
statements provided in this manual should not be interpreted as such.
You can order IBM publications online or through your local IBM representative.
v To order publications online, go to the IBM Publications Center at www.ibm.com/shop/publications/order
v To find your local IBM representative, go to the IBM Directory of Worldwide Contacts at www.ibm.com/
planetwide
To order DB2 publications from DB2 Marketing and Sales in the United States or Canada, call 1-800-IBM-4YOU
(426-4968).
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright IBM Corporation 1993, 2010.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
About this book . . . . . . . . . . . v LOAD authority . . . . . . . . . . . 133
Loading data . . . . . . . . . . . . . 133
Loading XML data . . . . . . . . . . 135
Part 1. Data movement utilities and Load considerations for partitioned tables . . . 136
reference . . . . . . . . . . . . . . 1 LBAC-protected data load considerations . . . 139
Identity column load considerations . . . . . 140
Chapter 1. Data movement options Generated column load considerations . . . . 143
available in DB2 V9.5 . . . . . . . . . 3 Moving data using the CURSOR file type . . . 145
Propagating dependent immediate staging
tables . . . . . . . . . . . . . . . 148
Chapter 2. Export utility . . . . . . . . 7 Refreshing dependent immediate materialized
Export utility overview . . . . . . . . . . . 7 query tables . . . . . . . . . . . . . 149
Privileges and authorities required to use the export Multidimensional clustering considerations . . 150
utility. . . . . . . . . . . . . . . . . 8 Moving data using a customized application
Exporting data. . . . . . . . . . . . . . 8 (user exit) . . . . . . . . . . . . . 151
Exporting XML data . . . . . . . . . . . 9 Additional considerations for load . . . . . . 159
LBAC-protected data export considerations . . . 12 Parallelism and loading . . . . . . . . . 159
Table export considerations . . . . . . . . 13 Index creation during load operations . . . . 159
Typed table export considerations . . . . . . 14 Compression dictionary creation during load
Identity column export considerations . . . . 16 operations . . . . . . . . . . . . . 169
LOB export considerations . . . . . . . . 16 Options for improving load performance . . . 170
Reference - Export . . . . . . . . . . . . 18 Load features for maintaining referential integrity 174
EXPORT . . . . . . . . . . . . . . 18 Checking for integrity violations following a
EXPORT command using the ADMIN_CMD load operation . . . . . . . . . . . . 174
procedure . . . . . . . . . . . . . . 28 Checking for constraint violations using SET
db2Export - Export data from a database . . . 38 INTEGRITY . . . . . . . . . . . . . 177
Export sessions - CLP examples . . . . . . 44 Table locking during load operations . . . . 180
Read access load operations . . . . . . . 181
Chapter 3. Import utility . . . . . . . 47 Table space states during and after load
Import overview. . . . . . . . . . . . . 47 operations . . . . . . . . . . . . . 183
Privileges and authorities required to use import . . 49 Table states during and after load operations 184
Importing data . . . . . . . . . . . . . 50 Load exception tables . . . . . . . . . 186
Importing XML data . . . . . . . . . . 52 Failed or incomplete loads . . . . . . . . . 187
Imported table re-creation . . . . . . . . 53 Restarting an interrupted load operation . . . 187
Typed table import considerations . . . . . . 54 Restarting or terminating an ALLOW READ
LBAC-protected data import considerations . . 57 ACCESS load operation . . . . . . . . . 188
Buffered-insert imports . . . . . . . . . 59 Recovering data with the load copy location file 189
Identity column import considerations . . . . 60 Load dump file. . . . . . . . . . . . 191
Generated column import considerations . . . 61 Load temporary files . . . . . . . . . . 191
LOB import considerations . . . . . . . . 62 Load utility log records . . . . . . . . . 192
User-defined distinct types import considerations 63 Load overview–partitioned database environments 192
Additional considerations for import . . . . . . 63 Loading data in a partitioned database
Client/server environments and import . . . . 63 environment. . . . . . . . . . . . . 194
Table locking during import . . . . . . . . 64 Monitoring a load operation in a partitioned
Reference - Import . . . . . . . . . . . . 65 database environment using the LOAD QUERY
IMPORT . . . . . . . . . . . . . . 65 command . . . . . . . . . . . . . 200
IMPORT command using the ADMIN_CMD Resuming, restarting, or terminating load
procedure . . . . . . . . . . . . . . 89 operations in a partitioned database
db2Import - Import data into a table, hierarchy, environment. . . . . . . . . . . . . 202
nickname or view . . . . . . . . . . . 113 Migration and version compatibility . . . . . 204
Import sessions - CLP examples . . . . . . 126 Reference - Load in a partitioned environment 204
Reference - Load . . . . . . . . . . . . 212
Chapter 4. Load utility . . . . . . . 129 LOAD . . . . . . . . . . . . . . . 212
Load overview . . . . . . . . . . . . . 129 LOAD command using the ADMIN_CMD
Privileges and authorities required to use load . . 132 procedure . . . . . . . . . . . . . 244
db2Load - Load data into a table . . . . . . 276

© Copyright IBM Corp. 1993, 2010 iii

 Load sessions - CLP examples . . . . . . . 297 Query and XPath Data Model . . . . . . . 450
SET INTEGRITY . . . . . . . . . . . 300
LOAD QUERY . . . . . . . . . . . . 317
Part 2. Appendixes . . . . . . . . 451
LIST TABLESPACES . . . . . . . . . . 323

Chapter 5. Other data movement Appendix A. Differences between the

options . . . . . . . . . . . . . . 339 import and load utility . . . . . . . 453
Moving data with DB2 Connect . . . . . . . 339
The IBM Replication Tools by Component . . . . 341 Appendix B. Bind files used by the
Copying schemas . . . . . . . . . . . . 342 export, import, and load utilities . . . 455
Examples of schema copy using the db2move
utility . . . . . . . . . . . . . . . 344 Appendix C. How to read the syntax
db2move - Database movement tool . . . . . 345 diagrams . . . . . . . . . . . . . 457
Performing a redirected restore using an
automatically generated script . . . . . . . . 353
RESTORE DATABASE . . . . . . . . . 354 Appendix D. Collecting data for data
High availability through suspended I/O and movement problems . . . . . . . . 461
online split mirror support . . . . . . . . . 372
db2inidb - Initialize a mirrored database . . . 373 Appendix E. Overview of the DB2
db2relocatedb - Relocate database . . . . . . 375 technical information . . . . . . . . 463
db2look - DB2 statistics and DDL extraction tool 380 DB2 technical library in hardcopy or PDF format 464
Ordering printed DB2 books . . . . . . . . 466
Chapter 6. File formats and data types 393 Displaying SQL state help from the command line
Export/Import/Load utility file formats . . . . 393 processor . . . . . . . . . . . . . . . 467
Moving data across platforms - file format Accessing different versions of the DB2
considerations . . . . . . . . . . . . 393 Information Center . . . . . . . . . . . 467
Delimited ASCII (DEL) file format . . . . . 395 Displaying topics in your preferred language in the
Non-delimited ASCII (ASC) file format . . . . 401 DB2 Information Center . . . . . . . . . . 468
PC Version of IXF file format . . . . . . . 405 Updating the DB2 Information Center installed on
Worksheet File Format (WSF) . . . . . . . 443 your computer or intranet server . . . . . . . 468
Unicode considerations for data movement . . . 444 DB2 tutorials . . . . . . . . . . . . . 470
Character set and national language support . . . 445 DB2 troubleshooting information . . . . . . . 471
XML data movement . . . . . . . . . . . 446 Terms and Conditions . . . . . . . . . . 471
Important considerations for XML data
movement . . . . . . . . . . . . . 447 Appendix F. Notices . . . . . . . . 473
LOB and XML file behavior when importing
and exporting . . . . . . . . . . . . 448
XML data specifier . . . . . . . . . . 449
Index . . . . . . . . . . . . . . . 477

iv Data Movement Utilities Guide and Reference

About this book
This book provides information about and shows you how to use the following
DB2® Database for Linux, UNIX, and Windows data movement utilities:
v Export and Import
The export and import utilities move data between a table or view and another
database or spreadsheet program; between DB2 databases; and between DB2
databases and host databases using DB2 Connect™. The export utility moves
data from a database into operating system files; you can then use those files to
import or load that data into another database.
v Load
The load utility moves data into tables, extends existing indexes, and generates
statistics. The load utility moves data much faster than the import utility when
large amounts of data are involved. Data exported using the export utility can
be loaded using the load utility.
When the load utility is used in a partitioned database environment, large
amounts of data can be distributed and loaded into different database partitions.
For a complete listing of data movement options, see Data movement options
available in DB2 V9.5

© Copyright IBM Corp. 1993, 2010 v

vi Data Movement Utilities Guide and Reference
Part 1. Data movement utilities and reference

© Copyright IBM Corp. 1993, 2010 1

2 Data Movement Utilities Guide and Reference
Chapter 1. Data movement options available in DB2 V9.5
There are various data movement options available in DB2 V9.5. The following
table provides an overview of the data movement tools and utilities available to
you. Use this table as a guide to help you determine which data movement
options might best suit your needs.
Table 1. Data movement options available in DB2 V9.5
Utility name Load utility
To efficiently move large quantities of data
Purpose into newly created tables, or into tables that
already contain data.
Cross platform compatible Yes
This utility is best suited to situations where
performance is your primary concern. This
utility can be used as an alternative to the
import utility. It is faster then the import
utility because it writes formatted pages
directly into the database rather than using
Best practice usage
SQL INSERTS. In addition, the load utility
allows you the option to not log the data or
use the COPY option to save a copy of the
loaded data. Load operations can fully
exploit resources, such as CPUs and memory
on SMP and MPP environments.
References Loading data

Utility name db2move

Using the db2move utility with the COPY
option, allows you to copy schema templates
(with or without data) from a source
database to a target database or move an
Purpose entire schema from a source database to a
target database. Using the db2move utility
with the IMPORT or EXPORT option
facilitates the movement of a large numbers
of tables between DB2 databases.
Cross platform compatible Yes
When used with the COPY option, the
source and the target database must be
different. The COPY option is useful in
making schema templates. Use the IMPORT
Best practice usage or EXPORT option for cloning databases
when there is no support for cross-platform
backup and restore operations. The IMPORT
and EXPORT options are used in
conjunction with the db2look command.

v “Copying a schema” in Data Servers,

References Databases, and Database Objects Guide
v Imported table re-creation

© Copyright IBM Corp. 1993, 2010 3

 Utility name Import utility
To insert data from an external file into a
Purpose
table, hierarchy, view, or nickname
Cross platform compatible Yes
The import utility can be a good alternative
to the load utility in the following situations:
v where the target table is a view

Best practice usage v the target table has constraints and you
don't want the target table to be put in the
Set Integrity Pending state
v the target table has triggers and you want
them fired
References Importing data

Utility name Export utility

To export data from a database to one of
Purpose several external file formats. The data can
then be imported or loaded at a later time.
Cross platform compatible Yes
This utility is best suited in situations where
you want to store data in an external file, to
either process it further or move data to
Best practice usage another table. High Performance Unload
(HPU) is an alternative, however, it must be
purchased separately. Export supports XML
columns.
References Exporting data

Utility name ADMIN_COPY_SCHEMA procedure

Allows you to make a copy of all the objects
in a single schema and re-create those
Purpose objects in a new schema. This copy
operation can be performed with or without
data, within a database.
Cross platform compatible Yes

4 Data Movement Utilities Guide and Reference

Utility name ADMIN_COPY_SCHEMA procedure
This utility is useful for making schema
templates. It is also useful if you want to
experiment with a schema (for example, try
out new indexes) without impacting the
source schema's behavior. The key
differences between the
ADMIN_COPY_SCHEMA procedure and the
db2move utility are:
v The ADMIN_COPY_SCHEMA procedure
is used on a single database while the
db2move utility is used across databases
Best practice usage
v The db2move utility fails when invoked if
it cannot create a physical object such as a
table or index. The
ADMIN_COPY_SCHEMA procedure logs
errors and continues.
v The ADMIN_COPY_SCHEMA procedure
uses load from cursor to move data from
one schema to the other. The db2move
utility uses a remote load, similar to a
load from cursor, which pulls in the data
from the source database.
“Copying a schema” in Data Servers,
References
Databases, and Database Objects Guide

Restore utility with the REDIRECT option

Utility name
and the GENERATE SCRIPT option
To copy an entire database from one system
Purpose to another using a script from an existing
backup image.
Cross platform compatible Limited. See References
This utility is best suited in situations where
Best practice usage
a backup image exists.

v “Performing a redirected restore using an

automatically generated script” in Data
Recovery and High Availability Guide and
Reference
References
v “Backup and restore operations between
different operating systems and hardware
platforms” in Data Recovery and High
Availability Guide and Reference

db2relocatedb - Relocate database

Utility name
command
To rename a database, or relocate a database
Purpose or part of a database to the same system or
a different system.
Cross platform compatible No

Chapter 1. Data movement options 5

 db2relocatedb - Relocate database
Utility name
command

v This utility can be used for situations

where a backup and restore could be time
consuming.
v This utility is an alternative to using
backup and restore to move or create
Best practice usage copies of databases.
v It also provides a quick method of cloning
a database for alternative environments
such as testing.
v It can be used to move table space
containers to a new set of storage devices
“db2relocatedb - Relocate database
References
command” in Command Reference

Utility name Split mirror

To create a clone, standby, or backup
Purpose
database.
Cross platform compatible No

v create a standby system in case of a

primary failure to reduce down time
v move backup operations away from a live
Best practice usage production machine onto a split database
v provides a quick method of cloning a
database for alternate environments, such
as testing

v only DMS table spaces can be backed up

on the split version of the database
v usually used in conjunction with some
flashcopy technology provided with
Considerations storage systems
v an alternative is to issue a file copy once
the database is suspended, however this
duplicates the amount of storage for the
database
“High availability through online split
mirror and suspended I/O support” in Data
References
Recovery and High Availability Guide and
Reference

6 Data Movement Utilities Guide and Reference

Chapter 2. Export utility
Export utility overview
The export utility extracts data using an SQL select or an XQuery statement, and
places that information into a file. You can use the output file to move data for a
future import or load operation or to make the data accessible for analysis.

The export utility is a relatively simple, yet flexible data movement utility. You can
activate it through the Control Center, by issuing the EXPORT command in the
CLP, by calling the ADMIN_CMD stored procedure, or by calling the db2Export
API through a user application.

The following items are mandatory for a basic export operation:

v The path and name of the operating system file in which you want to store the
exported data
v The format of the data in the input file
Export supports IXF, WSF, and DEL data formats for the output files.
v A specification of the data that is to be exported
For the majority of export operations, you need to provide a SELECT statement
that specifies the data to be retrieved for export. When exporting typed tables,
you don’t need to issue the SELECT statement explicitly; you only need to
specify the subtable traverse order within the hierarchy
You can use the export utility with DB2 Connect if you need to move data in IXF
format.

Additional options
There are a number of parameters that allow you to customize an export operation.
File type modifiers offer many options such as allowing you to change the format
of the data, date and time stamps, or code page, or have certain data types written
to separate files. Using the METHOD parameters, you can specify different
column names to be used for the exported data.

You can export from tables that include one or more columns with an XML data
type. Use the XMLFILE, XML TO, and XMLSAVESCHEMA parameters to specify
details about how those exported documents are stored.

There are a few ways to improve the export utility’s performance. As the export
utility is an embedded SQL application and does SQL fetches internally,
optimizations that apply to SQL operations apply to the export utility as well.
Consider taking advantage of large buffer pools, indexing, and sort heaps. In
addition, try to minimize device contention on the output files by placing them
away from the containers and log devices.

The messages file

The export utility writes error, warning, and informational messages to standard
ASCII text message files. For all interfaces except the CLP, you must specify the
name of these files in advance with the MESSAGES parameter. If you are using
the CLP and do not specify a messages file, the export utility writes the messages
to standard output.

© Copyright IBM Corp. 1993, 2010 7

Privileges and authorities required to use the export utility
Privileges enable you to create, update, delete, or access database resources.
Authority levels provide a method of mapping privileges to higher-level database
manager maintenance and utility operations.

Together, privileges and authorities control access to the database manager and its
database objects. You can access only those objects for which you have the
appropriate authorization: that is, the required privilege or authority.

You must have SYSADM or DBADM authority or the CONTROL or SELECT

privilege for each table or view participating in the export operation.

When you are exporting LBAC-protected data, the session authorization ID must
be allowed to read the rows or columns that you are trying to export. Protected
rows that the session authorization ID is not authorized to read are not exported. If
the SELECT statement includes any protected columns that the session
authorization ID is not allowed to read, the export utility fails, and an error
(SQLSTATE 42512) is returned.

Exporting data
Use the export utility to export data from a database to a file. The file can have
one of several external file formats. You can specify the data to be exported by
supplying an SQL SELECT statement or by providing hierarchical information for
typed tables.

Before you begin

You need SYSADM authority, DBADM authority, the CONTROL privilege, or the
SELECT privilege on each participating table or view to export data from a
database

Before running the export utility, you must be connected (or be able to implicitly
connect) to the database from which you will export the data. If implicit connect is
enabled, a connection to the default database is established. Utility access to Linux,
UNIX, or Windows database servers from Linux, UNIX, or Windows clients must
be through a direct connection through the engine and not through a DB2 Connect
gateway or loop back environment.

Because the utility issues a COMMIT statement, you should complete all
transactions and release all locks by issuing a COMMIT or a ROLLBACK statement
before running the export utility. There is no requirement for applications accessing
the table and using separate connections to disconnect.

The following restriction applies to the export utility:

v This utility does not support tables with structured type columns.

About this task

You can run the export utility by using the Export Table notebook in the Control
Center or the application programming interface (API) db2Export, or by specifying
the EXPORT command in the command line processor (CLP).

Using the Export Table notebook

8 Data Movement Utilities Guide and Reference

 To export data by using the Export Table notebook:

Procedure
1. From the Control Center, expand the object tree until you find the Tables or
Views folder.
2. Click on the folder that you want to work with. Any existing tables or views
are displayed in the pane on the right side of the window (the contents pane).
3. In the contents pane, right-click the table or view that you want, and select
Export from the pop-up menu. The Export Table notebook opens.

Example

Detailed information about the Export Table notebook is provided in the Control
Center online help facility.

Issuing an EXPORT command by using the CLP

A very simple export operation requires you to specify only a target file, a file
format, and a source file for the SELECT statement.

To export data from the CLP, enter the EXPORT command:

db2 export to filename of ixf select * from table

where filename is the name of the output file that you want to create and export,
ixf is the file format, and table is the name of the table that contains the data you
want to copy.

However, you might also want to specify a messages file to which warning and
error messages will be written. To do that, add the MESSAGES parameter and a
message file name (in this case, msg.txt) so the command is:
db2 export to filename of ixf messages msgs.txt select * from table

For complete syntax and usage information, see "EXPORT command."

Exporting XML data

When exporting XML data, the resulting QDM (XQuery Data Model) instances are
written to a file or files separate from the main data file containing exported
relational data. This is true even if neither the XMLFILE nor the XML TO option is
specified. By default, exported QDM instances are all concatenated to the same
XML file. You can use the XMLINSEPFILES file type modifier to specify that each
QDM instance be written to a separate file.

The XML data, however, is represented in the main data file with an XML data
specifier (XDS). The XDS is a string represented as an XML tag named "XDS",
which has attributes that describe information about the actual XML data in the
column; such information includes the name of the file that contains the actual
XML data, and the offset and length of the XML data within that file.

The destination paths and base names of the exported XML files can be specified
with the XML TO and XMLFILE options. If the XML TO or XMLFILE option is
specified, the format of the exported XML file names, stored in the FIL attribute of
the XDS, is xmlfilespec.xxx.xml, where xmlfilespec is the value specified for the
XMLFILE option, and xxx is a sequence number for xml files produced by the
export utility. Otherwise, the format of the exported XML file names is:

Chapter 2. Export utility 9

 exportfilename.xxx.xml, where exportfilename is the name of the exported output
file specified for the EXPORT command, and xxx is a sequence number for xml
files produced by the export utility.

By default, exported XML files are written to the path of the exported data file.
The default base name for exported XML files is the name of the exported data file,
with an appending 3-digit sequence number, and the .xml extension.

Examples

For the following examples, imagine a table USER.T1 containing four columns and
two rows:
C1 INTEGER
C2 XML
C3 VARCHAR(10)
C4 XML

Table 2. USER.T1
C1 C2 C3 C4
2 <?xml version="1.0" 'char1' <?xml version="1.0"
encoding="UTF-8" ?><note encoding="UTF-8" ?><note
time="12:00:00"><to>You</ time="13:00:00"><to>Him</
to><from> Me</ to><from> Her</
from><heading>note1</heading> from><heading>note2</heading><
<body>Hello World!</body></ body>Hello World!</body></note>
note>
4 NULL 'char2' ?xml version="1.0" encoding="UTF-8"
?><note time="14:00:00">to>Us</
to><from> Them</
from><heading>note3</heading>
<body>Hello World!</body></
note>

Example 1

The following command exports the contents of USER.T1 in Delimited ASCII

(DEL) format to the file "/mypath/t1export.del". Because the XML TO and
XMLFILE options are not specified, the XML documents contained in columns C2
and C4 are written to the same path as the main exported file "/mypath". The base
name for these files is "t1export.del.xml". The XMLSAVESCHEMA option indicates
that XML schema information is saved during the export procedure.
EXPORT TO /mypath/t1export.del OF DEL XMLSAVESCHEMA SELECT * FROM USER.T1

The exported file "/mypath/t1export.del" contains:

2,"<XDS FIL=’t1export.del.001.xml’ OFF=’0’ LEN=’144’ />","char1",
"<XDS FIL=’t1export.del.001.xml’ OFF=’144’ LEN=’145’ />"
4,,"char2","<XDS FIL=’t1export.del.001.xml’ OFF=’289’
LEN=’145’ SCH=’S1.SCHEMA_A’ />"

The exported XML file "/mypath/t1export.del.001.xml" contains:

<?xml version="1.0" encoding="UTF-8" ?><note time="12:00:00"><to>You</to>
<from>Me</from><heading>note1</heading><body>Hello World!</body>
</note><?xml version="1.0" encoding="UTF-8" ?><note time="13:00:00"><to>Him
</to><from>Her</from><heading>note2</heading><body>Hello World!
</body></note><?xml version="1.0" encoding="UTF-8" ?><note time="14:00:00">
<to>Us</to><from>Them</from>heading>note3</heading><body>
Hello World!</body></note>

10 Data Movement Utilities Guide and Reference

Example 2

The following command exports the contents of USER.T1 in DEL format to the file
"t1export.del". XML documents contained in columns C2 and C4 are written to the
path "/home/user/xmlpath". The XML files are named with the base name
"xmldocs", with multiple exported XML documents written to the same XML file.
The XMLSAVESCHEMA option indicates that XML schema information is saved
during the export procedure.
EXPORT TO /mypath/t1export.del OF DEL XML TO /home/user/xmlpath
XMLFILE xmldocs XMLSAVESCHEMA SELECT * FROM USER.T1

The exported DEL file "/home/user/t1export.del" contains:

2,"<XDS FIL=’xmldocs.001.xml’ OFF=’0’ LEN=’144’ />","char1",
"<XDS FIL=’xmldocs.001.xml’ OFF=’144’ LEN=’145’ />"
4,,"char2","<XDS FIL=’xmldocs.001.xml’ OFF=’289’
LEN=’145’ SCH=’S1.SCHEMA_A’ />"

The exported XML file "/home/user/xmlpath/xmldocs.001.xml" contains:

<?xml version="1.0" encoding="UTF-8" ?><note time="12:00:00"><to>You</to>
<from>Me</from><heading>note1</heading><body>Hello World!</body>
</note><?xml version="1.0" encoding="UTF-8" ?><note time="13:00:00">
<to>Him</to><from>Her</from><heading>note2</heading><body>
Hello World!</body></note><?xml version="1.0" encoding="UTF-8" ?>
<note time="14:00:00"><to>Us</to><from>Them</from><heading>
note3</heading><body>Hello World!</body></note>

Example 3

The following command is similar to Example 2, except that each exported XML
document is written to a separate XML file.
EXPORT TO /mypath/t1export.del OF DEL XML TO /home/user/xmlpath
XMLFILE xmldocs MODIFIED BY XMLINSEPFILES XMLSAVESCHEMA
SELECT * FROM USER.T1

The exported file "/mypath/t1export.del" contains:

2,"<XDS FIL=’xmldocs.001.xml’ />","char1","XDS FIL=’xmldocs.002.xml’ />"
4,,"char2","<XDS FIL=’xmldocs.004.xml’ SCH=’S1.SCHEMA_A’ />"

The exported XML file "/home/user/xmlpath/xmldocs.001.xml" contains:

<?xml version="1.0" encoding="UTF-8" ?><note time="12:00:00"><to>You</to>
<from>Me</from><heading>note1</heading><body>Hello World!</body>
</note>

The exported XML file "/home/user/xmlpath/xmldocs.002.xml" contains:

?xml version="1.0" encoding="UTF-8" ?>note time="13:00:00">to>Him/to>
from>Her/from>heading>note2/heading>body>Hello World!/body>
/note>

The exported XML file "/home/user/xmlpath/xmldocs.004.xml" contains:

<?xml version="1.0" encoding="UTF-8" ?><note time="14:00:00"><to>Us</to>
<from>Them</from><heading>note3</heading><body>Hello World!</body>
</note>

Example 4

The following command writes the result of an XQuery to an XML file.

Chapter 2. Export utility 11

 EXPORT TO /mypath/t1export.del OF DEL XML TO /home/user/xmlpath
XMLFILE xmldocs MODIFIED BY XMLNODECLARATION select
xmlquery( ’$m/note/from/text()’ passing by ref c4 as "m" returning sequence)
from USER.T1

The exported DEL file "/mypath/t1export.del" contains:

"<XDS FIL=’xmldocs.001.xml’ OFF=’0’ LEN=’3’ />"
"<XDS FIL=’xmldocs.001.xml’ OFF=’3’ LEN=’4’ />"

The exported XML file "/home/user/xmlpath/xmldocs.001.xml" contains:

HerThem

Note: The result of this particular XQuery does not produce well-formed XML
documents. Therefore, the file exported above could not be directly imported into
an XML column.

LBAC-protected data export considerations

When you export data that is protected by label-based access control (LBAC), the
data that is exported is limited to the data that your LBAC credentials allow you to
read.

If your LBAC credentials do not allow you to read a row, that row is not exported,
but no error is returned. If your LBAC credentials do not allow you to read a
column, the export utility fails, and an error (SQLSTATE 42512) is returned.

A value from a column with a data type of DB2SECURITYLABEL is exported as

raw data enclosed in character delimiters. If a character delimiter is included in the
original data, it is doubled. No other changes are made to the bytes that make up
the exported value. This means that a data file that contains DB2SECURITYLABEL
data can contain newlines, formfeeds, or other non-printable ASCII characters.

If you want the values of columns with a data type of DB2SECURITYLABEL to be

exported in a human-readable form, you can use the SECLABEL_TO_CHAR scalar
function in the SELECT statement to convert the values to the security label string
format.

Examples

In the following examples, output is in DEL format and is written to the file
myfile.del. The data is exported from a table named REPS, which was created
with the following statement:
create table reps (row_label db2securitylabel,
id integer,
name char(30))
security policy data_access_policy

This example exports the values of the row_label column in the default format:
db2 export to myfile.del of del select * from reps

The data file is not very readable in most text editors because the values for the
row_label column are likely to contain several ASCII control characters.

The following example exports the values of the row_label column in the security
label string format:
db2 export to myfile.del of del select SECLABEL_TO_CHAR
(row_label,’DATA_ACCESS_POLICY’), id, name from reps

12 Data Movement Utilities Guide and Reference

 Here is an excerpt of the data file created by the previous example. Notice that the
format of the security label is readable:
...
"Secret:():Epsilon 37", 2005, "Susan Liu"
"Secret:():(Epsilon 37,Megaphone,Cloverleaf)", 2006, "Johnny Cogent"
"Secret:():(Megaphone,Cloverleaf)", 2007, "Ron Imron"
...

Table export considerations

A typical export operation involves the outputting of selected data that is inserted
or loaded into existing tables. However, it is also possible to export an entire table
for subsequent re-creation using the import utility.

To export a table, you must specify the PC/IXF file format. You can then re-create
your saved table (including its indexes) using the import utility in CREATE mode.
However, some information is not saved to the exported IXF file if any of the
following conditions exist:
v The index column names contain hexadecimal values of 0x2B or 0x2D.
v The table contains XML columns.
v The table is multidimensional clustered (MDC).
v The table contains a table partitioning key.
v The index name is longer than 128 bytes due to code page conversion.
v The table is protected.
v The EXPORT command contains action strings other than SELECT * FROM
tablename
v You specify the METHOD N parameter for the export utility.
For a list of table attributes that are lost, see "Table import considerations." If any
information is not saved, warning SQL27984W is returned when the table is
re-created.

Note: Import's CREATE mode is being deprecated. Use the db2look utility to
capture and re-create your tables.

Index information
If the column names specified in the index contain either - or + characters, the
index information is not collected, and warning SQL27984W is returned. The
export utility completes its processing, and the data exported is unaffected.
However, the index information is not saved in the IXF file. As a result, you must
create the indexes separately using the db2look utility.

Space limitations
The export operation fails if the data that you are exporting exceeds the space
available on the file system on which the exported file is created. In this case, you
should limit the amount of data selected by specifying conditions on the WHERE
clause so that the exported file fits on the target file system. You can run the export
utility multiple times to export all of the data.

Tables with other file formats

If you do not export using the IXF file format, the output files do not contain
descriptions of the target table, but they contain the record data. To re-create a
table and its data, create the target table, then use the load or import utility to
populate the table. You can use the db2look utility to capture the original table
definitions and to generate the corresponding data definition language (DDL).

Chapter 2. Export utility 13

 Typed table export considerations
You can use the DB2 export utility can be used to move data out of typed tables
for a later import. Export moves data from one hierarchical structure of typed
tables to another by following a specific order and creating an intermediate flat
file.

When working with typed tables, the export utility controls what is placed in the
output file; specify only the target table name and, optionally, the WHERE clause.
You can express subselect statements only by specifying the target table name and
the WHERE clause. You cannot specify a fullselect or select-statement when
exporting a hierarchy.

Preservation of hierarchies using traverse order

Typed tables can be in a hierarchy. There are several ways you can move data
across hierarchies:
v Movement from one hierarchy to an identical hierarchy
v Movement from one hierarchy to a subsection of a larger hierarchy
v Movement from a subsection of a large hierarchy to a separate hierarchy

Identification of types in a hierarchy is database dependent, meaning that in

different databases, the same type has a different identifier. Therefore, when
moving data between these databases, a mapping of the same types must be done
to ensure that the data is moved correctly.

The mapping used for typed tables is known as the traverse order, the order of
proceeding top-to-bottom, left-to-right through all of the supertables and subtables
in the hierarchy. Before each typed row is written out during an export operation,
an identifier is translated into an index value. This index value can be any number
from one to the number of relevant types in the hierarchy. Index values are
generated by numbering each type when moving through the hierarchy in a
specific order—the traverse order. Figure 1 shows a hierarchy with four valid
traverse orders:
v Person, Employee, Manager, Architect, Student
v Person, Student, Employee, Manager, Architect
v Person, Employee, Architect, Manager, Student
v Person, Student, Employee, Architect, Manager

14 Data Movement Utilities Guide and Reference

 8 1
Person
3 Person_t 2
(Oid, Name, Age)

5 Employee 6
Student
Employee_t
Student_t
4 (SerialNum, Salary, REF 7 (SerialNum, Marks)
(Department_t))

Manager Architect
Manager_t Architect_t
(Bonus) (StockOption)

Figure 1. An example of a hierarchy

The traverse order is important when moving data between table hierarchies
because it determines where the data is moved in relation to other data. There are
two types of traverse order: default and user specified.

Default traverse order

With the default traverse order, all relevant types refer to all reachable types in the
hierarchy from a given starting point in the hierarchy. The default order includes
all tables in the hierarchy, and each table is ordered by the scheme used in the
OUTER order predicate. For instance, the default traverse order of Figure 1,
indicated by the dotted line, would be Person, Student, Employee, Manager,
Architect.

The default traverse order behaves differently when used with different file
formats. Exporting data to the PC/IXF file format creates a record of all relevant
types, their definitions, and relevant tables. The export utility also completes the
mapping of an index value to each table. When working with the PC/IXF file
format, you should use the default traverse order.

With the ASC, DEL, or WSF file format, the order in which the typed rows and the
typed tables are created could be different, even though the source and target
hierarchies might be structurally identical. This results in time differences that the
default traverse order identifies when proceeding through the hierarchies. The
creation time of each type determines the order used to move through the
hierarchy at both the source and the target when using the default traverse order.
Ensure that the creation order of each type in both the source and the target
hierarchies is identical and that there is structural identity between the source and
the target. If these conditions cannot be met, select a user-specified traverse order.

User-specified traverse order

With the user-specified traverse order, you define (in a traverse order list) the
relevant types to be used. This order outlines how to traverse the hierarchy and
what sub-tables to export, whereas with the default traverse order, all tables in the
hierarchy are exported.

Although you determine the starting point and the path down the hierarchy when
defining the traverse order, remember that the subtables must be traversed in

Chapter 2. Export utility 15

 pre-order fashion. Each branch in the hierarchy must be traversed to the bottom
before a new branch can be started. The export utility looks for violations of this
condition within the specified traverse order. One method of ensuring that the
condition is met is to proceed from the top of the hierarchy (or the root table),
down the hierarchy (subtables) to the bottom subtable, then back up to its
supertable, down to the next "right-most" subtable, then back up to next higher
supertable, down to its subtables, and so on.

If you want to control the traverse order through the hierarchies, ensure that the
same traverse order is used for both the export and the import utilities.

Example 1

The following examples are based on the hierarchical structure in Figure 1. To

export the entire hierarchy, enter the following commands:
DB2 CONNECT TO Source_db
DB2 EXPORT TO entire_hierarchy.ixf OF IXF HIERARCHY STARTING Person

Note that setting the parameter HIERARCHY STARTING to Person indicates that
the default traverse order starting from the table PERSON.

Example 2

To export the entire hierarchy, but only the data for those people over the age of
20, you would enter the following commands:
DB2 CONNECT TO Source_db
DB2 EXPORT TO entire_hierarchy.del OF DEL HIERARCHY (Person,
Employee, Manager, Architect, Student) WHERE Age>=20

Note that setting the parameter HIERARCHY to Person, Employee, Manager,

Architect, Student indicates a user-specified traverse order.

Identity column export considerations

You can use the export utility to export data from a table containing an identity
column. However, the identity column limits your choice of output file format.

If the SELECT statement that you specify for the export operation is of the form
SELECT * FROM tablename and you do not use the METHOD option is not used,
exporting identity column properties to IXF files is supported. You can then use
the REPLACE_CREATE and the CREATE options of the IMPORT command to
re-create the table, including its identity column properties. If you create the
exported IXF file from a table containing an identity column of type GENERATED
ALWAYS, the only way that you can successfully import the data file is to specify
the identityignore file type modifier during the import operation. Otherwise, all
rows are rejected (SQL3550W is issued).

Note: The CREATE and REPLACE_CREATE options of the IMPORT command are
deprecated and might be removed in a future release.

LOB export considerations

When exporting tables with large object (LOB) columns, the default action is to
export a maximum of 32 KB per LOB value and to place it in the same file as the
rest of the column data. If you are exporting LOB values that exceed 32 KB, you
should have the LOB data written to a separate file to avoid truncation.

16 Data Movement Utilities Guide and Reference

To specify that LOB should be written to its own file, use the lobsinfile file type
modifier. This modifier instructs the export utility to place the LOB data in the
directories specified by the LOBS TO clause. Using LOBS TO or LOBFILE
implicitly activates the lobsinfile file type modifier. By default, LOB values are
written to the same path to which the exported relational data is written. If one or
more paths are specified with the LOBS TO option, the export utility cycles
between the paths to write each successful LOB value to the appropriate LOB file.
You can also specify names for the output LOB files using the LOBFILE option. If
the LOBFILE option is specified, the format of lobfilename is lobfilespec.xxx.lob,
where lobfilespec is the value specified for the LOBFILE option, and xxx is a
sequence number for LOB files produced by the export utility. Otherwise,
lobfilename is of the format: exportfilename.xxx.lob, where exportfilename is the
name of the exported output file specified for the EXPORT command, and xxx is a
sequence number for LOB files produced by the export utility.

By default, LOBs are written to a single file, but you can also specify that the
individual LOBs are to be stored in separate files. The export utility generates a
LOB Location Specifier (LLS) to enable the storage of multiple LOBs in one file.
The LLS, which is written to the export output file, is a string that indicates where
the LOB data is stored within the file. The format of the LLS is
lobfilename.ext.nnn.mmm/, where lobfilename.ext is the name of the file that
contains the LOB, nnn is the offset of the LOB within the file (measured in bytes),
and mmm is the length of the LOB (measured in bytes). For example, an LLS of
db2exp.001.123.456/ indicates that the LOB is located in the file db2exp.001,
begins at an offset of 123 bytes into the file, and is 456 bytes long. If the indicated
size in the LLS is 0, the LOB is considered to have a length of 0. If the length is -1,
the LOB is considered to be NULL and the offset and file name are ignored.

If you don't want individual LOB data concatenated to the same file, use the
lobsinsepfiles file type modifier to write each LOB to a separate file.

Note: The IXF file format does not store the LOB options of the column, such as
whether or not the LOB column is logged. This means that the import utility
cannot re-create a table containing a LOB column that is defined to be 1 GB or
larger.

Example 1
The following example shows how to export LOBs (where the exported LOB files
have the specified base name lobs1) to a DEL file:
db2 export to myfile.del of del lobs to mylobs/
lobfile lobs1 modified by lobsinfile
select * from emp_photo

Example 2
The following example shows how to export LOBs to a DEL file, where each LOB
value is written to a separate file and lobfiles are written to two directories:
db2 export to myfile.del of del
lobs to /db2exp1/, /db2exp2/ modified by lobsinfile
select * from emp_photo

Chapter 2. Export utility 17

Reference - Export

EXPORT
Exports data from a database to one of several external file formats. The user
specifies the data to be exported by supplying an SQL SELECT statement, or by
providing hierarchical information for typed tables.

Quick link to “File type modifiers for the export utility” on page 22.

Authorization

One of the following:

v sysadm
v dbadm

or CONTROL or SELECT privilege on each participating table or view.

Required connection

Command syntax


EXPORT TO filename OF filetype

,

LOBS TO  lob-path

, ,

LOBFILE  filename XML TO  xml-path

,

XMLFILE  filename MODIFIED BY  filetype-mod

XMLSAVESCHEMA ,

METHOD N (  column-name )

select-statement

XQUERY xquery-statement
HIERARCHY STARTING sub-table-name
traversal-order-list

 WHERE

traversal-order-list:

(  sub-table-name )

18 Data Movement Utilities Guide and Reference

Command parameters
HIERARCHY traversal-order-list
Export a sub-hierarchy using the specified traverse order. All sub-tables
must be listed in PRE-ORDER fashion. The first sub-table name is used as
the target table name for the SELECT statement.
HIERARCHY STARTING sub-table-name
Using the default traverse order (OUTER order for ASC, DEL, or WSF files,
or the order stored in PC/IXF data files), export a sub-hierarchy starting
from sub-table-name.
LOBFILE filename
Specifies one or more base file names for the LOB files. When name space
is exhausted for the first name, the second name is used, and so on. This
will implicitly activate the LOBSINFILE behavior.
When creating LOB files during an export operation, file names are
constructed by appending the current base name from this list to the
current path (from lob-path), and then appending a 3-digit sequence
number to start and the three character identifier lob. For example, if the
current LOB path is the directory /u/foo/lob/path/, and the current LOB
file name is bar, the LOB files created will be /u/foo/lob/path/
bar.001.lob, /u/foo/lob/path/bar.002.lob, and so on. The 3-digit
sequence number in the LOB file name will grow to 4-digits once 999 is
used, 4-digits will grow to 5-digits once 9999 is used, and so on.
LOBS TO lob-path
Specifies one or more paths to directories in which the LOB files are to be
stored. There will be at least one file per LOB path, and each file will
contain at least one LOB. The maximum number of paths that can be
specified is 999. This will implicitly activate the LOBSINFILE behavior.
METHOD N column-name
Specifies one or more column names to be used in the output file. If this
parameter is not specified, the column names in the table are used. This
parameter is valid only for WSF and IXF files, but is not valid when
exporting hierarchical data.
MODIFIED BY filetype-mod
Specifies file type modifier options. See “File type modifiers for the export
utility” on page 22.
OF filetype
Specifies the format of the data in the output file:
v DEL (delimited ASCII format), which is used by a variety of database
manager and file manager programs.
v WSF (work sheet format), which is used by programs such as:
– Lotus® 1-2-3®
– Lotus Symphony
When exporting BIGINT or DECIMAL data, only values that fall within
the range of type DOUBLE can be exported accurately. Although values
that do not fall within this range are also exported, importing or loading
these values back might result in incorrect data, depending on the
operating system.
v IXF (Integration Exchange Format, PC version) is a proprietary binary
format.

Chapter 2. Export utility 19

 select-statement
Specifies the SELECT or XQUERY statement that will return the data to be
exported. If the statement causes an error, a message is written to the
message file (or to standard output). If the error code is one of SQL0012W,
SQL0347W, SQL0360W, SQL0437W, or SQL1824W, the export operation
continues; otherwise, it stops.
TO filename
If the name of a file that already exists is specified, the export utility
overwrites the contents of the file; it does not append the information.
XMLFILE filename
Specifies one or more base file names for the XML files. When name space
is exhausted for the first name, the second name is used, and so on.
When creating XML files during an export operation, file names are
constructed by appending the current base name from this list to the
current path (from xml-path), appending a 3-digit sequence number, and
appending the three character identifier xml. For example, if the current
XML path is the directory /u/foo/xml/path/, and the current XML file
name is bar, the XML files created will be /u/foo/xml/path/bar.001.xml,
/u/foo/xml/path/bar.002.xml, and so on.
XML TO xml-path
Specifies one or more paths to directories in which the XML files are to be
stored. There will be at least one file per XML path, and each file will
contain at least one XQuery Data Model (XDM) instance. If more than one
path is specified, then XDM instances are distributed evenly among the
paths.
XMLSAVESCHEMA
Specifies that XML schema information should be saved for all XML
columns. For each exported XML document that was validated against an
XML schema when it was inserted, the fully qualified SQL identifier of that
schema will be stored as an (SCH) attribute inside the corresponding XML
Data Specifier (XDS). If the exported document was not validated against
an XML schema or the schema object no longer exists in the database, an
SCH attribute will not be included in the corresponding XDS.
The schema and name portions of the SQL identifier are stored as the
"OBJECTSCHEMA" and "OBJECTNAME" values in the row of the
SYSCAT.XSROBJECTS catalog table corresponding to the XML schema.
The XMLSAVESCHEMA option is not compatible with XQuery sequences
that do not produce well-formed XML documents.

Usage notes
v Be sure to complete all table operations and release all locks before starting an
export operation. This can be done by issuing a COMMIT after closing all
cursors opened WITH HOLD, or by issuing a ROLLBACK.
v Table aliases can be used in the SELECT statement.
v The messages placed in the message file include the information returned from
the message retrieval service. Each message begins on a new line.
v The export utility produces a warning message whenever a character column
with a length greater than 254 is selected for export to DEL format files.

20 Data Movement Utilities Guide and Reference

v PC/IXF import should be used to move data between databases. If character
data containing row separators is exported to a delimited ASCII (DEL) file and
processed by a text transfer program, fields containing the row separators will
shrink or expand.
v The file copying step is not necessary if the source and the target databases are
both accessible from the same client.
v DB2 Connect can be used to export tables from DRDA® servers such as DB2 for
OS/390®, DB2 for VM and VSE, and DB2 for OS/400®. Only PC/IXF export is
supported.
v When exporting to the IXF format, if identifiers exceed the maximum size
supported by the IXF format, the export will succeed but the resulting datafile
cannot be used by a subsequent import operation using the CREATE mode.
SQL27984W will be returned.
v When exporting to a diskette on Windows, and the table that has more data
than the capacity of a single diskette, the system will prompt for another
diskette, and multiple-part PC/IXF files (also known as multi-volume PC/IXF
files, or logically split PC/IXF files), are generated and stored in separate
diskettes. In each file, with the exception of the last, there is a DB2
CONTINUATION RECORD (or "AC" Record in short) written to indicate the
files are logically split and where to look for the next file. The files can then be
transferred to an AIX® system, to be read by the import and load utilities. The
export utility will not create multiple-part PC/IXF files when invoked from an
AIX system. For detailed usage, see the IMPORT command or LOAD command.
v The export utility will store the NOT NULL WITH DEFAULT attribute of the
table in an IXF file if the SELECT statement provided is in the form SELECT *
FROM tablename.
v When exporting typed tables, subselect statements can only be expressed by
specifying the target table name and the WHERE clause. Fullselect and
select-statement cannot be specified when exporting a hierarchy.
v For file formats other than IXF, it is recommended that the traversal order list be
specified, because it tells DB2 how to traverse the hierarchy, and what sub-tables
to export. If this list is not specified, all tables in the hierarchy are exported, and
the default order is the OUTER order. The alternative is to use the default order,
which is the order given by the OUTER function.
v Use the same traverse order during an import operation. The load utility does
not support loading hierarchies or sub-hierarchies.
v When exporting data from a table that has protected rows, the LBAC credentials
held by the session authorization id might limit the rows that are exported.
Rows that the session authorization ID does not have read access to will not be
exported. No error or warning is given.
v If the LBAC credentials held by the session authorization id do not allow
reading from one or more protected columns included in the export then the
export fails and an error (SQLSTATE 42512) is returned.
v When running Data Movement utilities such as export and db2move, the query
compiler might determine that the underlying query will run more efficiently
against an MQT than the base table or tables. In this case, the query will execute
against a refresh deferred MQT, and the result of the utilities might not
accurately represent the data in the underlying table.
v Export packages are bound using DATETIME ISO format, thus, all
date/time/timestamp values are converted into ISO format when cast to a string
representation. Since the CLP packages are bound using DATETIME LOC format
(locale specific format), you may see inconsistent behavior between CLP and

Chapter 2. Export utility 21

 export if the CLP DATETIME format is different from ISO. For instance, the
following SELECT statement may return expected results:
db2 select col2 from tab1 where char(col2)=’05/10/2005’;
COL2
----------
05/10/2005
05/10/2005
05/10/2005
3 record(s) selected.

But an export command using the same select clause will not:
db2 export to test.del of del select col2 from test
where char(col2)=’05/10/2005’;
Number of rows exported: 0

Now, replacing the LOCALE date format with ISO format gives the expected
results:
db2 export to test.del of del select col2 from test
where char(col2)=’2005-05-10’;
Number of rows exported: 3

File type modifiers for the export utility

Table 3. Valid file type modifiers for the export utility: All file formats
Modifier Description
lobsinfile lob-path specifies the path to the files containing LOB data.

Each path contains at least one file that contains at least one LOB pointed to by a
Lob Location Specifier (LLS) in the data file. The LLS is a string representation of
the location of a LOB in a file stored in the LOB file path. The format of an LLS is
filename.ext.nnn.mmm/, where filename.ext is the name of the file that contains the
LOB, nnn is the offset in bytes of the LOB within the file, and mmm is the length
of the LOB in bytes. For example, if the string db2exp.001.123.456/ is stored in
the data file, the LOB is located at offset 123 in the file db2exp.001, and is 456
bytes long.

If you specify the “lobsinfile” modifier when using EXPORT, the LOB data is
placed in the locations specified by the LOBS TO clause. Otherwise the LOB data
is sent to the data file directory. The LOBS TO clause specifies one or more paths
to directories in which the LOB files are to be stored. There will be at least one
file per LOB path, and each file will contain at least one LOB. The LOBS TO or
LOBFILE options will implicitly activate the LOBSINFILE behavior.

To indicate a null LOB , enter the size as -1. If the size is specified as 0, it is
treated as a 0 length LOB. For null LOBS with length of -1, the offset and the file
name are ignored. For example, the LLS of a null LOB might be db2exp.001.7.-1/.
xmlinsepfiles Each XQuery Data Model (XDM) instance is written to a separate file. By default,
multiple values are concatenated together in the same file.
lobsinsepfiles Each LOB value is written to a separate file. By default, multiple values are
concatenated together in the same file.
xmlnodeclaration XDM instances are written without an XML declaration tag. By default, XDM
instances are exported with an XML declaration tag at the beginning that includes
an encoding attribute.
xmlchar XDM instances are written in the character codepage. Note that the character
codepage is the value specified by the codepage file type modifier, or the
application codepage if it is not specified. By default, XDM instances are written
out in Unicode.

22 Data Movement Utilities Guide and Reference

Table 3. Valid file type modifiers for the export utility: All file formats (continued)
Modifier Description
xmlgraphic If the xmlgraphic modifier is specified with the EXPORT command, the exported
XML document will be encoded in the UTF-16 code page regardless of the
application code page or the codepage file type modifier.

Table 4. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format
Modifier Description
chardelx x is a single character string delimiter. The default value is a double quotation
mark ("). The specified character is used in place of double quotation marks to
enclose a character string.2 If you want to explicitly specify the double quotation
mark as the character string delimiter, it should be specified as follows:
modified by chardel""

The single quotation mark (') can also be specified as a character string delimiter
as follows:
modified by chardel’’
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the output data set. Converts character data to this code page from the
application code page during the export operation.

For pure DBCS (graphic), mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive. The codepage modifier cannot be used with the
lobsinfile modifier.
coldelx x is a single character column delimiter. The default value is a comma (,). The
specified character is used in place of a comma to signal the end of a column.2

In the following example, coldel; causes the export utility to use the semicolon
character (;) as a column delimiter for the exported data:
db2 "export to temp of del modified by coldel;
select * from staff where dept = 20"
decplusblank Plus sign character. Causes positive decimal values to be prefixed with a blank
space instead of a plus sign (+). The default action is to prefix positive decimal
values with a plus sign.
decptx x is a single character substitute for the period as a decimal point character. The
default value is a period (.). The specified character is used in place of a period as
a decimal point character.2
nochardel Column data will not be surrounded by character delimiters. This option should
not be specified if the data is intended to be imported or loaded using DB2. It is
provided to support vendor data files that do not have character delimiters.
Improper usage might result in data loss or corruption.

This option cannot be specified with chardelx or nodoubledel. These are mutually
exclusive options.
nodoubledel Suppresses recognition of double character delimiters.2

Chapter 2. Export utility 23

Table 4. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format (continued)
Modifier Description
striplzeros Removes the leading zeros from all exported decimal columns.

Consider the following example:

db2 create table decimalTable ( c1 decimal( 31, 2 ) )
db2 insert into decimalTable values ( 1.1 )

db2 export to data of del select * from decimalTable

db2 export to data of del modified by STRIPLZEROS

select * from decimalTable

In the first export operation, the content of the exported file data will be
+00000000000000000000000000001.10. In the second operation, which is identical
to the first except for the striplzeros modifier, the content of the exported file
data will be +1.10.

24 Data Movement Utilities Guide and Reference

Table 4. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format (continued)
Modifier Description
timestampformat="x" x is the format of the time stamp in the source file.4 Valid time stamp elements
are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 01 - 12;
mutually exclusive with M and MMM)
MMM - Month (three-letter case-insensitive abbreviation for
the month name; mutually exclusive with M and MM)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31; mutually exclusive with D)
DDD - Day of the year (three digits ranging from 001 - 366;
mutually exclusive with other day or month elements)
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system;
mutually exclusive with H)
M - Minute (one or two digits ranging from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M, minute)
S - Second (one or two digits ranging from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
UUUUUU - Microsecond (6 digits ranging from 000000 - 999999;
mutually exclusive with all other microsecond elements)
UUUUU - Microsecond (5 digits ranging from 00000 - 99999,
maps to range from 000000 - 999990;
mutually exclusive with all other microseond elements)
UUUU - Microsecond (4 digits ranging from 0000 - 9999,
maps to range from 000000 - 999900;
mutually exclusive with all other microseond elements)
UUU - Microsecond (3 digits ranging from 000 - 999,
maps to range from 000000 - 999000;
mutually exclusive with all other microseond elements)
UU - Microsecond (2 digits ranging from 00 - 99,
maps to range from 000000 - 990000;
mutually exclusive with all other microseond elements)
U - Microsecond (1 digit ranging from 0 - 9,
maps to range from 000000 - 900000;
mutually exclusive with all other microseond elements)
TT - Meridian indicator (AM or PM)

Following is an example of a time stamp format:

"YYYY/MM/DD HH:MM:SS.UUUUUU"

The MMM element will produce the following values: 'Jan', 'Feb', 'Mar', 'Apr',
'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', and 'Dec'. 'Jan' is equal to month 1, and
'Dec' is equal to month 12.

The following example illustrates how to export data containing user-defined

time stamp formats from a table called 'schedule':
db2 export to delfile2 of del
modified by timestampformat="yyyy.mm.dd hh:mm tt"
select * from schedule

Chapter 2. Export utility 25

Table 5. Valid file type modifiers for the export utility: IXF file format
Modifier Description
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the output data set. Converts character data from this code page to the
application code page during the export operation.

For pure DBCS (graphic), mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive.

Table 6. Valid file type modifiers for the export utility: WSF file format
Modifier Description
1 Creates a WSF file that is compatible with Lotus 1-2-3 Release 1, or Lotus 1-2-3
Release 1a.5 This is the default.
2 Creates a WSF file that is compatible with Lotus Symphony Release 1.0.5
3 Creates a WSF file that is compatible with Lotus 1-2-3 Version 2, or Lotus
Symphony Release 1.1.5
4 Creates a WSF file containing DBCS characters.

Note:
1. The export utility does not issue a warning if an attempt is made to use
unsupported file types with the MODIFIED BY option. If this is attempted, the
export operation fails, and an error code is returned.
2. Delimiter considerations for moving data lists restrictions that apply to the
characters that can be used as delimiter overrides.
3. The export utility normally writes
v date data in YYYYMMDD format
v char(date) data in "YYYY-MM-DD" format
v time data in "HH.MM.SS" format
v time stamp data in "YYYY-MM-DD-HH. MM.SS.uuuuuu" format
Data contained in any datetime columns specified in the SELECT statement
for the export operation will also be in these formats.
4. For time stamp formats, care must be taken to avoid ambiguity between the
month and the minute descriptors, since they both use the letter M. A month
field must be adjacent to other date fields. A minute field must be adjacent to
other time fields. Following are some ambiguous time stamp formats:
"M" (could be a month, or a minute)
"M:M" (Which is which?)
"M:YYYY:M" (Both are interpreted as month.)
"S:M:YYYY" (adjacent to both a time value and a date value)

In ambiguous cases, the utility will report an error message, and the operation
will fail.
Following are some unambiguous time stamp formats:
"M:YYYY" (Month)
"S:M" (Minute)
"M:YYYY:S:M" (Month....Minute)
"M:H:YYYY:M:D" (Minute....Month)
5. These files can also be directed to a specific product by specifying an L for
Lotus 1-2-3, or an S for Symphony in the filetype-mod parameter string. Only
one value or product designator can be specified.

26 Data Movement Utilities Guide and Reference

 6. The WSF file format is not supported for XML columns.
7. All XDM instances are written to XML files that are separate from the main
data file, even if neither the XMLFILE nor the XML TO clause is specified. By
default, XML files are written to the path of the exported data file. The default
base name for XML files is the name of the exported data file with the
extension ".xml" appended to it.
8. All XDM instances are written with an XML declaration at the beginning that
includes an encoding attribute, unless the XMLNODECLARATION file type
modifier is specified.
9. By default, all XDM instances are written in Unicode unless the XMLCHAR or
XMLGRAPHIC file type modifier is specified.
10. The default path for XML data and LOB data is the path of the main data file.
The default XML file base name is the main data file. The default LOB file
base name is the main data file. For example, if the main data file is
/mypath/myfile.del

, the default path for XML data and LOB data is

/mypath"

, the default XML file base name is

myfile.del

, and the default LOB file base name is

myfile.del

.
The LOBSINFILE file type modifier must be specified in order to have LOB
files generated.
11. The export utility appends a numeric identifier to each LOB file or XML file.
The identifier starts as a 3 digit, 0 padded sequence value, starting at
.001

. After the 999th LOB file or XML file, the identifier will no longer be padded
with zeroes (for example, the 1000th LOG file or XML file will have an
extension of
.1000

. Following the numeric identifier is a three character type identifier

representing the data type, either
.lob

or
.xml

. For example, a generated LOB file would have a name in the format
myfile.del.001.lob

, and a generated XML file would be have a name in the format

myfile.del.001.xml

.
12. It is possible to have the export utility export XDM instances that are not
well-formed documents by specifying an XQuery. However, you will not be
Chapter 2. Export utility 27
 able to import or load these exported documents directly into an XML
column, since XML columns can only contain complete documents.

EXPORT command using the ADMIN_CMD procedure

Exports data from a database to one of several external file formats. The user
specifies the data to be exported by supplying an SQL SELECT statement, or by
providing hierarchical information for typed tables.

Quick link to “File type modifiers for the export utility” on page 32.

Authorization

One of the following:

v sysadm
v dbadm

or CONTROL or SELECT privilege on each participating table or view.

Required connection

Command syntax


EXPORT TO filename OF filetype

,

LOBS TO  lob-path

, ,

LOBFILE  filename XML TO  xml-path

,

XMLFILE  filename MODIFIED BY  filetype-mod

XMLSAVESCHEMA ,

METHOD N (  column-name )

select-statement

XQUERY xquery-statement
HIERARCHY STARTING sub-table-name
traversal-order-list

 WHERE

traversal-order-list:

(  sub-table-name )

28 Data Movement Utilities Guide and Reference

Command parameters
HIERARCHY traversal-order-list
Export a sub-hierarchy using the specified traverse order. All sub-tables
must be listed in PRE-ORDER fashion. The first sub-table name is used as
the target table name for the SELECT statement.
HIERARCHY STARTING sub-table-name
Using the default traverse order (OUTER order for ASC, DEL, or WSF files,
or the order stored in PC/IXF data files), export a sub-hierarchy starting
from sub-table-name.
LOBFILE filename
Specifies one or more base file names for the LOB files. When name space
is exhausted for the first name, the second name is used, and so on. This
will implicitly activate the LOBSINFILE behavior.
When creating LOB files during an export operation, file names are
constructed by appending the current base name from this list to the
current path (from lob-path), and then appending a 3-digit sequence
number to start and the three character identifier lob. For example, if the
current LOB path is the directory /u/foo/lob/path/, and the current LOB
file name is bar, the LOB files created will be /u/foo/lob/path/
bar.001.lob, /u/foo/lob/path/bar.002.lob, and so on. The 3-digit
sequence number in the LOB file name will grow to 4-digits once 999 is
used, 4-digits will grow to 5-digits once 9999 is used, and so on.
LOBS TO lob-path
Specifies one or more paths to directories in which the LOB files are to be
stored. There will be at least one file per LOB path, and each file will
contain at least one LOB. The maximum number of paths that can be
specified is 999. This will implicitly activate the LOBSINFILE behavior.
METHOD N column-name
Specifies one or more column names to be used in the output file. If this
parameter is not specified, the column names in the table are used. This
parameter is valid only for WSF and IXF files, but is not valid when
exporting hierarchical data.
MODIFIED BY filetype-mod
Specifies file type modifier options. See “File type modifiers for the export
utility” on page 32.
OF filetype
Specifies the format of the data in the output file:
v DEL (delimited ASCII format), which is used by a variety of database
manager and file manager programs.
v WSF (work sheet format), which is used by programs such as:
– Lotus 1-2-3
– Lotus Symphony
When exporting BIGINT or DECIMAL data, only values that fall within
the range of type DOUBLE can be exported accurately. Although values
that do not fall within this range are also exported, importing or loading
these values back might result in incorrect data, depending on the
operating system.
v IXF (Integration Exchange Format, PC version) is a proprietary binary
format.

Chapter 2. Export utility 29

 select-statement
Specifies the SELECT or XQUERY statement that will return the data to be
exported. If the statement causes an error, a message is written to the
message file (or to standard output). If the error code is one of SQL0012W,
SQL0347W, SQL0360W, SQL0437W, or SQL1824W, the export operation
continues; otherwise, it stops.
TO filename
If the name of a file that already exists is specified, the export utility
overwrites the contents of the file; it does not append the information.
XMLFILE filename
Specifies one or more base file names for the XML files. When name space
is exhausted for the first name, the second name is used, and so on.
When creating XML files during an export operation, file names are
constructed by appending the current base name from this list to the
current path (from xml-path), appending a 3-digit sequence number, and
appending the three character identifier xml. For example, if the current
XML path is the directory /u/foo/xml/path/, and the current XML file
name is bar, the XML files created will be /u/foo/xml/path/bar.001.xml,
/u/foo/xml/path/bar.002.xml, and so on.
XML TO xml-path
Specifies one or more paths to directories in which the XML files are to be
stored. There will be at least one file per XML path, and each file will
contain at least one XQuery Data Model (XDM) instance. If more than one
path is specified, then XDM instances are distributed evenly among the
paths.
XMLSAVESCHEMA
Specifies that XML schema information should be saved for all XML
columns. For each exported XML document that was validated against an
XML schema when it was inserted, the fully qualified SQL identifier of that
schema will be stored as an (SCH) attribute inside the corresponding XML
Data Specifier (XDS). If the exported document was not validated against
an XML schema or the schema object no longer exists in the database, an
SCH attribute will not be included in the corresponding XDS.
The schema and name portions of the SQL identifier are stored as the
"OBJECTSCHEMA" and "OBJECTNAME" values in the row of the
SYSCAT.XSROBJECTS catalog table corresponding to the XML schema.
The XMLSAVESCHEMA option is not compatible with XQuery sequences
that do not produce well-formed XML documents.

Usage notes
v Be sure to complete all table operations and release all locks before starting an
export operation. This can be done by issuing a COMMIT after closing all
cursors opened WITH HOLD, or by issuing a ROLLBACK.
v Table aliases can be used in the SELECT statement.
v The messages placed in the message file include the information returned from
the message retrieval service. Each message begins on a new line.
v The export utility produces a warning message whenever a character column
with a length greater than 254 is selected for export to DEL format files.

30 Data Movement Utilities Guide and Reference

v PC/IXF import should be used to move data between databases. If character
data containing row separators is exported to a delimited ASCII (DEL) file and
processed by a text transfer program, fields containing the row separators will
shrink or expand.
v The file copying step is not necessary if the source and the target databases are
both accessible from the same client.
v DB2 Connect can be used to export tables from DRDA servers such as DB2 for
OS/390, DB2 for VM and VSE, and DB2 for OS/400. Only PC/IXF export is
supported.
v When exporting to the IXF format, if identifiers exceed the maximum size
supported by the IXF format, the export will succeed but the resulting datafile
cannot be used by a subsequent import operation using the CREATE mode.
SQL27984W will be returned.
v When exporting to a diskette on Windows, and the table that has more data
than the capacity of a single diskette, the system will prompt for another
diskette, and multiple-part PC/IXF files (also known as multi-volume PC/IXF
files, or logically split PC/IXF files), are generated and stored in separate
diskettes. In each file, with the exception of the last, there is a DB2
CONTINUATION RECORD (or "AC" Record in short) written to indicate the
files are logically split and where to look for the next file. The files can then be
transferred to an AIX system, to be read by the import and load utilities. The
export utility will not create multiple-part PC/IXF files when invoked from an
AIX system. For detailed usage, see the IMPORT command or LOAD command.
v The export utility will store the NOT NULL WITH DEFAULT attribute of the
table in an IXF file if the SELECT statement provided is in the form SELECT *
FROM tablename.
v When exporting typed tables, subselect statements can only be expressed by
specifying the target table name and the WHERE clause. Fullselect and
select-statement cannot be specified when exporting a hierarchy.
v For file formats other than IXF, it is recommended that the traversal order list be
specified, because it tells DB2 how to traverse the hierarchy, and what sub-tables
to export. If this list is not specified, all tables in the hierarchy are exported, and
the default order is the OUTER order. The alternative is to use the default order,
which is the order given by the OUTER function.
v Use the same traverse order during an import operation. The load utility does
not support loading hierarchies or sub-hierarchies.
v When exporting data from a table that has protected rows, the LBAC credentials
held by the session authorization id might limit the rows that are exported.
Rows that the session authorization ID does not have read access to will not be
exported. No error or warning is given.
v If the LBAC credentials held by the session authorization id do not allow
reading from one or more protected columns included in the export then the
export fails and an error (SQLSTATE 42512) is returned.
v When running Data Movement utilities such as export and db2move, the query
compiler might determine that the underlying query will run more efficiently
against an MQT than the base table or tables. In this case, the query will execute
against a refresh deferred MQT, and the result of the utilities might not
accurately represent the data in the underlying table.
v Export packages are bound using DATETIME ISO format, thus, all
date/time/timestamp values are converted into ISO format when cast to a string
representation. Since the CLP packages are bound using DATETIME LOC format
(locale specific format), you may see inconsistent behavior between CLP and

Chapter 2. Export utility 31

 export if the CLP DATETIME format is different from ISO. For instance, the
following SELECT statement may return expected results:
db2 select col2 from tab1 where char(col2)=’05/10/2005’;
COL2
----------
05/10/2005
05/10/2005
05/10/2005
3 record(s) selected.

But an export command using the same select clause will not:
db2 export to test.del of del select col2 from test
where char(col2)=’05/10/2005’;
Number of rows exported: 0

Now, replacing the LOCALE date format with ISO format gives the expected
results:
db2 export to test.del of del select col2 from test
where char(col2)=’2005-05-10’;
Number of rows exported: 3

File type modifiers for the export utility

Table 7. Valid file type modifiers for the export utility: All file formats
Modifier Description
lobsinfile lob-path specifies the path to the files containing LOB data.

Each path contains at least one file that contains at least one LOB pointed to by a
Lob Location Specifier (LLS) in the data file. The LLS is a string representation of
the location of a LOB in a file stored in the LOB file path. The format of an LLS is
filename.ext.nnn.mmm/, where filename.ext is the name of the file that contains the
LOB, nnn is the offset in bytes of the LOB within the file, and mmm is the length
of the LOB in bytes. For example, if the string db2exp.001.123.456/ is stored in
the data file, the LOB is located at offset 123 in the file db2exp.001, and is 456
bytes long.

If you specify the “lobsinfile” modifier when using EXPORT, the LOB data is
placed in the locations specified by the LOBS TO clause. Otherwise the LOB data
is sent to the data file directory. The LOBS TO clause specifies one or more paths
to directories in which the LOB files are to be stored. There will be at least one
file per LOB path, and each file will contain at least one LOB. The LOBS TO or
LOBFILE options will implicitly activate the LOBSINFILE behavior.

To indicate a null LOB , enter the size as -1. If the size is specified as 0, it is
treated as a 0 length LOB. For null LOBS with length of -1, the offset and the file
name are ignored. For example, the LLS of a null LOB might be db2exp.001.7.-1/.
xmlinsepfiles Each XQuery Data Model (XDM) instance is written to a separate file. By default,
multiple values are concatenated together in the same file.
lobsinsepfiles Each LOB value is written to a separate file. By default, multiple values are
concatenated together in the same file.
xmlnodeclaration XDM instances are written without an XML declaration tag. By default, XDM
instances are exported with an XML declaration tag at the beginning that includes
an encoding attribute.
xmlchar XDM instances are written in the character codepage. Note that the character
codepage is the value specified by the codepage file type modifier, or the
application codepage if it is not specified. By default, XDM instances are written
out in Unicode.

32 Data Movement Utilities Guide and Reference

Table 7. Valid file type modifiers for the export utility: All file formats (continued)
Modifier Description
xmlgraphic If the xmlgraphic modifier is specified with the EXPORT command, the exported
XML document will be encoded in the UTF-16 code page regardless of the
application code page or the codepage file type modifier.

Table 8. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format
Modifier Description
chardelx x is a single character string delimiter. The default value is a double quotation
mark ("). The specified character is used in place of double quotation marks to
enclose a character string.2 If you want to explicitly specify the double quotation
mark as the character string delimiter, it should be specified as follows:
modified by chardel""

The single quotation mark (') can also be specified as a character string delimiter
as follows:
modified by chardel’’
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the output data set. Converts character data to this code page from the
application code page during the export operation.

For pure DBCS (graphic), mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive. The codepage modifier cannot be used with the
lobsinfile modifier.
coldelx x is a single character column delimiter. The default value is a comma (,). The
specified character is used in place of a comma to signal the end of a column.2

In the following example, coldel; causes the export utility to use the semicolon
character (;) as a column delimiter for the exported data:
db2 "export to temp of del modified by coldel;
select * from staff where dept = 20"
decplusblank Plus sign character. Causes positive decimal values to be prefixed with a blank
space instead of a plus sign (+). The default action is to prefix positive decimal
values with a plus sign.
decptx x is a single character substitute for the period as a decimal point character. The
default value is a period (.). The specified character is used in place of a period as
a decimal point character.2
nochardel Column data will not be surrounded by character delimiters. This option should
not be specified if the data is intended to be imported or loaded using DB2. It is
provided to support vendor data files that do not have character delimiters.
Improper usage might result in data loss or corruption.

This option cannot be specified with chardelx or nodoubledel. These are mutually
exclusive options.
nodoubledel Suppresses recognition of double character delimiters.2

Chapter 2. Export utility 33

Table 8. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format (continued)
Modifier Description
striplzeros Removes the leading zeros from all exported decimal columns.

Consider the following example:

db2 create table decimalTable ( c1 decimal( 31, 2 ) )
db2 insert into decimalTable values ( 1.1 )

db2 export to data of del select * from decimalTable

db2 export to data of del modified by STRIPLZEROS

select * from decimalTable

In the first export operation, the content of the exported file data will be
+00000000000000000000000000001.10. In the second operation, which is identical
to the first except for the striplzeros modifier, the content of the exported file
data will be +1.10.

34 Data Movement Utilities Guide and Reference

Table 8. Valid file type modifiers for the export utility: DEL (delimited ASCII) file format (continued)
Modifier Description
timestampformat="x" x is the format of the time stamp in the source file.4 Valid time stamp elements
are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 01 - 12;
mutually exclusive with M and MMM)
MMM - Month (three-letter case-insensitive abbreviation for
the month name; mutually exclusive with M and MM)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31; mutually exclusive with D)
DDD - Day of the year (three digits ranging from 001 - 366;
mutually exclusive with other day or month elements)
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system;
mutually exclusive with H)
M - Minute (one or two digits ranging from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M, minute)
S - Second (one or two digits ranging from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
UUUUUU - Microsecond (6 digits ranging from 000000 - 999999;
mutually exclusive with all other microsecond elements)
UUUUU - Microsecond (5 digits ranging from 00000 - 99999,
maps to range from 000000 - 999990;
mutually exclusive with all other microseond elements)
UUUU - Microsecond (4 digits ranging from 0000 - 9999,
maps to range from 000000 - 999900;
mutually exclusive with all other microseond elements)
UUU - Microsecond (3 digits ranging from 000 - 999,
maps to range from 000000 - 999000;
mutually exclusive with all other microseond elements)
UU - Microsecond (2 digits ranging from 00 - 99,
maps to range from 000000 - 990000;
mutually exclusive with all other microseond elements)
U - Microsecond (1 digit ranging from 0 - 9,
maps to range from 000000 - 900000;
mutually exclusive with all other microseond elements)
TT - Meridian indicator (AM or PM)

Following is an example of a time stamp format:

"YYYY/MM/DD HH:MM:SS.UUUUUU"

The MMM element will produce the following values: 'Jan', 'Feb', 'Mar', 'Apr',
'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', and 'Dec'. 'Jan' is equal to month 1, and
'Dec' is equal to month 12.

The following example illustrates how to export data containing user-defined

time stamp formats from a table called 'schedule':
db2 export to delfile2 of del
modified by timestampformat="yyyy.mm.dd hh:mm tt"
select * from schedule

Chapter 2. Export utility 35

Table 9. Valid file type modifiers for the export utility: IXF file format
Modifier Description
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the output data set. Converts character data from this code page to the
application code page during the export operation.

For pure DBCS (graphic), mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive.

Table 10. Valid file type modifiers for the export utility: WSF file format
Modifier Description
1 Creates a WSF file that is compatible with Lotus 1-2-3 Release 1, or Lotus 1-2-3
Release 1a.5 This is the default.
2 Creates a WSF file that is compatible with Lotus Symphony Release 1.0.5
3 Creates a WSF file that is compatible with Lotus 1-2-3 Version 2, or Lotus
Symphony Release 1.1.5
4 Creates a WSF file containing DBCS characters.

Note:
1. The export utility does not issue a warning if an attempt is made to use
unsupported file types with the MODIFIED BY option. If this is attempted, the
export operation fails, and an error code is returned.
2. Delimiter considerations for moving data lists restrictions that apply to the
characters that can be used as delimiter overrides.
3. The export utility normally writes
v date data in YYYYMMDD format
v char(date) data in "YYYY-MM-DD" format
v time data in "HH.MM.SS" format
v time stamp data in "YYYY-MM-DD-HH. MM.SS.uuuuuu" format
Data contained in any datetime columns specified in the SELECT statement
for the export operation will also be in these formats.
4. For time stamp formats, care must be taken to avoid ambiguity between the
month and the minute descriptors, since they both use the letter M. A month
field must be adjacent to other date fields. A minute field must be adjacent to
other time fields. Following are some ambiguous time stamp formats:
"M" (could be a month, or a minute)
"M:M" (Which is which?)
"M:YYYY:M" (Both are interpreted as month.)
"S:M:YYYY" (adjacent to both a time value and a date value)

In ambiguous cases, the utility will report an error message, and the operation
will fail.
Following are some unambiguous time stamp formats:
"M:YYYY" (Month)
"S:M" (Minute)
"M:YYYY:S:M" (Month....Minute)
"M:H:YYYY:M:D" (Minute....Month)
5. These files can also be directed to a specific product by specifying an L for
Lotus 1-2-3, or an S for Symphony in the filetype-mod parameter string. Only
one value or product designator can be specified.

36 Data Movement Utilities Guide and Reference

 6. The WSF file format is not supported for XML columns.
7. All XDM instances are written to XML files that are separate from the main
data file, even if neither the XMLFILE nor the XML TO clause is specified. By
default, XML files are written to the path of the exported data file. The default
base name for XML files is the name of the exported data file with the
extension ".xml" appended to it.
8. All XDM instances are written with an XML declaration at the beginning that
includes an encoding attribute, unless the XMLNODECLARATION file type
modifier is specified.
9. By default, all XDM instances are written in Unicode unless the XMLCHAR or
XMLGRAPHIC file type modifier is specified.
10. The default path for XML data and LOB data is the path of the main data file.
The default XML file base name is the main data file. The default LOB file
base name is the main data file. For example, if the main data file is
/mypath/myfile.del

, the default path for XML data and LOB data is

/mypath"

, the default XML file base name is

myfile.del

, and the default LOB file base name is

myfile.del

.
The LOBSINFILE file type modifier must be specified in order to have LOB
files generated.
11. The export utility appends a numeric identifier to each LOB file or XML file.
The identifier starts as a 3 digit, 0 padded sequence value, starting at
.001

. After the 999th LOB file or XML file, the identifier will no longer be padded
with zeroes (for example, the 1000th LOG file or XML file will have an
extension of
.1000

. Following the numeric identifier is a three character type identifier

representing the data type, either
.lob

or
.xml

. For example, a generated LOB file would have a name in the format
myfile.del.001.lob

, and a generated XML file would be have a name in the format

myfile.del.001.xml

.
12. It is possible to have the export utility export XDM instances that are not
well-formed documents by specifying an XQuery. However, you will not be
Chapter 2. Export utility 37
 able to import or load these exported documents directly into an XML
column, since XML columns can only contain complete documents.

db2Export - Export data from a database

Exports data from a database to one of several external file formats. The user
specifies the data to be exported by supplying an SQL SELECT statement, or by
providing hierarchical information for typed tables.

Authorization

One of the following:

v sysadm
v dbadm

or CONTROL or SELECT privilege on each participating table or view. Label-based

access control (LBAC) is enforced for this function. The data that is exported may
be limited by the LBAC credentials of the caller if the data is protected by LBAC.

Required connection

Database. If implicit connect is enabled, a connection to the default database is

established.

API include file

db2ApiDf.h

API and data structure syntax

SQL_API_RC SQL_API_FN
db2Export (
db2Uint32 versionNumber,
void * pParmStruct,
struct sqlca * pSqlca);

typedef SQL_STRUCTURE db2ExportStruct

{
char *piDataFileName;
struct sqlu_media_list *piLobPathList;
struct sqlu_media_list *piLobFileList;
struct sqldcol *piDataDescriptor;
struct sqllob *piActionString;
char *piFileType;
struct sqlchar *piFileTypeMod;
char *piMsgFileName;
db2int16 iCallerAction;
struct db2ExportOut *poExportInfoOut;
struct db2ExportIn *piExportInfoIn;
struct sqlu_media_list *piXmlPathList;
struct sqlu_media_list *piXmlFileList;
} db2ExportStruct;

typedef SQL_STRUCTURE db2ExportIn

{
db2Uint16 *piXmlSaveSchema;
} db2ExportIn;

typedef SQL_STRUCTURE db2ExportOut

{
db2Uint64 oRowsExported;
} db2ExportOut;

38 Data Movement Utilities Guide and Reference

SQL_API_RC SQL_API_FN
db2gExport (
db2Uint32 versionNumber,
void * pParmStruct,
struct sqlca * pSqlca);

typedef SQL_STRUCTURE db2gExportStruct

{
char *piDataFileName;
struct sqlu_media_list *piLobPathList;
struct sqlu_media_list *piLobFileList;
struct sqldcol *piDataDescriptor;
struct sqllob *piActionString;
char *piFileType;
struct sqlchar *piFileTypeMod;
char *piMsgFileName;
db2int16 iCallerAction;
struct db2ExportOut *poExportInfoOut;
db2Uint16 iDataFileNameLen;
db2Uint16 iFileTypeLen;
db2Uint16 iMsgFileNameLen;
struct db2ExportIn *piExportInfoIn;
struct sqlu_media_list *piXmlPathList;
struct sqlu_media_list *piXmlFileList;
} db2gExportStruct;

db2Export API parameters

versionNumber
Input. Specifies the version and release level of the structure passed as the
second parameter pParmStruct.
pParmStruct
Input. A pointer to the db2ExportStruct structure.
pSqlca
Output. A pointer to the sqlca structure.

db2ExportStruct data structure parameters

piDataFileName
Input. A string containing the path and the name of the external file into
which the data is to be exported.
piLobPathList
Input. Pointer to an sqlu_media_list structure with its media_type field set
to SQLU_LOCAL_MEDIA, and its sqlu_media_entry structure listing paths
on the client where the LOB files are to be stored. Exported LOB data will
be distributed evenly among all the paths listed in the sqlu_media_entry
structure.
piLobFileList
Input. Pointer to an sqlu_media_list structure with its media_type field set
to SQLU_CLIENT_LOCATION, and its sqlu_location_entry structure
containing base file names.
When the name space is exhausted using the first name in this list, the API
will use the second name, and so on. When creating LOB files during an
export operation, file names are constructed by appending the current base
name from this list to the current path (from piLobPathList), and then
appending a 3-digit sequence number and the .lob extension. For example,
if the current LOB path is the directory /u/foo/lob/path, the current LOB
file name is bar, and the LOBSINSEPFILES file type modifier is set, then

Chapter 2. Export utility 39

 the created LOB files will be /u/foo/LOB/path/bar.001.lob,
/u/foo/LOB/path/bar.002.lob, and so on. If the LOBSINSEPFILES file
type modifier is not set, then all the LOB documents will be concatenated
and put into one file /u/foo/lob/path/bar.001.lob
piDataDescriptor
Input. Pointer to an sqldcol structure specifying the column names for the
output file. The value of the dcolmeth field determines how the remainder
of the information provided in this parameter is interpreted by the export
utility. Valid values for this parameter (defined in sqlutil header file,
located in the include directory) are:
SQL_METH_N
Names. Specify column names to be used in the output file.
SQL_METH_D
Default. Existing column names from the table are to be used in
the output file. In this case, the number of columns and the
column specification array are both ignored. The column names are
derived from the output of the SELECT statement specified in
piActionString.
piActionString
Input. Pointer to an sqllob structure containing a valid dynamic SQL
SELECT statement. The structure contains a 4-byte long field, followed by
the characters that make up the SELECT statement. The SELECT statement
specifies the data to be extracted from the database and written to the
external file.
The columns for the external file (from piDataDescriptor), and the database
columns from the SELECT statement, are matched according to their
respective list/structure positions. The first column of data selected from
the database is placed in the first column of the external file, and its
column name is taken from the first element of the external column array.
piFileType
Input. A string that indicates the format of the data within the external file.
Supported external file formats (defined in sqlutil header file) are:
SQL_DEL
Delimited ASCII, for exchange with dBase, BASIC, and the IBM®
Personal Decision Series programs, and many other database
managers and file managers.
SQL_WSF
Worksheet formats for exchange with Lotus Symphony and 1-2-3
programs.
SQL_IXF
PC version of the Integration Exchange Format, the preferred
method for exporting data from a table. Data exported to this file
format can later be imported or loaded into the same table or into
another database manager table.
piFileTypeMod
Input. A pointer to an sqldcol structure containing a 2-byte long field,
followed by an array of characters that specify one or more processing
options. If this pointer is NULL, or the structure pointed to has zero
characters, this action is interpreted as selection of a default specification.

40 Data Movement Utilities Guide and Reference

 Not all options can be used with all of the supported file types. See related
link below: "File type modifiers for the export utility."
piMsgFileName
Input. A string containing the destination for error, warning, and
informational messages returned by the utility. It can be the path and the
name of an operating system file or a standard device. If the file already
exists, the information is appended . If it does not exist, a file is created.
iCallerAction
Input. An action requested by the caller. Valid values (defined in sqlutil
header file, located in the include directory) are:
SQLU_INITIAL
Initial call. This value must be used on the first call to the API. If
the initial call or any subsequent call returns and requires the
calling application to perform some action prior to completing the
requested export operation, the caller action must be set to one of
the following:
SQLU_CONTINUE
Continue processing. This value can only be used on subsequent
calls to the API, after the initial call has returned with the utility
requesting user input (for example, to respond to an end of tape
condition). It specifies that the user action requested by the utility
has completed, and the utility can continue processing the initial
request.
SQLU_TERMINATE
Terminate processing. This value can only be used on subsequent
calls to the API, after the initial call has returned with the utility
requesting user input (for example, to respond to an end of tape
condition). It specifies that the user action requested by the utility
was not performed, and the utility is to terminate processing the
initial request.
poExportInfoOut
A pointer to the db2ExportOut structure.
piExportInfoIn
Input. Pointer to the db2ExportIn structure.
piXmlPathList
Input. Pointer to an sqlu_media_list structure with its media_type field set
to SQLU_LOCAL_MEDIA, and its sqlu_media_entry structure listing paths
on the client where the XML files are to be stored. Exported XML data will
be distributed evenly among all the paths listed in the sqlu_media_entry
structure.
piXmlFileList
Input. Pointer to an sqlu_media_list structure with its media_type field set
to SQLU_CLIENT_LOCATION, and its sqlu_location_entry structure
containing base file names.
When the name space is exhausted using the first name in this list, the API
will use the second name, and so on. When creating XML files during an
export operation, file names are constructed by appending the current base
name from this list to the current path (from piXmlFileList), and then
appending a 3-digit sequence number and the .xml extension. For example,
if the current XML path is the directory /u/foo/xml/path, the current
XML file name is bar, and the XMLINSEPFILES file type modifier is set,

Chapter 2. Export utility 41

 then the created XML files will be /u/foo/xml/path/bar.001.xml,
/u/foo/xml/path/bar.002.xml, and so on. If the XMLINSEPFILES file type
modifier is not set, then all the XML documents will be concatenated and
put into one file /u/foo/xml/path/bar.001.xml

db2ExportIn data structure parameters

piXmlSaveSchema
Input. Indicates that the SQL identifier of the XML schema used to validate
each exported XML document should be saved in the exported data file.
Possible values are TRUE and FALSE.

db2ExportOut data structure parameters

oRowsExported
Output. Returns the number of records exported to the target file.

db2gExportStruct data structure specific parameters

iDataFileNameLen
Input. A 2-byte unsigned integer representing the length in bytes of the
data file name.
iFileTypeLen
Input. A 2-byte unsigned integer representing the length in bytes of the file
type.
iMsgFileNameLen
Input. A 2-byte unsigned integer representing the length in bytes of the
message file name.

Usage notes

Before starting an export operation, you must complete all table operations and
release all locks in one of two ways:
v Close all open cursors that were defined with the WITH HOLD clause, and
commit the data changes by executing the COMMIT statement.
v Roll back the data changes by executing the ROLLBACK statement.

Table aliases can be used in the SELECT statement.

The messages placed in the message file include the information returned from the
message retrieval service. Each message begins on a new line.

If the export utility produces warnings, the message will be written out to a
message file, or standard output if one is not specified.

A warning message is issued if the number of columns (dcolnum field of sqldcol

structure) in the external column name array, piDataDescriptor, is not equal to the
number of columns generated by the SELECT statement. In this case, the number
of columns written to the external file is the lesser of the two numbers. Excess
database columns or external column names are not used to generate the output
file.

If the db2uexpm.bnd module or any other shipped .bnd files are bound manually,
the format option on the binder must not be used.

42 Data Movement Utilities Guide and Reference

DB2 Connect can be used to export tables from DRDA servers such as DB2 for
z/OS® and OS/390, DB2 for VM and VSE, and DB2 for System i®. Only PC/IXF
export is supported.

PC/IXF import should be used to move data between databases. If character data
containing row separators is exported to a delimited ASCII (DEL) file and
processed by a text transfer program, fields containing the row separators will
shrink or expand.

The export utility will not create multiple-part PC/IXF files when invoked from an
AIX system.

Index definitions for a table are included in the PC/IXF file when the contents of a
single database table are exported to a PC/IXF file with a piActionString
parameter beginning with SELECT * FROM tablename, and the piDataDescriptor
parameter specifying default names. Indexes are not saved for views, or if the
SELECT clause of the piActionString includes a join. A WHERE clause, a GROUP
BY clause, or a HAVING clause in the piActionString parameter will not prevent
the saving of indexes. In all of these cases, when exporting from typed tables, the
entire hierarchy must be exported.

The export utility will store the NOT NULL WITH DEFAULT attribute of the table
in an IXF file if the SELECT statement provided is in the form: SELECT * FROM
tablename.

When exporting typed tables, subselect statements can only be expressed by

specifying the target table name and the WHERE clause. Fullselect and
select-statement cannot be specified when exporting a hierarchy.

For file formats other than IXF, it is recommended that the traversal order list be
specified, because it tells DB2 how to traverse the hierarchy, and what sub-tables to
export. If this list is not specified, all tables in the hierarchy are exported, and the
default order is the OUTER order. The alternative is to use the default order, which
is the order given by the OUTER function.

Note: Use the same traverse order during an import operation. The load utility
does not support loading hierarchies or sub-hierarchies.

REXX API syntax

EXPORT :stmt TO datafile OF filetype
[MODIFIED BY :filetmod] [USING :dcoldata]
MESSAGES msgfile [ROWS EXPORTED :number]

CONTINUE EXPORT

STOP EXPORT

REXX API parameters

stmt A REXX host variable containing a valid dynamic SQL SELECT statement.
The statement specifies the data to be extracted from the database.
datafile
Name of the file into which the data is to be exported.
filetype
The format of the data in the export file. The supported file formats are:

Chapter 2. Export utility 43

 DEL Delimited ASCII
WSF Worksheet format
IXF PC version of Integration Exchange Format.
filetmod
A host variable containing additional processing options.
dcoldata
A compound REXX host variable containing the column names to be used
in the export file. In the following, XXX represents the name of the host
variable:
XXX.0 Number of columns (number of elements in the remainder of the
variable).
XXX.1 First column name.
XXX.2 Second column name.
XXX.3 and so on.

If this parameter is NULL, or a value for dcoldata has not been specified,
the utility uses the column names from the database table.
msgfile
File, path, or device name where error and warning messages are to be
sent.
number
A host variable that will contain the number of exported rows.

Export sessions - CLP examples

Example 1
The following example shows how to export information from the STAFF table in
the SAMPLE database (to which the user must be connected) to myfile.ixf, with
the output in IXF format. If the database connection is not through DB2 Connect,
the index definitions (if any) will be stored in the output file; otherwise, only the
data will be stored:
db2 export to myfile.ixf of ixf messages msgs.txt select * from staff

Example 2
The following example shows how to export the information about employees in
Department 20 from the STAFF table in the SAMPLE database (to which the user
must be connected) to awards.ixf, with the output in IXF format:
db2 export to awards.ixf of ixf messages msgs.txt select * from staff
where dept = 20

Example 3
The following example shows how to export LOBs to a DEL file:
db2 export to myfile.del of del lobs to mylobs/
lobfile lobs1, lobs2 modified by lobsinfile
select * from emp_photo

Example 4
The following example shows how to export LOBs to a DEL file, specifying a
second directory for files that might not fit into the first directory:

44 Data Movement Utilities Guide and Reference

 db2 export to myfile.del of del
lobs to /db2exp1/, /db2exp2/ modified by lobsinfile
select * from emp_photo

Example 5
The following example shows how to export data to a DEL file, using a single
quotation mark as the string delimiter, a semicolon as the column delimiter, and a
comma as the decimal point. The same convention should be used when importing
data back into the database:
db2 export to myfile.del of del
modified by chardel’’ coldel; decpt,
select * from staff

Chapter 2. Export utility 45

46 Data Movement Utilities Guide and Reference
Chapter 3. Import utility
Import overview
The import utility populates a table, typed table, or view with data using an SQL
INSERT statement. If the table or view receiving the imported data already
contains data, the input data can either replace or be appended to the existing
data.

Like export, import is a relatively simple data movement utility. It can be activated
through the Control Center, by issuing CLP commands, by calling the
ADMIN_CMD stored procedure, or by calling its API, db2Import, through a user
application.

There are a number of data formats that import supports, as well as features that
can be used with import:
v Import supports IXF, WSF, ASC, and DEL data formats.
v Import can be used with file type modifiers to customize the import operation.
v Import can be used to move hierarchical data and typed tables.
v Import logs all activity, updates indexes, verifies constraints, and fires triggers.
v Import allows you to specify the names of the columns within the table or view
into which the data is to be inserted.
v Import can be used with DB2 Connect.

Import modes

Import has five modes which determine the method in which the data is imported.
The first three, INSERT, INSERT_UPDATE, and REPLACE are used when the
target tables already exist. All three support IXF, WSF, ASC, and DEL data formats.
However, only INSERT and INSERT_UPDATE can be used with nicknames.
Table 11. Overview of INSERT, INSERT_UPDATE, and REPLACE import modes
Mode Best practice usage
INSERT Inserts input data into target table without
changing existing data
INSERT_UPDATE Updates rows with matching primary key
values with values of input rows
Where there's no matching row, inserts
imported row into the table
REPLACE Deletes all existing data and inserts
imported data, while keeping table and
index definitions

The other two modes, REPLACE_CREATE and CREATE, are used when the target
tables do not exist. They can only be used with input files in the PC/IXF format,
which contains a structured description of the table that is to be created. Imports
cannot be performed in these modes if the object table has any dependents other
than itself.

© Copyright IBM Corp. 1993, 2010 47

 Note: Import's CREATE and REPLACE_CREATE modes are being deprecated. Use
the db2look utility instead.
Table 12. Overview of REPLACE_CREATE and CREATE import modes
Mode Best practice usage
REPLACE_CREATE Deletes all existing data and inserts
imported data, while keeping table and
index definitions
Creates target table and index if they don't
exist
CREATE Creates target table and index
Can specify the name of the table space
where the new table is created

How import works

The number of steps and the amount of time required for an import depend on the
amount of data being moved and the options that you specify. An import
operation follows these steps:
1. Locking tables
Import acquires either an exclusive (X) lock or a nonexclusive (IX) lock on
existing target tables, depending on whether you allow concurrent access to the
table.
2. Locating and retrieving data
Import uses the FROM clause to locate the input data. If your command
indicates that XML or LOB data is present, import will locate this data.
3. Inserting data
Import either replaces existing data or adds new rows of data to the table.
4. Checking constraints and firing triggers
As the data is written, import ensures that each inserted row complies with the
constraints defined on the target table. Information about rejected rows is
written to the messages file. Import also fires existing triggers.
5. Committing the operation
Import saves the changes made and releases the locks on the target table. You
can also specify that periodic take place during the import.

The following items are mandatory for a basic import operation:

v The path and the name of the input file
v The name or alias of the target table or view
v The format of the data in the input file
v The method by which the data is to be imported
v The traverse order, when importing hierarchical data
v The subtable list, when importing typed tables

Additional options
There are a number of options that allow you to customize an import operation.
You can specify file type modifiers in the MODIFIED BY clause to change the
format of the data, tell the import utility what to do with the data, and to improve
performance.

The import utility, by default, does not perform commits until the end of a
successful import, except in the case of some ALLOW WRITE ACCESS imports.

48 Data Movement Utilities Guide and Reference

 This improves the speed of an import, but for the sake of concurrency,
restartability, and active log space considerations, it might be preferable to specify
that commits take place during the import. One way of doing so is to set the
COMMITCOUNT parameter to “automatic,” which instructs import to internally
determine when it should perform a commit. Alternatively, you can set
COMMITCOUNT to a specific number, which instructs import to perform a
commit once that specified number of records has been imported.

There are a few ways to improve import's performance. As the import utility is an
embedded SQL application and does SQL fetches internally, optimizations that
apply to SQL operations apply to import as well. You can use the compound file
type modifier to perform a specified number of rows to insert at a time, rather
than the default row-by-row insertion. If you anticipate that a large number of
warnings will be generated (and, therefore, slow down the operation) during the
import, you can also specify the norowwarnings file type modifier to suppress
warnings about rejected rows.

Messages file
During an import, standard ASCII text message files are written to contain the
error, warning, and informational messages associated with that operation. If the
utility is invoked through the application programming interface (API) db2Import,
you must specify the name of these files in advance with the MESSAGES
parameter, otherwise it is optional. The messages file is a convenient way of
monitoring the progress of an import, as you can access is while the import is in
progress. In the event of a failed import operation, message files can be used to
determine a restarting point by indicating the last row that was successfully
imported.

Note: If the volume of output messages generated by an import operation against

a remote database exceeds 60 KB, the utility will keep the first 30 KB and the last
30 KB.

Privileges and authorities required to use import

Privileges enable users to create or access database resources. Authority levels
provide a method of grouping privileges and higher-level database manager
maintenance and utility operations. Together, these act to control access to the
database manager and its database objects.

Users can access only those objects for which they have the appropriate
authorization; that is, the required privilege or authority.

With SYSADM or DBADM authority, you can perform any type of import
operation. The table below lists the other authorities on each participating table,
view or nickname that enable you to perform the corresponding type of import.
Table 13. Authorities required to perform import operations
Mode Required authority
INSERT CONTROL or
INSERT and SELECT
INSERT_UPDATE CONTROL or
INSERT, SELECT, UPDATE, and DELETE
REPLACE CONTROL or
INSERT, SELECT, and DELETE

Chapter 3. Import utility 49

 Table 13. Authorities required to perform import operations (continued)
Mode Required authority
REPLACE_CREATE When the target table exists: CONTROL or
INSERT, SELECT, and DELETE
When the target table doesn't exist: CREATETAB (on the
database), USE (on the table space), and
when the schema does not exist: IMPLICIT_SCHEMA (on
the database), or
when the schema exists: CREATEIN (on the schema)
CREATE CREATETAB (on the database), USE (on the table space),
and
when the schema does not exist: IMPLICIT_SCHEMA (on
the database), or
when the schema exists: CREATEIN (on the schema)

Note: The CREATE and REPLACE_CREATE options of the IMPORT command

are deprecated and might be removed in a future release.
As well, to use the REPLACE or REPLACE_CREATE option on a table, the session
authorization ID must have the authority to drop the table.

If you want to import to a hierarchy, the required authority also depends on the
mode. For existing hierarchies, CONTROL privilege on every subtable in the
hierarchy is sufficient for a REPLACE operation. For hierarchies that don't exist,
CONTROL privilege on every subtable in the hierarchy, along with CREATETAB
and USE, is sufficient for a REPLACE_CREATE operation.

In addition, there a few considerations for importing into tables with label-based
access control (LBAC) security labels defined on them. To import data into a table
that has protected columns, the session authorization ID must have LBAC
credentials that allow write access to all protected columns in the table. To import
data into a table that has protected rows, the session authorization ID must have
been granted a security label for write access that is part of the security policy
protecting the table.

Importing data
The import utility inserts data from an external file with a supported file format
into a table, hierarchy, view or nickname. The load utility is a faster alternative, but
the load utility does not support loading data at the hierarchy level.

Before you begin

Before invoking the import utility, you must be connected to (or be able to
implicitly connect to) the database into which the data will be imported. If implicit
connect is enabled, a connection to the default database is established. Utility
access to DB2 for Linux, UNIX, or Windows database servers from DB2 for Linux,
UNIX, or Windows clients must be a direct connection through the engine and not
through a DB2 Connect gateway or loop back environment. Since the utility will
issue a COMMIT or a ROLLBACK statement, you should complete all transactions
and release all locks by issuing a COMMIT statement or a ROLLBACK operation
before invoking import.

Note: The CREATE and REPLACE_CREATE options of the IMPORT command are
deprecated and might be removed in a future release.

50 Data Movement Utilities Guide and Reference

About this task

The following restrictions apply to the import utility:

v If the existing table is a parent table containing a primary key that is referenced
by a foreign key in a dependent table, its data cannot be replaced, only
appended to.
v You cannot perform an import replace operation into an underlying table of a
materialized query table defined in refresh immediate mode.
v You cannot import data into a system table, a summary table, or a table with a
structured type column.
v You cannot import data into declared temporary tables.
v Views cannot be created through the import utility.
v Referential constraints and foreign key definitions are not preserved when
creating tables from PC/IXF files. (Primary key definitions are preserved if the
data was previously exported using SELECT *.)
v Because the import utility generates its own SQL statements, the maximum
statement size of 2 MB might, in some cases, be exceeded.
v You cannot re-create a partitioned table or an multidimensional clustered table
(MDC) using the CREATE or REPLACE_CREATE import options.
v You cannot re-create tables containing XML columns.
v You cannot import encrypted data.
v The import replace operation does not honor the Not Logged Initially clause.
The IMPORT command's REPLACE option does not honor the CREATE TABLE
statement's NOT LOGGED INITIALLY (NLI) clause or the ALTER TABLE
statement's ACTIVATE NOT LOGGED INITIALLY clause. If an import with the
REPLACE action is performed within the same transaction as a CREATE TABLE
or ALTER TABLE statement where the NLI clause is invoked, the import will
not honor the NLI clause. All inserts will be logged.
Workaround 1: Delete the contents of the table using the DELETE statement,
then invoke the import with INSERT statement.
Workaround 2: Drop the table and re-create it, then invoke the import with
INSERT statement.

The following limitation applies to the import utility: If the volume of output
messages generated by an import operation against a remote database exceeds 60
KB, the utility will keep the first 30 KB and the last 30 KB.

The import utility can be invoked through the command line processor (CLP), the
Import Table notebook in the Control Center, or by calling the application
programming interface (API) db2Import from a client application.

Using the Import Table notebook

Procedure
1. From the Control Center, expand the object tree until you find the Tables folder.
2. Click on the Tables folder. Any existing tables are displayed in the pane on the
right side of the window (the contents pane).
3. Right-click on the table you want in the contents pane, and select Import from
the pop-up menu. The Import Table notebook opens.

Chapter 3. Import utility 51

 Example

Detailed information about the Import Table notebook is provided through the
Control Center online help facility.

Issuing IMPORT commands through the CLP

A very simple import operation requires you to specify only an input file, a file
format, an import mode, and a target table (or the name of the table that is to be
created).

For example, to import data from the CLP, enter the IMPORT command:
db2 import from filename of fileformat import_mode into table

where filename is the name of the input file that contains the data you want to
import, ixf is the file format, insert is the mode, and table is the name of the
table that you want to insert the data into.

However, you might also want to specify a messages file to which warning and
error messages will be written. To do that, add the MESSAGES parameter and a
message file name so the command is:
db2 import from filename of fileformat messages messagefile import_mode into table

For complete syntax and usage information, see "IMPORT command."

Importing XML data

The import utility can be used to import XML data into an XML table column
using either the table name or a nickname for a DB2 Database for Linux, UNIX,
and Windows source data object.

When importing data into an XML table column, you can use the XML FROM
option to specify the paths of the input XML data file or files. For example, for an
XML file "/home/user/xmlpath/xmldocs.001.xml" that had previously been
exported, the following command could be used to import the data back into the
table.
IMPORT FROM t1export.del OF DEL XML FROM /home/user/xmlpath INSERT INTO USER.T1

Validating inserted documents against schemas

The XMLVALIDATE option allows XML documents to be validated against XML

schemas as they are imported. In the following example, incoming XML
documents are validated against schema information that was saved when the
XML documents were exported:
IMPORT FROM t1export.del OF DEL XML FROM /home/user/xmlpath XMLVALIDATE
USING XDS INSERT INTO USER.T1

Specifying parse options

You can use the XMLPARSE option to specify whether whitespace in the imported
XML documents is preserved or stripped. In the following example, all imported
XML documents are validated against XML schema information that was saved
when the XML documents were exported, and these documents are parsed with
whitespace preserved.
IMPORT FROM t1export.del OF DEL XML FROM /home/user/xmlpath XMLPARSE PRESERVE
WHITESPACE XMLVALIDATE USING XDS INSERT INTO USER.T1

52 Data Movement Utilities Guide and Reference

Imported table re-creation
You can use the import utility’s CREATE mode to re-create a table that was saved
through the export utility. However, there are a number of limitations on the
process, as many of the input table’s attributes are not retained.

For import to be able to re-create the table, the export operation must meet some
requirements. The original table must have been exported to an IXF file. If you
export files with DEL or ASC file formats, the output files do not contain
descriptions of the target table, but they contain the record data. To re-create a
table with data stored in these file formats, create the target table, then use the
load or import utility to populate the table from these files. You can use the
db2look utility to capture the original table definitions and to generate the
corresponding data definition language (DDL). As well, the SELECT statement
used during the export can only contain certain action strings. For example, no
column names can be used in the SELECT clause and only SELECT * is permitted.

Note: Import's CREATE mode is being deprecated. Use the db2look utility to
capture and re-create your tables.

Retained attributes
The re-created table will retain the following attributes of the original table:
v The primary key name, and definition
v Column information, including:
– Column name
– Column data type, including user-defined distinct types, which are preserved
as their base type
– Identity properties
– Lengths (except for lob_file types)
– Code page (if applicable)
– Identity options
– Whether the column is defined as nullable or not nullable
– Default values for constants, if any, but not other types of default values
v Index information, including:
– Index name
– Index creator name
– Column names, and whether each column is sorted in ascending or
descending order
– Whether the index is defined as unique
– Whether the index is clustered
– Whether the index allows reverse scans
– PCTFREE values
– MINPCTUSED values

Note: No index information is retained if the column names in the index contain
the characters - or +, in which case SQL27984W is returned.

Lost attributes
The re-created table does not retain several attributes of the original table,
including:

Chapter 3. Import utility 53

 v Whether the source was a normal table, a materialized query table (MQT), a
view, or a set of columns from any or all of these sources
v Unique constraints and other types of constraints or triggers (not including
primary key constraints)
v Table information, including:
– MQT definition (if applicable)
– MQT options (if applicable)
– Table space options; however, this information can be specified through the
IMPORT command
– Multidimensional clustering (MDC) dimensions
– Partitioned table dimensions
– Table partitioning key
– NOT LOGGED INITIALLY property
– Check constraints
– Table code page
– Protected table properties
– Table or value compression options
v Column information, including:
– Any default value except constant values
– LOB options (if any)
– XML properties
– References clause of the CREATE TABLE statement (if any)
– Referential constraints (if any)
– Check constraints (if any)
– Generated column options (if any)
– Columns dependent on database scope sequences
v Index information, including:
– INCLUDE columns (if any)
– Index name, if the index is a primary key index
– Descending order of keys, if the index is a primary key index (ascending is
the default)
– Index column names that contain hexadecimal values of 0x2B or 0x2D
– Index names that contain more than 128 bytes after code page conversion
– PCTFREE2 value
– Unique constraints

Note: This list is not exhaustive, use with care.

If the import fails and SQL3311N is returned, you can still re-create the table using
the file type modifier forcecreate. This modifier allows you to create the table
with missing or limited information.

Typed table import considerations

The import utility can be used to move data both from and into typed tables while
preserving the data’s preexisting hierarchy. If desired, import can also be used to
create the table hierarchy and the type hierarchy.

54 Data Movement Utilities Guide and Reference

The movement of data from one hierarchical structure of typed tables to another is
done through a specific traverse order and the creation of an intermediate flat file
during an export operation. In turn, the import utility controls the size and the
placement of the hierarchy being moved, using the CREATE, INTO table-name,
UNDER, and AS ROOT TABLE parameters. As well, import determines what is
placed in the target database. For example, it can specify an attributes list at the
end of each subtable name to restrict the attributes that are moved to the target
database. If no attributes list is used, all of the columns in each subtable are
moved.

Table re-creation
The type of import you are able to perform depends on the file format of the input
file. When working with ASC, DEL, or WSF data, the target table or hierarchy
must exist before the data can be imported. However, data from a PC/IXF file can
be imported even if the table or hierarchy does not already exist if you specify an
import CREATE operation. It must be noted that if the CREATE option is specified,
import cannot alter subtable definitions.

Traverse order
The traverse order contained in the input file enables the hierarchies in the data to
be maintained. Therefore, the same traverse order must be used when invoking the
export utility and the import utility.

For the PC/IXF file format, one need only specify the target subtable name, and
use the default traverse order stored in the file.

When using options other than CREATE with typed tables, the traverse order list
enables one to specify the traverse order. This user-specified traverse order must
match the one used during the export operation. The import utility guarantees the
accurate movement of data to the target database given the following:
v An identical definition of subtables in both the source and the target databases
v An identical hierarchical relationship among the subtables in both the source
and target databases
v An identical traverse order

Although you determine the starting point and the path down the hierarchy when
defining the traverse order, each branch must be traversed to the end before the
next branch in the hierarchy can be started. The import utility looks for violations
of this condition within the specified traverse order.

Examples

Examples in this section are based on the following hierarchical structure with four
valid traverse orders:
v Person, Employee, Manager, Architect, Student
v Person, Student, Employee, Manager, Architect
v Person, Employee, Architect, Manager, Student
v Person, Student, Employee, Architect, Manager

Chapter 3. Import utility 55

 8 1
Person
3 Person_t 2
(Oid, Name, Age)

5 Employee 6
Student
Employee_t
Student_t
4 (SerialNum, Salary, REF 7 (SerialNum, Marks)
(Department_t))

Manager Architect
Manager_t Architect_t
(Bonus) (StockOption)

Figure 2. An example of a hierarchy

Example 1
To re-create an entire hierarchy (contained in the data file entire_hierarchy.ixf
created by a prior export operation) using import, you would enter the following
commands:
DB2 CONNECT TO Target_db
DB2 IMPORT FROM entire_hierarchy.ixf OF IXF CREATE INTO
HIERARCHY STARTING Person AS ROOT TABLE

Each type in the hierarchy is created if it does not exist. If these types already
exist, they must have the same definition in the target database as in the source
database. An SQL error (SQL20013N) is returned if they are not the same. Since a
new hierarchy is being created, none of the subtables defined in the data file being
moved to the target database (Target_db) can exist. Each of the tables in the source
database hierarchy is created. Data from the source database is imported into the
correct subtables of the target database.

Example 2
To re-create the entire hierarchy of the source database and import it to the target
database, while only keeping selected data, you would enter the following
commands:
DB2 CONNECT TO Target_db
DB2 IMPORT FROM entire_hierarchy.del OF DEL INSERT INTO (Person,
Employee(Salary), Architect) IN HIERARCHY (Person, Employee,
Manager, Architect, Student)

The target tables PERSON, EMPLOYEE, and ARCHITECT must all exist. Data is
imported into the PERSON, EMPLOYEE, and ARCHITECT subtables. That is, the
following will be imported:
v All columns in PERSON into PERSON
v All columns in PERSON plus SALARY in EMPLOYEE into EMPLOYEE
v All columns in PERSON plus SALARY in EMPLOYEE, plus all columns in
ARCHITECT into ARCHITECT

56 Data Movement Utilities Guide and Reference

 Columns SerialNum and REF(Employee_t) are not imported into EMPLOYEE or its
subtables (that is, ARCHITECT, which is the only subtable having data imported
into it).

Note: Because ARCHITECT is a subtable of EMPLOYEE, and the only import

column specified for EMPLOYEE is SALARY, SALARY is also the only
Employee-specific column imported into ARCHITECT. That is, neither SerialNum
nor REF(Employee_t) columns are imported into either EMPLOYEE or
ARCHITECT rows.
Data for the MANAGER and the STUDENT tables is not imported.

Example 3
This example shows how to export from a regular table, and import as a single
subtable in a hierarchy. The EXPORT command operates on regular (non-typed)
tables, so there is no Type_id column in the data file. The file type modifier
no_type_id is used to indicate this, so that the import utility does not expect the
first column to be the Type_id column.
DB2 CONNECT TO Source_db
DB2 EXPORT TO Student_sub_table.del OF DEL SELECT * FROM
Regular_Student
DB2 CONNECT TO Target_db
DB2 IMPORT FROM Student_sub_table.del OF DEL METHOD P(1,2,3,5,4)
MODIFIED BY NO_TYPE_ID INSERT INTO HIERARCHY (Student)

In this example, the target table STUDENT must exist. Since STUDENT is a
subtable, the modifier no_type_id is used to indicate that there is no Type_id in the
first column. However, you must ensure that there is an existing Object_id column,
in addition to all of the other attributes that exist in the STUDENT table. Object-id
is expected to be the first column in each row imported into the STUDENT table.
The METHOD clause reverses the order of the last two attributes.

LBAC-protected data import considerations

For a successful import operation into a table with protected rows, you must have
LBAC (label-based access control) credentials. You must also provide a valid
security label, or a security label that can be converted to a valid label, for the
security policy currently associated with the target table.

If you do not have valid LBAC credentials, the import fails and an error
(SQLSTATE 42512) is returned. In cases where the input data does not contain a
security label or that security label is not in its internal binary format, you can use
several file type modifiers to allow your import to proceed.

When you import data into a table with protected rows, the target table has one
column with a data type of DB2SECURITYLABEL. If the input row of data does
not contain a value for that column, that row is rejected unless the usedefaults file
type modifier is specified in the import command, in which case the security label
you hold for write access from the security policy protecting the table is used. If
you do not hold a security label for write access, the row is rejected and processing
continues on to the next row.

When you import data into a table that has protected rows and the input data does
include a value for the column with a data type of DB2SECURITYLABEL, the
same rules are followed as when you insert data into that table. If the security
label protecting the row being imported (the one in that row of the data file) is one
that you are able to write to, then that security label is used to protect the row. (In
other words, it is written to the column that has a data type of

Chapter 3. Import utility 57

 DB2SECURITYLABEL.) If you are not able to write to a row protected by that
security label, what happens depends on how the security policy protecting the
source table was created:
v If the CREATE SECURITY POLICY statement that created the policy included
the option RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL, the insert
fails and an error is returned.
v If the CREATE SECURITY POLICY statement did not include the option or if it
instead included the OVERRIDE NOT AUTHORIZED WRITE SECURITY
LABEL option, the security label in the data file for that row is ignored and the
security label you hold for write access is used to protect that row. No error or
warning is issued in this case. If you do not hold a security label for write
access, the row is rejected and processing continues on to the next row.

Delimiter considerations
When importing data into a column with a data type of DB2SECURITYLABEL, the
value in the data file is assumed by default to be the actual bytes that make up the
internal representation of that security label. However, some raw data might
contain newline characters which could be misinterpreted by the IMPORT
command as delimiting the row. If you have this problem, use the delprioritychar
file type modifier to ensure that the character delimiter takes precedence over the
row delimiter. When you use delprioritychar, any record or column delimiters
that are contained within character delimiters are not recognized as being
delimiters. Using the delprioritychar file type modifier is safe to do even if none
of the values contain a newline character, but it does slow the import down
slightly.

If the data being imported is in ASC format, you might want to take an extra step
in order to prevent any trailing white space from being included in the imported
security labels and security label names. ASCII format uses column positions as
delimiters, so this might occur when importing into variable-length fields. Use the
striptblanks file type modifier to truncate any trailing blank spaces.

Nonstandard security label values

You can also import data files in which the values for the security labels are strings
containing the values of the components in the security label, for example,
S:(ALPHA,BETA). To do so you must use the file type modifier seclabelchar.
When you use seclabelchar, a value for a column with a data type of
DB2SECURITYLABEL is assumed to be a string constant containing the security
label in the string format for security labels. If a string is not in the proper format,
the row is not inserted and a warning (SQLSTATE 01H53) is returned. If the string
does not represent a valid security label that is part of the security policy
protecting the table, the row is not inserted and a warning (SQLSTATE 01H53) is
returned.

You can also import a data file in which the values of the security label column are
security label names. To import this sort of file you must use the file type modifier
seclabelname. When you use seclabelname, all values for columns with a data type
of DB2SECURITYLABEL are assumed to be string constants containing the names
of existing security labels. If no security label exists with the indicated name for
the security policy protecting the table, the row is not inserted and a warning
(SQLSTATE 01H53) is returned.

58 Data Movement Utilities Guide and Reference

 Examples

For all examples, the input data file myfile.del is in DEL format. All are importing
data into a table named REPS, which was created with this statement:
create table reps (row_label db2securitylabel,
id integer,
name char(30))
security policy data_access_policy

For this example, the input file is assumed to contain security labels in the default
format:
db2 import from myfile.del of del modified by delprioritychar insert into reps

For this example, the input file is assumed to contain security labels in the security
label string format:
db2 import from myfile.del of del modified by seclabelchar insert into reps

For this example, the input file is assumed to contain security labels names for the
security label column:
db2 import from myfile.del of del modified by seclabelname insert into reps

Buffered-insert imports
In a partitioned database environment, the import utility can be enabled to use
buffered inserts. This reduces the messaging that occurs when data is imported,
resulting in better performance.

The buffered inserts option should only be enabled if you are not concerned about
error reporting, since details about a failed buffered insert are not returned.

When buffered inserts are used, import sets a default WARNINGCOUNT value to
1. As a result, the operation will fail if any rows are rejected. If a record is rejected,
the utility will roll back the current transaction. The number of committed records
can be used to determine which records were successfully inserted into the
database. The number of committed records can be non zero only if the
COMMITCOUNT option was specified.

If a different WARNINGCOUNT value is explicitly specified on the import

command, and some rows are rejected, the row summary output by the utility can
be incorrect. This is due to a combination of the asynchronous error reporting used
with buffered inserts and the fact that an error detected during the insertion of a
group of rows causes all the rows of that group to be backed out. Since the utility
would not reliably report which input records were rejected, it would be difficult
to determine which records were committed and which records need to be
re-inserted into the database.

Use the DB2 bind utility to request buffered inserts. The import package,
db2uimpm.bnd, must be rebound against the database using the INSERT BUF
option. For example:
db2 connect to your_database
db2 bind db2uimpm.bnd insert buf

Buffered inserts feature cannot be used in conjunction with import operations in

the INSERT_UPDATE mode. The bind file db2uImpInsUpdate.bnd enforces this
restriction. This file should never be bound with the INSERT BUF option. This

Chapter 3. Import utility 59

 causes the import operations in the INSERT_UPDATE mode to fail. Import
operations in the INSERT, REPLACE, or REPLACE_CREATE modes are not
affected by the binding of the new file.

Identity column import considerations

The import utility can be used to import data into a table containing an identity
column whether or not the input data has identity column values.

If no identity-related file type modifiers are used, the utility works according to the
following rules:
v If the identity column is GENERATED ALWAYS, an identity value is generated
for a table row whenever the corresponding row in the input file is missing a
value for the identity column, or a NULL value is explicitly given. If a
non-NULL value is specified for the identity column, the row is rejected
(SQL3550W).
v If the identity column is GENERATED BY DEFAULT, the import utility makes
use of user-supplied values, if they are provided; if the data is missing or
explicitly NULL, a value is generated.

The import utility does not perform any extra validation of user-supplied identity
values beyond what is normally done for values of the identity column's data type
(that is, SMALLINT, INT, BIGINT, or DECIMAL). Duplicate values will not be
reported. In addition, the compound=x modifier cannot be used when importing
data into a table with an identity column.

There are two ways you can simplify the import of data into tables that contain an
identity column: the identitymissing and the identityignore file type modifiers.

Importing data without an identity column

The identitymissing modifier makes importing a table with an identity column
more convenient if the input data file does not contain any values (not even
NULLS) for the identity column. For example, consider a table defined with the
following SQL statement:
create table table1 (c1 char(30),
c2 int generated by default as identity,
c3 real,
c4 char(1))

A user might want to import data from a file (import.del) into TABLE1, and this
data might have been exported from a table that does not have an identity column.
The following is an example of such a file:
Robert, 45.2, J
Mike, 76.9, K
Leo, 23.4, I

One way to import this file would be to explicitly list the columns to be imported
through the IMPORT command as follows:
db2 import from import.del of del replace into table1 (c1, c3, c4)

For a table with many columns, however, this syntax might be cumbersome and
prone to error. An alternate method of importing the file is to use the
identitymissing file type modifier as follows:
db2 import from import.del of del modified by identitymissing
replace into table1

60 Data Movement Utilities Guide and Reference

 Importing data with an identity column
The identityignore modifier is in some ways the opposite of the identitymissing
modifier: it indicates to the import utility that even though the input data file
contains data for the identity column, the data should be ignored, and an identity
value should be generated for each row. For example, a user might want to import
the following data from a file (import.del) into TABLE1, as defined above:
Robert, 1, 45.2, J
Mike, 2, 76.9, K
Leo, 3, 23.4, I

If the user-supplied values of 1, 2, and 3 are not to be used for the identity
column, the user could issue the following IMPORT command:
db2 import from import.del of del method P(1, 3, 4)
replace into table1 (c1, c3, c4)

Again, this approach might be cumbersome and prone to error if the table has
many columns. The identityignore modifier simplifies the syntax as follows:
db2 import from import.del of del modified by identityignore
replace into table1

When a table with an identity column is exported to an IXF file, the

REPLACE_CREATE and the CREATE options of the IMPORT command can be
used to re-create the table, including its identity column properties. If such an IXF
file is created from a table containing an identity column of type GENERATED
ALWAYS, the only way that the data file can be successfully imported is to specify
the identityignore modifier. Otherwise, all rows will be rejected (SQL3550W).

Note: The CREATE and REPLACE_CREATE options of the IMPORT command are
deprecated and might be removed in a future release.

Generated column import considerations

The import utility can be used to import data into a table containing (nonidentity)
generated columns whether or not the input data has generated column values.

If no generated column-related file type modifiers are used, the import utility
works according to the following rules:
v A value is generated for a generated column whenever the corresponding row in
the input file is missing a value for the column, or a NULL value is explicitly
given. If a non-NULL value is supplied for a generated column, the row is
rejected (SQL3550W).
v If the server generates a NULL value for a generated column that is not nullable,
the row of data to which this field belongs is rejected (SQL0407N). This could
happen, for example, if a non-nullable generated column were defined as the
sum of two table columns that have NULL values supplied to them in the input
file.

There are two ways you can simplify the import of data into tables that contain a
generated column: the generatedmissing and the generatedignore file type
modifiers.

Importing data without generated columns

The generatedmissing modifier makes importing data into a table with generated
columns more convenient if the input data file does not contain any values (not
even NULLS) for all generated columns present in the table. For example, consider
a table defined with the following SQL statement:

Chapter 3. Import utility 61

 create table table1 (c1 int,
c2 int,
g1 int generated always as (c1 + c2),
g2 int generated always as (2 * c1),
c3 char(1))

A user might want to import data from a file (load.del) into TABLE1, and this
data might have been exported from a table that does not have any generated
columns. The following is an example of such a file:
1, 5, J
2, 6, K
3, 7, I

One way to import this file would be to explicitly list the columns to be imported
through the IMPORT command as follows:
db2 import from import.del of del replace into table1 (c1, c2, c3)

For a table with many columns, however, this syntax might be cumbersome and
prone to error. An alternate method of importing the file is to use the
generatedmissing file type modifier as follows:
db2 import from import.del of del modified by generatedmissing
replace into table1

Importing data with generated columns

The generatedignore modifier is in some ways the opposite of the
generatedmissing modifier: it indicates to the import utility that even though the
input data file contains data for all generated columns, the data should be ignored,
and values should be generated for each row. For example, a user might want to
import the following data from a file (import.del) into TABLE1, as defined above:
1, 5, 10, 15, J
2, 6, 11, 16, K
3, 7, 12, 17, I

The user-supplied, non-NULL values of 10, 11, and 12 (for g1), and 15, 16, and 17
(for g2) result in the row being rejected (SQL3550W). To avoid this, the user could
issue the following IMPORT command:
db2 import from import.del of del method P(1, 2, 5)
replace into table1 (c1, c2, c3)

Again, this approach might be cumbersome and prone to error if the table has
many columns. The generatedignore modifier simplifies the syntax as follows:
db2 import from import.del of del modified by generatedignore
replace into table1

For an INSERT_UPDATE, if the generated column is also a primary key and the
generatedignore modifier is specified, the IMPORT command honors the
generatedignore modifier. The IMPORT command does not substitute the
user-supplied value for this column in the WHERE clause of the UPDATE
statement.

LOB import considerations

Since the import utility restricts the size of a single column value to 32 KB, extra
considerations need to be taken when importing LOBs.

The import utility, by default, treats data in the input file as data to load into the
column. However, when large object (LOB) data is stored in the main input data

62 Data Movement Utilities Guide and Reference

 file, the size of the data is limited to 32 KB. Therefore, to prevent loss of data, LOB
data should be stored separate from the main datafile and the lobsinfile file type
modifier should be specified when importing LOBs.

The LOBS FROM clause implicitly activates lobsinfile. The LOBS FROM clause
conveys to the import utility the list of paths to search for the LOB files while
importing the data. If LOBS FROM option is not specified, the LOB files to import
are assumed to reside in the same path as the input relational data file.

Indicating where LOB data is stored

The LOB Location Specifier (LLS) can be used to store multiple LOBs in a single
file when importing the LOB information. The export utility generates and stores it
in the export output file when lobsinfile is specified, and it indicates where LOB
data can be found. When data with the modified by lobsinfile option specified is
being imported, the database will expect an LLS for each of the corresponding
LOB columns. If something other than an LLS is encountered for a LOB column,
the database will treat it as a LOB file and will load the entire file as the LOB.

For an import in CREATE mode, you can specify that the LOB data be created and
stored in a separate table space by using the LONG IN clause.

The following example shows how you would import an DEL file which has its
LOBs stored in separate files:
IMPORT FROM inputfile.del OF DEL
LOBS FROM /tmp/data
MODIFIED BY lobsinfile
INSERT INTO newtable

User-defined distinct types import considerations

The import utility casts user-defined distinct types (UDTs) to similar base data
types automatically. This saves you from having to explicitly cast UDTs to the base
data types. Casting allows for comparisons between UDTs and the base data types
in SQL.

Additional considerations for import

Client/server environments and import

When you import a file to a remote database, a stored procedure can be called to
perform the import on the server.

A stored procedure cannot be called when:

v The application and database code pages are different.
v The file being imported is a multiple-part PC/IXF file.
v The method used for importing the data is either column name or relative
column position.
v The target column list provided is longer than 4 KB.
v The LOBS FROM clause or the lobsinfile modifier is specified.
v The NULL INDICATORS clause is specified for ASC files.

When import uses a stored procedure, messages are created in the message file
using the default language installed on the server. The messages are in the
language of the application if the language at the client and the server are the
same.

Chapter 3. Import utility 63

 The import utility creates two temporary files in the tmp subdirectory of the sqllib
directory (or the directory indicated by the DB2INSTPROF registry variable, if
specified). One file is for data, and the other file is for messages generated by the
import utility.

If you receive an error about writing or opening data on the server, ensure that:
v The directory exists.
v There is sufficient disk space for the files.
v The instance owner has write permission in the directory.

Table locking during import

The import utility supports two table locking modes: offline, or ALLOW NO
ACCESS, mode; and online, or ALLOW WRITE ACCESS mode.

ALLOW NO ACCESS mode prevents concurrent applications from accessing table

data. ALLOW WRITE ACCESS mode allows concurrent applications both read and
write access to the import target table. If no mode is explicitly specified, import
runs in the default mode, ALLOW NO ACCESS. As well, the import utility is, by
default, bound to the database with isolation level RS (read stability).

Offline import (ALLOW NO ACCESS)

In ALLOW NO ACCESS mode, import acquires an exclusive (X) lock on the target
table is before inserting any rows. Holding a lock on a table has two implications:
v First, if there are other applications holding a table lock or row locks on the
import target table, the import utility waits for those applications to commit or
roll back their changes.
v Second, while import is running, any other application requesting locks waits for
the import operation to complete.

Note: You can specify a locktimeout value, which prevents applications (including
the import utility) from waiting indefinitely for a lock.
By requesting an exclusive lock at the beginning of the operation, import prevents
deadlocks from occurring as a result of other applications working and holding
row locks on the same target table.

Online import (ALLOW WRITE ACCESS)

In ALLOW WRITE ACCESS mode, the import utility acquires a nonexclusive (IX)
lock on the target table. Holding this lock on the table has the following
implications:
v If there are other applications holding an incompatible table lock, the import
utility does not start inserting data until all of these applications commit or roll
back their changes.
v While import is running, any other application requesting an incompatible table
lock waits until the import commits or rolls back the current transaction. Note
that import's table lock does not persist across a transaction boundary. As a
result, online import has to request and potentially wait for a table lock after
every commit.
v If there are other applications holding an incompatible row lock, the import
utility stops inserting data until all of these applications commit or roll back
their changes.

64 Data Movement Utilities Guide and Reference

 v While import is running, any other application requesting an incompatible row
lock waits until the import operation commits or rolls back the current
transaction.

To preserve the online properties, and to reduce the chance of a deadlock, an

ALLOW WRITE ACCESS import periodically commits the current transaction and
releases all row locks before escalating to an exclusive table lock. If you have not
explicitly set a commit frequency, import performs commits as if COMMITCOUNT
AUTOMATIC has been specified. No commits are performed if COMMITCOUNT
is set to 0.

ALLOW WRITE ACCESS mode is not compatible with the following:

v Imports in REPLACE, CREATE, or REPLACE_CREATE mode
v Imports with buffered inserts
v Imports into a target view
v Imports into a hierarchy table
v Imports into a table with its lock granularity is set at the table level (set by using
the LOCKSIZE parameter of the ALTER TABLE statement)

Reference - Import

IMPORT
Inserts data from an external file with a supported file format into a table,
hierarchy, view or nickname. LOAD is a faster alternative, but the load utility does
not support loading data at the hierarchy level.

Quick link to “File type modifiers for the import utility” on page 79.

Authorization
v IMPORT using the INSERT option requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on each participating table, view, or nickname
– INSERT and SELECT privilege on each participating table or view
v IMPORT to an existing table using the INSERT_UPDATE option, requires one of
the following:
– sysadm
– dbadm
– CONTROL privilege on each participating table, view, or nickname
– INSERT, SELECT, UPDATE and DELETE privilege on each participating table
or view
v IMPORT to an existing table using the REPLACE or REPLACE_CREATE option,
requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on the table or view
– INSERT, SELECT, and DELETE privilege on the table or view
v IMPORT to a new table using the CREATE or REPLACE_CREATE option,
requires one of the following:

Chapter 3. Import utility 65

 – sysadm
– dbadm
– CREATETAB authority on the database and USE privilege on the table space,
as well as one of:
- IMPLICIT_SCHEMA authority on the database, if the implicit or explicit
schema name of the table does not exist
- CREATEIN privilege on the schema, if the schema name of the table refers
to an existing schema
v IMPORT to a hierarchy that does not exist using the CREATE, or the
REPLACE_CREATE option, requires one of the following:
– sysadm
– dbadm
– CREATETAB authority on the database and USE privilege on the table space
and one of:
- IMPLICIT_SCHEMA authority on the database, if the schema name of the
table does not exist
- CREATEIN privilege on the schema, if the schema of the table exists
- CONTROL privilege on every sub-table in the hierarchy, if the
REPLACE_CREATE option on the entire hierarchy is used
v IMPORT to an existing hierarchy using the REPLACE option requires one of the
following:
– sysadm
– dbadm
– CONTROL privilege on every sub-table in the hierarchy
v To import data into a table that has protected columns, the session authorization
ID must have LBAC credentials that allow write access to all protected columns
in the table. Otherwise the import fails and an error (SQLSTATE 42512) is
returned.
v To import data into a table that has protected rows, the session authorization ID
must hold LBAC credentials that meet these criteria:
– It is part of the security policy protecting the table
– It was granted to the session authorization ID for write access
The label on the row to insert, the user's LBAC credentials, the security policy
definition, and the LBAC rules determine the label on the row.
v If the REPLACE or REPLACE_CREATE option is specified, the session
authorization ID must have the authority to drop the table.
v To import data into a nickname, the session authorization ID must have the
privilege to access and use a specified data source in pass-through mode.

Required connection

Command syntax


IMPORT FROM filename OF filetype

,

LOBS FROM  lob-path

66 Data Movement Utilities Guide and Reference




,

XML FROM  xml-path MODIFIED BY  filetype-mod

METHOD L-method_specs
,

N (  column-name )
,

P (  column-position )

XMLPARSE STRIP WHITESPACE
PRESERVE

ALLOW NO ACCESS



XMLVALIDATE USING XDS-specs ALLOW WRITE ACCESS
SCHEMA schema-sqlid
SCHEMALOCATION HINTS

COMMITCOUNT n RESTARTCOUNT n ROWCOUNT n
AUTOMATIC SKIPCOUNT

WARNINGCOUNT n NOTIMEOUT

INSERT INTO insert-table-specs


INSERT_UPDATE
REPLACE
REPLACE_CREATE
CREATE INTO create-table-specs tblspace-specs

create-table-specs:

table-name
,

(  insert-column )
hierarchy description AS ROOT TABLE
UNDER sub-table-name

Chapter 3. Import utility 67

 insert-table-specs:

table-name
,

(  insert-column )
hierarchy description

hierarchy description:

ALL TABLES
sub-table-list HIERARCHY STARTING sub-table-name
IN traversal-order-list

L-method-specs:

L (  column-start column-end )

,

NULL INDICATORS (  null-indicator-list )

sub-table-list:

(  sub-table-name )
,

(  insert-column )

traversal-order-list:

(  sub-table-name )

tblspace-specs:

IN tablespace-name
INDEX IN tablespace-name LONG IN tablespace-name

XDS-specs:

XDS

DEFAULT schema-sqlid ,

IGNORE (  schema-sqlid )

68 Data Movement Utilities Guide and Reference



,

MAP (  ( schema-sqlid , schema-sqlid ) )

Command parameters
ALL TABLES
An implicit keyword for hierarchy only. When importing a hierarchy, the
default is to import all tables specified in the traversal order.
ALLOW NO ACCESS
Runs import in the offline mode. An exclusive (X) lock on the target table
is acquired before any rows are inserted. This prevents concurrent
applications from accessing table data. This is the default import behavior.
ALLOW WRITE ACCESS
Runs import in the online mode. An intent exclusive (IX) lock on the target
table is acquired when the first row is inserted. This allows concurrent
readers and writers to access table data. Online mode is not compatible
with the REPLACE, CREATE, or REPLACE_CREATE import options.
Online mode is not supported in conjunction with buffered inserts. The
import operation will periodically commit inserted data to prevent lock
escalation to a table lock and to avoid running out of active log space.
These commits will be performed even if the COMMITCOUNT option
was not used. During each commit, import will lose its IX table lock, and
will attempt to reacquire it after the commit. This parameter is required
when you import to a nickname and COMMITCOUNT must be specified
with a valid number (AUTOMATIC is not considered a valid option).
AS ROOT TABLE
Creates one or more sub-tables as a stand-alone table hierarchy.
COMMITCOUNT n | AUTOMATIC
Performs a COMMIT after every n records are imported. When a number n
is specified, import performs a COMMIT after every n records are
imported. When compound inserts are used, a user-specified commit
frequency of n is rounded up to the first integer multiple of the compound
count value. When AUTOMATIC is specified, import internally determines
when a commit needs to be performed. The utility will commit for either
one of two reasons:
v to avoid running out of active log space
v to avoid lock escalation from row level to table level
If the ALLOW WRITE ACCESS option is specified, and the
COMMITCOUNT option is not specified, the import utility will perform
commits as if COMMITCOUNT AUTOMATIC had been specified.

The ability of the import operation to avoid running out of active log space
is affected by the DB2 registry variable
DB2_FORCE_APP_ON_MAX_LOG:
v If DB2_FORCE_APP_ON_MAX_LOG is set to FALSE and the
COMMITCOUNT AUTOMATIC command option is specified, the
import utility will be able to automatically avoid running out of active
log space.
v If DB2_FORCE_APP_ON_MAX_LOG is set to FALSE and the
COMMITCOUNT n command option is specified, the import utility will

Chapter 3. Import utility 69

 attempt to resolve the log full condition if it encounters an SQL0964C
(Transaction Log Full) while inserting or updating a record. It will
perform an unconditional commit and then will reattempt to insert or
update the record. If this does not help resolve the issue (which would
be the case when the log full is attributed to other activity on the
database), then the IMPORT command will fail as expected, however the
number of rows committed may not be a multiple of the
COMMITCOUNT n value. To avoid processing the rows that were
already committed when you retry the import operation, use the
RESTARTCOUNT or SKIPCOUNT command parameters.
v If DB2_FORCE_APP_ON_MAX_LOG is set to TRUE (which is the
default), the import operation will fail if it encounters an SQL0964C
while inserting or updating a record. This can occur irrespective of
whether you specify COMMITCOUNT AUTOMATIC or
COMMITCOUNT n.
The application is forced off the database and the current unit of work is
rolled back. To avoid processing the rows that were already committed
when you retry the import operation, use the RESTARTCOUNT or
SKIPCOUNT command parameters.
CREATE

Note: The CREATE parameter is deprecated and may be removed in a

future release. For additional details, see “IMPORT command options
CREATE and REPLACE_CREATE are deprecated”.
Creates the table definition and row contents in the code page of the
database. If the data was exported from a DB2 table, sub-table, or
hierarchy, indexes are created. If this option operates on a hierarchy, and
data was exported from DB2, a type hierarchy will also be created. This
option can only be used with IXF files.
This parameter is not valid when you import to a nickname.

Note: If the data was exported from an MVS™ host database, and it
contains LONGVAR fields whose lengths, calculated on the page size, are
more than 254, CREATE might fail because the rows are too long. See
“Imported table re-creation” for a list of restrictions. In this case, the table
should be created manually, and IMPORT with INSERT should be
invoked, or, alternatively, the LOAD command should be used.
DEFAULT schema-sqlid
This option can only be used when the USING XDS parameter is
specified. The schema specified through the DEFAULT clause identifies a
schema to use for validation when the XML Data Specifier (XDS) of an
imported XML document does not contain an SCH attribute identifying an
XML Schema.
The DEFAULT clause takes precedence over the IGNORE and MAP
clauses. If an XDS satisfies the DEFAULT clause, the IGNORE and MAP
specifications will be ignored.
FROM filename
HIERARCHY
Specifies that hierarchical data is to be imported.
IGNORE schema-sqlid
This option can only be used when the USING XDS parameter is

70 Data Movement Utilities Guide and Reference

 specified. The IGNORE clause specifies a list of one or more schemas to
ignore if they are identified by an SCH attribute. If an SCH attribute exists
in the XML Data Specifier for an imported XML document, and the schema
identified by the SCH attribute is included in the list of schemas to ignore,
then no schema validation will occur for the imported XML document.
If a schema is specified in the IGNORE clause, it cannot also be present in
the left side of a schema pair in the MAP clause.
The IGNORE clause applies only to the XDS. A schema that is mapped by
the MAP clause will not be subsequently ignored if specified by the
IGNORE clause.
IN tablespace-name
Identifies the table space in which the table will be created. The table space
must exist, and must be a REGULAR table space. If no other table space is
specified, all table parts are stored in this table space. If this clause is not
specified, the table is created in a table space created by the authorization
ID. If none is found, the table is placed into the default table space
USERSPACE1. If USERSPACE1 has been dropped, table creation fails.
INDEX IN tablespace-name
Identifies the table space in which any indexes on the table will be created.
This option is allowed only when the primary table space specified in the
IN clause is a DMS table space. The specified table space must exist, and
must be a REGULAR or LARGE DMS table space.

Note: Specifying which table space will contain an index can only be done
when the table is created.
insert-column
Specifies the name of a column in the table or the view into which data is
to be inserted.
INSERT
Adds the imported data to the table without changing the existing table
data.
INSERT_UPDATE
Adds rows of imported data to the target table, or updates existing rows
(of the target table) with matching primary keys.
INTO table-name
Specifies the database table into which the data is to be imported. This
table cannot be a system table, a declared temporary table or a summary
table.
One can use an alias for INSERT, INSERT_UPDATE, or REPLACE, except
in the case of an earlier server, when the fully qualified or the unqualified
table name should be used. A qualified table name is in the form:
schema.tablename. The schema is the user name under which the table was
created.
LOBS FROM lob-path
The names of the LOB data files are stored in the main data file (ASC,
DEL, or IXF), in the column that will be loaded into the LOB column. The
maximum number of paths that can be specified is 999. This will implicitly
activate the LOBSINFILE behavior.
This parameter is not valid when you import to a nickname.

Chapter 3. Import utility 71

 LONG IN tablespace-name
Identifies the table space in which the values of any long columns (LONG
VARCHAR, LONG VARGRAPHIC, LOB data types, or distinct types with
any of these as source types) will be stored. This option is allowed only if
the primary table space specified in the IN clause is a DMS table space.
The table space must exist, and must be a LARGE DMS table space.
MAP schema-sqlid
This option can only be used when the USING XDS parameter is
specified. Use the MAP clause to specify alternate schemas to use in place
of those specified by the SCH attribute of an XML Data Specifier (XDS) for
each imported XML document. The MAP clause specifies a list of one or
more schema pairs, where each pair represents a mapping of one schema
to another. The first schema in the pair represents a schema that is referred
to by an SCH attribute in an XDS. The second schema in the pair
represents the schema that should be used to perform schema validation.
If a schema is present in the left side of a schema pair in the MAP clause,
it cannot also be specified in the IGNORE clause.
Once a schema pair mapping is applied, the result is final. The mapping
operation is non-transitive, and therefore the schema chosen will not be
subsequently applied to another schema pair mapping.
A schema cannot be mapped more than once, meaning that it cannot
appear on the left side of more than one pair.
METHOD
L Specifies the start and end column numbers from which to import
data. A column number is a byte offset from the beginning of a
row of data. It is numbered starting from 1.

Note: This method can only be used with ASC files, and is the
only valid option for that file type.
N Specifies the names of the columns in the data file to be imported.
The case of these column names must match the case of the
corresponding names in the system catalogs. Each table column
that is not nullable should have a corresponding entry in the
METHOD N list. For example, given data fields F1, F2, F3, F4, F5,
and F6, and table columns C1 INT, C2 INT NOT NULL, C3 INT
NOT NULL, and C4 INT, method N (F2, F1, F4, F3) is a valid
request, while method N (F2, F1) is not valid.

Note: This method can only be used with IXF files.

P Specifies the field numbers of the input data fields to be imported.

Note: This method can only be used with IXF or DEL files, and is
the only valid option for the DEL file type.
MODIFIED BY filetype-mod
Specifies file type modifier options. See “File type modifiers for the import
utility” on page 79.
NOTIMEOUT
Specifies that the import utility will not time out while waiting for locks.
This option supersedes the locktimeout database configuration parameter.
Other applications are not affected.

72 Data Movement Utilities Guide and Reference

NULL INDICATORS null-indicator-list
This option can only be used when the METHOD L parameter is specified.
That is, the input file is an ASC file. The null indicator list is a
comma-separated list of positive integers specifying the column number of
each null indicator field. The column number is the byte offset of the null
indicator field from the beginning of a row of data. There must be one
entry in the null indicator list for each data field defined in the METHOD
L parameter. A column number of zero indicates that the corresponding
data field always contains data.
A value of Y in the NULL indicator column specifies that the column data
is NULL. Any character other than Y in the NULL indicator column
specifies that the column data is not NULL, and that column data specified
by the METHOD L option will be imported.
The NULL indicator character can be changed using the MODIFIED BY
option, with the nullindchar file type modifier.
OF filetype
Specifies the format of the data in the input file:
v ASC (non-delimited ASCII format)
v DEL (delimited ASCII format), which is used by a variety of database
manager and file manager programs
v WSF (work sheet format), which is used by programs such as:
– Lotus 1-2-3
– Lotus Symphony
v IXF (Integration Exchange Format, PC version) is a binary format that is
used exclusively by DB2.
The WSF file type is not supported when you import to a nickname.
REPLACE
Deletes all existing data from the table by truncating the data object, and
inserts the imported data. The table definition and the index definitions are
not changed. This option can only be used if the table exists. If this option
is used when moving data between hierarchies, only the data for an entire
hierarchy, not individual subtables, can be replaced.
This parameter is not valid when you import to a nickname.
This option does not honor the CREATE TABLE statement's NOT
LOGGED INITIALLY (NLI) clause or the ALTER TABLE statement's
ACTIVE NOT LOGGED INITIALLY clause.
If an import with the REPLACE option is performed within the same
transaction as a CREATE TABLE or ALTER TABLE statement where the
NLI clause is invoked, the import will not honor the NLI clause. All inserts
will be logged.
Workaround 1
Delete the contents of the table using the DELETE statement, then
invoke the import with INSERT statement
Workaround 2
Drop the table and recreate it, then invoke the import with INSERT
statement.
This limitation applies to DB2 Universal Database™ Version 7 and DB2
UDB Version 8

Chapter 3. Import utility 73

 REPLACE_CREATE

Note: The REPLACE_CREATE parameter is deprecated and may be

removed in a future release. For additional details, see “IMPORT command
options CREATE and REPLACE_CREATE are deprecated”.
If the table exists, deletes all existing data from the table by truncating the
data object, and inserts the imported data without changing the table
definition or the index definitions.
If the table does not exist, creates the table and index definitions, as well as
the row contents, in the code page of the database. See Imported table
re-creation for a list of restrictions.
This option can only be used with IXF files. If this option is used when
moving data between hierarchies, only the data for an entire hierarchy, not
individual subtables, can be replaced.
This parameter is not valid when you import to a nickname.
RESTARTCOUNT n
Specifies that an import operation is to be started at record n+1. The first n
records are skipped. This option is functionally equivalent to
SKIPCOUNT. RESTARTCOUNT and SKIPCOUNT are mutually
exclusive.
ROWCOUNT n
Specifies the number n of physical records in the file to be imported
(inserted or updated). Allows a user to import only n rows from a file,
starting from the record determined by the SKIPCOUNT or
RESTARTCOUNT options. If the SKIPCOUNT or RESTARTCOUNT
options are not specified, the first n rows are imported. If SKIPCOUNT m
or RESTARTCOUNT m is specified, rows m+1 to m+n are imported. When
compound inserts are used, user specified ROWCOUNT n is rounded up
to the first integer multiple of the compound count value.
SKIPCOUNT n
Specifies that an import operation is to be started at record n+1. The first n
records are skipped. This option is functionally equivalent to
RESTARTCOUNT. SKIPCOUNT and RESTARTCOUNT are mutually
exclusive.
STARTING sub-table-name
A keyword for hierarchy only, requesting the default order, starting from
sub-table-name. For PC/IXF files, the default order is the order stored in the
input file. The default order is the only valid order for the PC/IXF file
format.
sub-table-list
For typed tables with the INSERT or the INSERT_UPDATE option, a list
of sub-table names is used to indicate the sub-tables into which data is to
be imported.
traversal-order-list
For typed tables with the INSERT, INSERT_UPDATE, or the REPLACE
option, a list of sub-table names is used to indicate the traversal order of
the importing sub-tables in the hierarchy.
UNDER sub-table-name
Specifies a parent table for creating one or more sub-tables.

74 Data Movement Utilities Guide and Reference

WARNINGCOUNT n
Stops the import operation after n warnings. Set this parameter if no
warnings are expected, but verification that the correct file and table are
being used is desired. If the import file or the target table is specified
incorrectly, the import utility will generate a warning for each row that it
attempts to import, which will cause the import to fail. If n is zero, or this
option is not specified, the import operation will continue regardless of the
number of warnings issued.
XML FROM xml-path
Specifies one or more paths that contain the XML files.
XMLPARSE
Specifies how XML documents are parsed. If this option is not specified,
the parsing behavior for XML documents will be determined by the value
of the CURRENT XMLPARSE OPTION special register.
STRIP WHITESPACE
Specifies to remove whitespace when the XML document is parsed.
PRESERVE WHITESPACE
Specifies not to remove whitespace when the XML document is
parsed.
XMLVALIDATE
Specifies that XML documents are validated against a schema, when
applicable.
USING XDS
XML documents are validated against the XML schema identified
by the XML Data Specifier (XDS) in the main data file. By default,
if the XMLVALIDATE option is invoked with the USING XDS
clause, the schema used to perform validation will be determined
by the SCH attribute of the XDS. If an SCH attribute is not present
in the XDS, no schema validation will occur unless a default
schema is specified by the DEFAULT clause.
The DEFAULT, IGNORE, and MAP clauses can be used to modify
the schema determination behavior. These three optional clauses
apply directly to the specifications of the XDS, and not to each
other. For example, if a schema is selected because it is specified by
the DEFAULT clause, it will not be ignored if also specified by the
IGNORE clause. Similarly, if a schema is selected because it is
specified as the first part of a pair in the MAP clause, it will not be
re-mapped if also specified in the second part of another MAP
clause pair.
USING SCHEMA schema-sqlid
XML documents are validated against the XML schema with the
specified SQL identifier. In this case, the SCH attribute of the XML
Data Specifier (XDS) will be ignored for all XML columns.
USING SCHEMALOCATION HINTS
XML documents are validated against the schemas identified by
XML schema location hints in the source XML documents. If a
schemaLocation attribute is not found in the XML document, no
validation will occur. When the USING SCHEMALOCATION
HINTS clause is specified, the SCH attribute of the XML Data
Specifier (XDS) will be ignored for all XML columns.

Chapter 3. Import utility 75

 See examples of the XMLVALIDATE option below.

Usage notes

Be sure to complete all table operations and release all locks before starting an
import operation. This can be done by issuing a COMMIT after closing all cursors
opened WITH HOLD, or by issuing a ROLLBACK.

The import utility adds rows to the target table using the SQL INSERT statement.
The utility issues one INSERT statement for each row of data in the input file. If an
INSERT statement fails, one of two actions result:
v If it is likely that subsequent INSERT statements can be successful, a warning
message is written to the message file, and processing continues.
v If it is likely that subsequent INSERT statements will fail, and there is potential
for database damage, an error message is written to the message file, and
processing halts.

The utility performs an automatic COMMIT after the old rows are deleted during a
REPLACE or a REPLACE_CREATE operation. Therefore, if the system fails, or the
application interrupts the database manager after the table object is truncated, all
of the old data is lost. Ensure that the old data is no longer needed before using
these options.

If the log becomes full during a CREATE, REPLACE, or REPLACE_CREATE

operation, the utility performs an automatic COMMIT on inserted records. If the
system fails, or the application interrupts the database manager after an automatic
COMMIT, a table with partial data remains in the database. Use the REPLACE or
the REPLACE_CREATE option to rerun the whole import operation, or use
INSERT with the RESTARTCOUNT parameter set to the number of rows
successfully imported.

Updates from the IMPORT command will always be committed at the end of an
IMPORT task. The IMPORT command can also perform automatic commits during
its execution to reduce the size of the lock list and the active log space. The
IMPORT command will rollback if the active log becomes full during IMPORT
processing.
v By default, automatic commits are not performed for the INSERT or the
INSERT_UPDATE option. They are, however, performed if the
COMMITCOUNT parameter is not zero.
v Offline import does not perform automatic COMMITs if any of the following
conditions are true:
– The target is a view, not a table
– Compound inserts are used
– Buffered inserts are used
v By default, online import performs automatic commit to free both the active log
space and the lock list. Automatic commits are not performed only if a
COMMITCOUNT value of zero is specified.

Whenever the import utility performs a COMMIT, two messages are written to the
message file: one indicates the number of records to be committed, and the other is
written after a successful COMMIT. When restarting the import operation after a
failure, specify the number of records to skip, as determined from the last
successful COMMIT.

76 Data Movement Utilities Guide and Reference

The import utility accepts input data with minor incompatibility problems (for
example, character data can be imported using padding or truncation, and numeric
data can be imported with a different numeric data type), but data with major
incompatibility problems is not accepted.

You cannot REPLACE or REPLACE_CREATE an object table if it has any

dependents other than itself, or an object view if its base table has any dependents
(including itself). To replace such a table or a view, do the following:
1. Drop all foreign keys in which the table is a parent.
2. Run the import utility.
3. Alter the table to recreate the foreign keys.

If an error occurs while recreating the foreign keys, modify the data to maintain
referential integrity.

Referential constraints and foreign key definitions are not preserved when
recreating tables from PC/IXF files. (Primary key definitions are preserved if the
data was previously exported using SELECT *.)

Importing to a remote database requires enough disk space on the server for a
copy of the input data file, the output message file, and potential growth in the
size of the database.

If an import operation is run against a remote database, and the output message
file is very long (more than 60 KB), the message file returned to the user on the
client might be missing messages from the middle of the import operation. The
first 30 KB of message information and the last 30 KB of message information are
always retained.

Importing PC/IXF files to a remote database is much faster if the PC/IXF file is on
a hard drive rather than on diskettes.

The database table or hierarchy must exist before data in the ASC, DEL, or WSF
file formats can be imported; however, if the table does not already exist, IMPORT
CREATE or IMPORT REPLACE_CREATE creates the table when it imports data
from a PC/IXF file. For typed tables, IMPORT CREATE can create the type
hierarchy and the table hierarchy as well.

PC/IXF import should be used to move data (including hierarchical data) between
databases. If character data containing row separators is exported to a delimited
ASCII (DEL) file and processed by a text transfer program, fields containing the
row separators will shrink or expand. The file copying step is not necessary if the
source and the target databases are both accessible from the same client.

The data in ASC and DEL files is assumed to be in the code page of the client
application performing the import. PC/IXF files, which allow for different code
pages, are recommended when importing data in different code pages. If the
PC/IXF file and the import utility are in the same code page, processing occurs as
for a regular application. If the two differ, and the FORCEIN option is specified,
the import utility assumes that data in the PC/IXF file has the same code page as
the application performing the import. This occurs even if there is a conversion
table for the two code pages. If the two differ, the FORCEIN option is not
specified, and there is a conversion table, all data in the PC/IXF file will be
converted from the file code page to the application code page. If the two differ,

Chapter 3. Import utility 77

 the FORCEIN option is not specified, and there is no conversion table, the import
operation will fail. This applies only to PC/IXF files on DB2 clients on the AIX
operating system.

For table objects on an 8 KB page that are close to the limit of 1012 columns,
import of PC/IXF data files might cause DB2 to return an error, because the
maximum size of an SQL statement was exceeded. This situation can occur only if
the columns are of type CHAR, VARCHAR, or CLOB. The restriction does not
apply to import of DEL or ASC files. If PC/IXF files are being used to create a
new table, an alternative is use db2look to dump the DDL statement that created
the table, and then to issue that statement through the CLP.

DB2 Connect can be used to import data to DRDA servers such as DB2 for
OS/390, DB2 for VM and VSE, and DB2 for OS/400. Only PC/IXF import
(INSERT option) is supported. The RESTARTCOUNT parameter, but not the
COMMITCOUNT parameter, is also supported.

When using the CREATE option with typed tables, create every sub-table defined
in the PC/IXF file; sub-table definitions cannot be altered. When using options
other than CREATE with typed tables, the traversal order list enables one to
specify the traverse order; therefore, the traversal order list must match the one
used during the export operation. For the PC/IXF file format, one need only
specify the target sub-table name, and use the traverse order stored in the file.

The import utility can be used to recover a table previously exported to a PC/IXF
file. The table returns to the state it was in when exported.

Data cannot be imported to a system table, a declared temporary table, or a

summary table.

Views cannot be created through the import utility.

Importing a multiple-part PC/IXF file whose individual parts are copied from a
Windows system to an AIX system is supported. Only the name of the first file
must be specified in the IMPORT command. For example, IMPORT FROM data.ixf
OF IXF INSERT INTO TABLE1. The file data.002, etc should be available in the same
directory as data.ixf.

On the Windows operating system:

v Importing logically split PC/IXF files is not supported.
v Importing bad format PC/IXF or WSF files is not supported.

Security labels in their internal format might contain newline characters. If you
import the file using the DEL file format, those newline characters can be mistaken
for delimiters. If you have this problem use the older default priority for delimiters
by specifying the delprioritychar file type modifier in the IMPORT command.

Federated considerations

When using the IMPORT command and the INSERT, UPDATE, or

INSERT_UPDATE command parameters, you must ensure that you have
CONTROL privilege on the participating nickname. You must ensure that the
nickname you want to use when doing an import operation already exists. There
are also several restrictions you should be aware of as shown in the IMPORT
command parameters section.

78 Data Movement Utilities Guide and Reference

 Some data sources, such as ODBC, do not support importing into nicknames.

File type modifiers for the import utility

Table 14. Valid file type modifiers for the import utility: All file formats
Modifier Description
compound=x x is a number between 1 and 100 inclusive. Uses nonatomic compound SQL to
insert the data, and x statements will be attempted each time.

If this modifier is specified, and the transaction log is not sufficiently large, the
import operation will fail. The transaction log must be large enough to
accommodate either the number of rows specified by COMMITCOUNT, or the
number of rows in the data file if COMMITCOUNT is not specified. It is
therefore recommended that the COMMITCOUNT option be specified to avoid
transaction log overflow.

This modifier is incompatible with INSERT_UPDATE mode, hierarchical tables,

and the following modifiers: usedefaults, identitymissing, identityignore,
generatedmissing, and generatedignore.
generatedignore This modifier informs the import utility that data for all generated columns is
present in the data file but should be ignored. This results in all values for the
generated columns being generated by the utility. This modifier cannot be used
with the generatedmissing modifier.
generatedmissing If this modifier is specified, the utility assumes that the input data file contains no
data for the generated columns (not even NULLs), and will therefore generate a
value for each row. This modifier cannot be used with the generatedignore
modifier.
identityignore This modifier informs the import utility that data for the identity column is
present in the data file but should be ignored. This results in all identity values
being generated by the utility. The behavior will be the same for both
GENERATED ALWAYS and GENERATED BY DEFAULT identity columns. This
means that for GENERATED ALWAYS columns, no rows will be rejected. This
modifier cannot be used with the identitymissing modifier.
identitymissing If this modifier is specified, the utility assumes that the input data file contains no
data for the identity column (not even NULLs), and will therefore generate a
value for each row. The behavior will be the same for both GENERATED
ALWAYS and GENERATED BY DEFAULT identity columns. This modifier cannot
be used with the identityignore modifier.
lobsinfile lob-path specifies the path to the files containing LOB data.

Each path contains at least one file that contains at least one LOB pointed to by a
Lob Location Specifier (LLS) in the data file. The LLS is a string representation of
the location of a LOB in a file stored in the LOB file path. The format of an LLS is
filename.ext.nnn.mmm/, where filename.ext is the name of the file that contains
the LOB, nnn is the offset in bytes of the LOB within the file, and mmm is the
length of the LOB in bytes. For example, if the string db2exp.001.123.456/ is
stored in the data file, the LOB is located at offset 123 in the file db2exp.001, and
is 456 bytes long.

The LOBS FROM clause specifies where the LOB files are located when the
“lobsinfile” modifier is used. The LOBS FROM clause will implicitly activate the
LOBSINFILE behavior. The LOBS FROM clause conveys to the IMPORT utility
the list of paths to search for the LOB files while importing the data.

To indicate a null LOB, enter the size as -1. If the size is specified as 0, it is
treated as a 0 length LOB. For null LOBS with length of -1, the offset and the file
name are ignored. For example, the LLS of a null LOB might be db2exp.001.7.-1/.

Chapter 3. Import utility 79

Table 14. Valid file type modifiers for the import utility: All file formats (continued)
Modifier Description
no_type_id Valid only when importing into a single sub-table. Typical usage is to export data
from a regular table, and then to invoke an import operation (using this modifier)
to convert the data into a single sub-table.
nodefaults If a source column for a target table column is not explicitly specified, and the
table column is not nullable, default values are not loaded. Without this option, if
a source column for one of the target table columns is not explicitly specified, one
of the following occurs:
v If a default value can be specified for a column, the default value is loaded
v If the column is nullable, and a default value cannot be specified for that
column, a NULL is loaded
v If the column is not nullable, and a default value cannot be specified, an error
is returned, and the utility stops processing.
norowwarnings Suppresses all warnings about rejected rows.
rowchangetimestampignore This modifier informs the import utility that data for the row change timestamp
column is present in the data file but should be ignored. This results in all ROW
CHANGE TIMESTAMP being generated by the utility. The behavior will be the
same for both GENERATED ALWAYS and GENERATED BY DEFAULT columns.
This means that for GENERATED ALWAYS columns, no rows will be rejected.
This modifier cannot be used with the rowchangetimestampmissing modifier.
rowchangetimestampmissing If this modifier is specified, the utility assumes that the input data file contains no
data for the row change timestamp column (not even NULLs), and will therefore
generate a value for each row. The behavior will be the same for both
GENERATED ALWAYS and GENERATED BY DEFAULT columns. This modifier
cannot be used with the rowchangetimestampignore modifier.
seclabelchar Indicates that security labels in the input source file are in the string format for
security label values rather than in the default encoded numeric format. IMPORT
converts each security label into the internal format as it is loaded. If a string is
not in the proper format the row is not loaded and a warning (SQLSTATE 01H53)
is returned. If the string does not represent a valid security label that is part of
the security policy protecting the table then the row is not loaded and a warning
(SQLSTATE 01H53, SQLCODE SQL3243W)) is returned.

This modifier cannot be specified if the seclabelname modifier is specified,

otherwise the import fails and an error (SQLCODE SQL3525N) is returned.
seclabelname Indicates that security labels in the input source file are indicated by their name
rather than the default encoded numeric format. IMPORT will convert the name
to the appropriate security label if it exists. If no security label exists with the
indicated name for the security policy protecting the table the row is not loaded
and a warning (SQLSTATE 01H53, SQLCODE SQL3244W) is returned.

This modifier cannot be specified if the seclabelchar modifier is specified,

otherwise the import fails and an error (SQLCODE SQL3525N) is returned.
Note: If the file type is ASC, any spaces following the name of the security label
will be interpreted as being part of the name. To avoid this use the striptblanks
file type modifier to make sure the spaces are removed.

80 Data Movement Utilities Guide and Reference

Table 14. Valid file type modifiers for the import utility: All file formats (continued)
Modifier Description
usedefaults If a source column for a target table column has been specified, but it contains no
data for one or more row instances, default values are loaded. Examples of
missing data are:
v For DEL files: two adjacent column delimiters (",,") or two adjacent column
delimiters separated by an arbitrary number of spaces (", ,") are specified for a
column value.
v For DEL/ASC/WSF files: A row that does not have enough columns, or is not
long enough for the original specification.
Note: For ASC files, NULL column values are not considered explicitly
missing, and a default will not be substituted for NULL column values. NULL
column values are represented by all space characters for numeric, date, time,
and /timestamp columns, or by using the NULL INDICATOR for a column of
any type to indicate the column is NULL.
Without this option, if a source column contains no data for a row instance, one
of the following occurs:
v For DEL/ASC/WSF files: If the column is nullable, a NULL is loaded. If the
column is not nullable, the utility rejects the row.

Table 15. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL)
Modifier Description
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the input data set. Converts character data from this code page to the
application code page during the import operation.

The following rules apply:

v For pure DBCS (graphic) mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive.
v nullindchar must specify symbols included in the standard ASCII set between
code points x20 and x7F, inclusive. This refers to ASCII symbols and code
points.
Note:
1. The codepage modifier cannot be used with the lobsinfile modifier.
2. If data expansion occurs when the code page is converted from the
application code page to the database code page, the data might be truncated
and loss of data can occur.
dateformat="x" x is the format of the date in the source file.2 Valid date elements are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 1 - 12;
mutually exclusive with M)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31;
mutually exclusive with D)
DDD - Day of the year (three digits ranging
from 001 - 366; mutually exclusive
with other day or month elements)

A default value of 1 is assigned for each element that is not specified. Some
examples of date formats are:
"D-M-YYYY"
"MM.DD.YYYY"
"YYYYDDD"

Chapter 3. Import utility 81

Table 15. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
implieddecimal The location of an implied decimal point is determined by the column definition;
it is no longer assumed to be at the end of the value. For example, the value
12345 is loaded into a DECIMAL(8,2) column as 123.45, not 12345.00.
timeformat="x" x is the format of the time in the source file.2 Valid time elements are:
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24
for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24
for a 24 hour system; mutually exclusive
with H)
M - Minute (one or two digits ranging
from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M)
S - Second (one or two digits ranging
from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
TT - Meridian indicator (AM or PM)

A default value of 0 is assigned for each element that is not specified. Some
examples of time formats are:
"HH:MM:SS"
"HH.MM TT"
"SSSSS"

82 Data Movement Utilities Guide and Reference

Table 15. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
timestampformat="x" x is the format of the time stamp in the source file.2 Valid time stamp elements
are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 01 - 12;
mutually exclusive with M and MMM)
MMM - Month (three-letter case-insensitive abbreviation for
the month name; mutually exclusive with M and MM)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31; mutually exclusive with D)
DDD - Day of the year (three digits ranging from 001 - 366;
mutually exclusive with other day or month elements)
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system;
mutually exclusive with H)
M - Minute (one or two digits ranging from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M, minute)
S - Second (one or two digits ranging from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
UUUUUU - Microsecond (6 digits ranging from 000000 - 999999;
mutually exclusive with all other microsecond elements)
UUUUU - Microsecond (5 digits ranging from 00000 - 99999,
maps to range from 000000 - 999990;
mutually exclusive with all other microseond elements)
UUUU - Microsecond (4 digits ranging from 0000 - 9999,
maps to range from 000000 - 999900;
mutually exclusive with all other microseond elements)
UUU - Microsecond (3 digits ranging from 000 - 999,
maps to range from 000000 - 999000;
mutually exclusive with all other microseond elements)
UU - Microsecond (2 digits ranging from 00 - 99,
maps to range from 000000 - 990000;
mutually exclusive with all other microseond elements)
U - Microsecond (1 digit ranging from 0 - 9,
maps to range from 000000 - 900000;
mutually exclusive with all other microseond elements)
TT - Meridian indicator (AM or PM)

A default value of 1 is assigned for unspecified YYYY, M, MM, D, DD, or DDD

elements. A default value of 'Jan' is assigned to an unspecified MMM element. A
default value of 0 is assigned for all other unspecified elements. Following is an
example of a time stamp format:
"YYYY/MM/DD HH:MM:SS.UUUUUU"

The valid values for the MMM element include: 'jan', 'feb', 'mar', 'apr', 'may', 'jun',
'jul', 'aug', 'sep', 'oct', 'nov' and 'dec'. These values are case insensitive.

The following example illustrates how to import data containing user defined
date and time formats into a table called schedule:
db2 import from delfile2 of del
modified by timestampformat="yyyy.mm.dd hh:mm tt"
insert into schedule

Chapter 3. Import utility 83

Table 15. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
usegraphiccodepage If usegraphiccodepage is given, the assumption is made that data being imported
into graphic or double-byte character large object (DBCLOB) data fields is in the
graphic code page. The rest of the data is assumed to be in the character code
page. The graphic code page is associated with the character code page. IMPORT
determines the character code page through either the codepage modifier, if it is
specified, or through the code page of the application if the codepage modifier is
not specified.

This modifier should be used in conjunction with the delimited data file
generated by drop table recovery only if the table being recovered has graphic
data.

Restrictions

The usegraphiccodepage modifier MUST NOT be specified with DEL files created
by the EXPORT utility, as these files contain data encoded in only one code page.
The usegraphiccodepage modifier is also ignored by the double-byte character
large objects (DBCLOBs) in files.
xmlchar Specifies that XML documents are encoded in the character code page.

This option is useful for processing XML documents that are encoded in the
specified character code page but do not contain an encoding declaration.

For each document, if a declaration tag exists and contains an encoding attribute,
the encoding must match the character code page, otherwise the row containing
the document will be rejected. Note that the character codepage is the value
specified by the codepage file type modifier, or the application codepage if it is
not specified. By default, either the documents are encoded in Unicode, or they
contain a declaration tag with an encoding attribute.
xmlgraphic Specifies that XML documents are encoded in the specified graphic code page.

This option is useful for processing XML documents that are encoded in a specific
graphic code page but do not contain an encoding declaration.

For each document, if a declaration tag exists and contains an encoding attribute,
the encoding must match the graphic code page, otherwise the row containing
the document will be rejected. Note that the graphic code page is the graphic
component of the value specified by the codepage file type modifier, or the
graphic component of the application code page if it is not specified. By default,
documents are either encoded in Unicode, or they contain a declaration tag with
an encoding attribute.
Note: If the xmlgraphic modifier is specified with the IMPORT command, the
XML document to be imported must be encoded in the UTF-16 code page.
Otherwise, the XML document may be rejected with a parsing error, or it may be
imported into the table with data corruption.

Table 16. Valid file type modifiers for the import utility: ASC (non-delimited ASCII) file format
Modifier Description
nochecklengths If nochecklengths is specified, an attempt is made to import each row, even if the
source data has a column definition that exceeds the size of the target table
column. Such rows can be successfully imported if code page conversion causes
the source data to shrink; for example, 4-byte EUC data in the source could
shrink to 2-byte DBCS data in the target, and require half the space. This option
is particularly useful if it is known that the source data will fit in all cases despite
mismatched column definitions.

84 Data Movement Utilities Guide and Reference

Table 16. Valid file type modifiers for the import utility: ASC (non-delimited ASCII) file format (continued)
Modifier Description
nullindchar=x x is a single character. Changes the character denoting a null value to x. The
default value of x is Y.3

This modifier is case sensitive for EBCDIC data files, except when the character is
an English letter. For example, if the null indicator character is specified to be the
letter N, then n is also recognized as a null indicator.
reclen=x x is an integer with a maximum value of 32 767. x characters are read for each
row, and a new-line character is not used to indicate the end of the row.
striptblanks Truncates any trailing blank spaces when loading data into a variable-length field.
If this option is not specified, blank spaces are kept.

In the following example, striptblanks causes the import utility to truncate

trailing blank spaces:
db2 import from myfile.asc of asc
modified by striptblanks
method l (1 10, 12 15) messages msgs.txt
insert into staff

This option cannot be specified together with striptnulls. These are mutually
exclusive options. This option replaces the obsolete t option, which is supported
for earlier compatibility only.
striptnulls Truncates any trailing NULLs (0x00 characters) when loading data into a
variable-length field. If this option is not specified, NULLs are kept.

This option cannot be specified together with striptblanks. These are mutually
exclusive options. This option replaces the obsolete padwithzero option, which is
supported for earlier compatibility only.

Table 17. Valid file type modifiers for the import utility: DEL (delimited ASCII) file format
Modifier Description
chardelx x is a single character string delimiter. The default value is a double quotation
mark ("). The specified character is used in place of double quotation marks to
enclose a character string.34 If you want to explicitly specify the double quotation
mark as the character string delimiter, it should be specified as follows:
modified by chardel""

The single quotation mark (') can also be specified as a character string delimiter.
In the following example, chardel’’ causes the import utility to interpret any
single quotation mark (') it encounters as a character string delimiter:
db2 "import from myfile.del of del
modified by chardel’’
method p (1, 4) insert into staff (id, years)"
coldelx x is a single character column delimiter. The default value is a comma (,). The
specified character is used in place of a comma to signal the end of a column.34

In the following example, coldel; causes the import utility to interpret any
semicolon (;) it encounters as a column delimiter:
db2 import from myfile.del of del
modified by coldel;
messages msgs.txt insert into staff
decplusblank Plus sign character. Causes positive decimal values to be prefixed with a blank
space instead of a plus sign (+). The default action is to prefix positive decimal
values with a plus sign.

Chapter 3. Import utility 85

Table 17. Valid file type modifiers for the import utility: DEL (delimited ASCII) file format (continued)
Modifier Description
decptx x is a single character substitute for the period as a decimal point character. The
default value is a period (.). The specified character is used in place of a period as
a decimal point character.34

In the following example, decpt; causes the import utility to interpret any
semicolon (;) it encounters as a decimal point:
db2 "import from myfile.del of del
modified by chardel’’
decpt; messages msgs.txt insert into staff"
delprioritychar The current default priority for delimiters is: record delimiter, character delimiter,
column delimiter. This modifier protects existing applications that depend on the
older priority by reverting the delimiter priorities to: character delimiter, record
delimiter, column delimiter. Syntax:
db2 import ... modified by delprioritychar ...

For example, given the following DEL data file:

"Smith, Joshua",4000,34.98<row delimiter>
"Vincent,<row delimiter>, is a manager", ...
... 4005,44.37<row delimiter>

With the delprioritychar modifier specified, there will be only two rows in this
data file. The second <row delimiter> will be interpreted as part of the first data
column of the second row, while the first and the third <row delimiter> are
interpreted as actual record delimiters. If this modifier is not specified, there will
be three rows in this data file, each delimited by a <row delimiter>.
keepblanks Preserves the leading and trailing blanks in each field of type CHAR, VARCHAR,
LONG VARCHAR, or CLOB. Without this option, all leading and trailing blanks
that are not inside character delimiters are removed, and a NULL is inserted into
the table for all blank fields.
nochardel The import utility will assume all bytes found between the column delimiters to
be part of the column's data. Character delimiters will be parsed as part of
column data. This option should not be specified if the data was exported using
DB2 (unless nochardel was specified at export time). It is provided to support
vendor data files that do not have character delimiters. Improper usage might
result in data loss or corruption.

This option cannot be specified with chardelx, delprioritychar or nodoubledel.

These are mutually exclusive options.
nodoubledel Suppresses recognition of double character delimiters.

Table 18. Valid file type modifiers for the import utility: IXF file format
Modifier Description
forcein Directs the utility to accept data despite code page mismatches, and to suppress
translation between code pages.

Fixed length target fields are checked to verify that they are large enough for the
data. If nochecklengths is specified, no checking is done, and an attempt is made
to import each row.
indexixf Directs the utility to drop all indexes currently defined on the existing table, and
to create new ones from the index definitions in the PC/IXF file. This option can
only be used when the contents of a table are being replaced. It cannot be used
with a view, or when a insert-column is specified.

86 Data Movement Utilities Guide and Reference

Table 18. Valid file type modifiers for the import utility: IXF file format (continued)
Modifier Description
indexschema=schema Uses the specified schema for the index name during index creation. If schema is
not specified (but the keyword indexschema is specified), uses the connection user
ID. If the keyword is not specified, uses the schema in the IXF file.
nochecklengths If nochecklengths is specified, an attempt is made to import each row, even if the
source data has a column definition that exceeds the size of the target table
column. Such rows can be successfully imported if code page conversion causes
the source data to shrink; for example, 4-byte EUC data in the source could
shrink to 2-byte DBCS data in the target, and require half the space. This option
is particularly useful if it is known that the source data will fit in all cases despite
mismatched column definitions.
forcecreate Specifies that the table should be created with possible missing or limited
information after returning SQL3311N during an import operation.

Table 19. IMPORT behavior when using codepage and usegraphiccodepage

codepage=N usegraphiccodepage IMPORT behavior
Absent Absent All data in the file is assumed to be in the application
code page.
Present Absent All data in the file is assumed to be in code page N.

Warning: Graphic data will be corrupted when

imported into the database if N is a single-byte code
page.
Absent Present Character data in the file is assumed to be in the
application code page. Graphic data is assumed to be in
the code page of the application graphic data.

If the application code page is single-byte, then all data

is assumed to be in the application code page.

Warning: If the application code page is single-byte,

graphic data will be corrupted when imported into the
database, even if the database contains graphic columns.
Present Present Character data is assumed to be in code page N. Graphic
data is assumed to be in the graphic code page of N.

If N is a single-byte or double-byte code page, then all

data is assumed to be in code page N.

Warning: Graphic data will be corrupted when

imported into the database if N is a single-byte code
page.

Note:
1. The import utility does not issue a warning if an attempt is made to use
unsupported file types with the MODIFIED BY option. If this is attempted,
the import operation fails, and an error code is returned.
2. Double quotation marks around the date format string are mandatory. Field
separators cannot contain any of the following: a-z, A-Z, and 0-9. The field
separator should not be the same as the character delimiter or field delimiter
in the DEL file format. A field separator is optional if the start and end

Chapter 3. Import utility 87

 positions of an element are unambiguous. Ambiguity can exist if (depending
on the modifier) elements such as D, H, M, or S are used, because of the
variable length of the entries.
For time stamp formats, care must be taken to avoid ambiguity between the
month and the minute descriptors, since they both use the letter M. A month
field must be adjacent to other date fields. A minute field must be adjacent to
other time fields. Following are some ambiguous time stamp formats:
"M" (could be a month, or a minute)
"M:M" (Which is which?)
"M:YYYY:M" (Both are interpreted as month.)
"S:M:YYYY" (adjacent to both a time value and a date value)

In ambiguous cases, the utility will report an error message, and the operation
will fail.
Following are some unambiguous time stamp formats:
"M:YYYY" (Month)
"S:M" (Minute)
"M:YYYY:S:M" (Month....Minute)
"M:H:YYYY:M:D" (Minute....Month)
Some characters, such as double quotation marks and back slashes, must be
preceded by an escape character (for example, \).
3. Character values provided for the chardel, coldel, or decpt file type modifiers
must be specified in the code page of the source data.
The character code point (instead of the character symbol), can be specified
using the syntax xJJ or 0xJJ, where JJ is the hexadecimal representation of the
code point. For example, to specify the # character as a column delimiter, use
one of the following:
... modified by coldel# ...
... modified by coldel0x23 ...
... modified by coldelX23 ...
4. Delimiter considerations for moving data lists restrictions that apply to the
characters that can be used as delimiter overrides.
5. The following file type modifiers are not allowed when importing into a
nickname:
v indexixf
v indexschema
v dldelfiletype
v nodefaults
v usedefaults
v no_type_idfiletype
v generatedignore
v generatedmissing
v identityignore
v identitymissing
v lobsinfile
6. The WSF file format is not supported for XML columns.
7. The CREATE mode is not supported for XML columns.
8. All XML data must reside in XML files that are separate from the main data
file. An XML Data Specifier (XDS) (or a NULL value) must exist for each XML
column in the main data file.

88 Data Movement Utilities Guide and Reference

 9. XML documents are assumed to be in Unicode format or to contain a
declaration tag that includes an encoding attribute, unless the XMLCHAR or
XMLGRAPHIC file type modifier is specified.
10. Rows containing documents that are not well-formed will be rejected.
11. If the XMLVALIDATE option is specified, documents that successfully
validate against their matching schema will be annotated with the schema
information as they are inserted. Rows containing documents that fail to
validate against their matching schema will be rejected. To successfully
perform the validation, the privileges held by the user invoking the import
must include at least one of the following:
v SYSADM or DBADM authority
v USAGE privilege on the XML schema to be used in the validation
12. When importing into a table containing an implicitly hidden row change
timestamp column, the implicitly hidden property of the column is not
honoured. Therefore, the rowchangetimestampmissing file type modifier must
be specified in the import command if data for the column is not present in
the data to be imported and there is no explicit column list present.

IMPORT command using the ADMIN_CMD procedure

Inserts data from an external file with a supported file format into a table,
hierarchy, view or nickname. LOAD is a faster alternative, but the load utility does
not support loading data at the hierarchy level.

Quick link to “File type modifiers for the import utility” on page 103.

Authorization
v IMPORT using the INSERT option requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on each participating table, view, or nickname
– INSERT and SELECT privilege on each participating table or view
v IMPORT to an existing table using the INSERT_UPDATE option, requires one of
the following:
– sysadm
– dbadm
– CONTROL privilege on each participating table, view, or nickname
– INSERT, SELECT, UPDATE and DELETE privilege on each participating table
or view
v IMPORT to an existing table using the REPLACE or REPLACE_CREATE option,
requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on the table or view
– INSERT, SELECT, and DELETE privilege on the table or view
v IMPORT to a new table using the CREATE or REPLACE_CREATE option,
requires one of the following:
– sysadm
– dbadm

Chapter 3. Import utility 89

 – CREATETAB authority on the database and USE privilege on the table space,
as well as one of:
- IMPLICIT_SCHEMA authority on the database, if the implicit or explicit
schema name of the table does not exist
- CREATEIN privilege on the schema, if the schema name of the table refers
to an existing schema
v IMPORT to a hierarchy that does not exist using the CREATE, or the
REPLACE_CREATE option, requires one of the following:
– sysadm
– dbadm
– CREATETAB authority on the database and USE privilege on the table space
and one of:
- IMPLICIT_SCHEMA authority on the database, if the schema name of the
table does not exist
- CREATEIN privilege on the schema, if the schema of the table exists
- CONTROL privilege on every sub-table in the hierarchy, if the
REPLACE_CREATE option on the entire hierarchy is used
v IMPORT to an existing hierarchy using the REPLACE option requires one of the
following:
– sysadm
– dbadm
– CONTROL privilege on every sub-table in the hierarchy
v To import data into a table that has protected columns, the session authorization
ID must have LBAC credentials that allow write access to all protected columns
in the table. Otherwise the import fails and an error (SQLSTATE 42512) is
returned.
v To import data into a table that has protected rows, the session authorization ID
must hold LBAC credentials that meet these criteria:
– It is part of the security policy protecting the table
– It was granted to the session authorization ID for write access
The label on the row to insert, the user's LBAC credentials, the security policy
definition, and the LBAC rules determine the label on the row.
v If the REPLACE or REPLACE_CREATE option is specified, the session
authorization ID must have the authority to drop the table.
v To import data into a nickname, the session authorization ID must have the
privilege to access and use a specified data source in pass-through mode.

Required connection
Command syntax


IMPORT FROM filename OF filetype

,

LOBS FROM  lob-path

90 Data Movement Utilities Guide and Reference




,

XML FROM  xml-path MODIFIED BY  filetype-mod

METHOD L-method_specs
,

N (  column-name )
,

P (  column-position )

XMLPARSE STRIP WHITESPACE
PRESERVE

ALLOW NO ACCESS



XMLVALIDATE USING XDS-specs ALLOW WRITE ACCESS
SCHEMA schema-sqlid
SCHEMALOCATION HINTS

COMMITCOUNT n RESTARTCOUNT n ROWCOUNT n
AUTOMATIC SKIPCOUNT

WARNINGCOUNT n NOTIMEOUT

INSERT INTO insert-table-specs


INSERT_UPDATE
REPLACE
REPLACE_CREATE
CREATE INTO create-table-specs tblspace-specs

create-table-specs:

table-name
,

(  insert-column )
hierarchy description AS ROOT TABLE
UNDER sub-table-name

Chapter 3. Import utility 91

 insert-table-specs:

table-name
,

(  insert-column )
hierarchy description

hierarchy description:

ALL TABLES
sub-table-list HIERARCHY STARTING sub-table-name
IN traversal-order-list

L-method-specs:

L (  column-start column-end )

,

NULL INDICATORS (  null-indicator-list )

sub-table-list:

(  sub-table-name )
,

(  insert-column )

traversal-order-list:

(  sub-table-name )

tblspace-specs:

IN tablespace-name
INDEX IN tablespace-name LONG IN tablespace-name

XDS-specs:

XDS

DEFAULT schema-sqlid ,

IGNORE (  schema-sqlid )

92 Data Movement Utilities Guide and Reference



,

MAP (  ( schema-sqlid , schema-sqlid ) )

Command parameters
ALL TABLES
An implicit keyword for hierarchy only. When importing a hierarchy, the
default is to import all tables specified in the traversal order.
ALLOW NO ACCESS
Runs import in the offline mode. An exclusive (X) lock on the target table
is acquired before any rows are inserted. This prevents concurrent
applications from accessing table data. This is the default import behavior.
ALLOW WRITE ACCESS
Runs import in the online mode. An intent exclusive (IX) lock on the target
table is acquired when the first row is inserted. This allows concurrent
readers and writers to access table data. Online mode is not compatible
with the REPLACE, CREATE, or REPLACE_CREATE import options.
Online mode is not supported in conjunction with buffered inserts. The
import operation will periodically commit inserted data to prevent lock
escalation to a table lock and to avoid running out of active log space.
These commits will be performed even if the COMMITCOUNT option
was not used. During each commit, import will lose its IX table lock, and
will attempt to reacquire it after the commit. This parameter is required
when you import to a nickname and COMMITCOUNT must be specified
with a valid number (AUTOMATIC is not considered a valid option).
AS ROOT TABLE
Creates one or more sub-tables as a stand-alone table hierarchy.
COMMITCOUNT n | AUTOMATIC
Performs a COMMIT after every n records are imported. When a number n
is specified, import performs a COMMIT after every n records are
imported. When compound inserts are used, a user-specified commit
frequency of n is rounded up to the first integer multiple of the compound
count value. When AUTOMATIC is specified, import internally determines
when a commit needs to be performed. The utility will commit for either
one of two reasons:
v to avoid running out of active log space
v to avoid lock escalation from row level to table level
If the ALLOW WRITE ACCESS option is specified, and the
COMMITCOUNT option is not specified, the import utility will perform
commits as if COMMITCOUNT AUTOMATIC had been specified.

The ability of the import operation to avoid running out of active log space
is affected by the DB2 registry variable
DB2_FORCE_APP_ON_MAX_LOG:
v If DB2_FORCE_APP_ON_MAX_LOG is set to FALSE and the
COMMITCOUNT AUTOMATIC command option is specified, the
import utility will be able to automatically avoid running out of active
log space.
v If DB2_FORCE_APP_ON_MAX_LOG is set to FALSE and the
COMMITCOUNT n command option is specified, the import utility will

Chapter 3. Import utility 93

 attempt to resolve the log full condition if it encounters an SQL0964C
(Transaction Log Full) while inserting or updating a record. It will
perform an unconditional commit and then will reattempt to insert or
update the record. If this does not help resolve the issue (which would
be the case when the log full is attributed to other activity on the
database), then the IMPORT command will fail as expected, however the
number of rows committed may not be a multiple of the
COMMITCOUNT n value. To avoid processing the rows that were
already committed when you retry the import operation, use the
RESTARTCOUNT or SKIPCOUNT command parameters.
v If DB2_FORCE_APP_ON_MAX_LOG is set to TRUE (which is the
default), the import operation will fail if it encounters an SQL0964C
while inserting or updating a record. This can occur irrespective of
whether you specify COMMITCOUNT AUTOMATIC or
COMMITCOUNT n.
The application is forced off the database and the current unit of work is
rolled back. To avoid processing the rows that were already committed
when you retry the import operation, use the RESTARTCOUNT or
SKIPCOUNT command parameters.
CREATE

Note: The CREATE parameter is deprecated and may be removed in a

future release. For additional details, see “IMPORT command options
CREATE and REPLACE_CREATE are deprecated”.
Creates the table definition and row contents in the code page of the
database. If the data was exported from a DB2 table, sub-table, or
hierarchy, indexes are created. If this option operates on a hierarchy, and
data was exported from DB2, a type hierarchy will also be created. This
option can only be used with IXF files.
This parameter is not valid when you import to a nickname.

Note: If the data was exported from an MVS host database, and it contains
LONGVAR fields whose lengths, calculated on the page size, are more
than 254, CREATE might fail because the rows are too long. See “Imported
table re-creation” for a list of restrictions. In this case, the table should be
created manually, and IMPORT with INSERT should be invoked, or,
alternatively, the LOAD command should be used.
DEFAULT schema-sqlid
This option can only be used when the USING XDS parameter is
specified. The schema specified through the DEFAULT clause identifies a
schema to use for validation when the XML Data Specifier (XDS) of an
imported XML document does not contain an SCH attribute identifying an
XML Schema.
The DEFAULT clause takes precedence over the IGNORE and MAP
clauses. If an XDS satisfies the DEFAULT clause, the IGNORE and MAP
specifications will be ignored.
FROM filename
HIERARCHY
Specifies that hierarchical data is to be imported.
IGNORE schema-sqlid
This option can only be used when the USING XDS parameter is

94 Data Movement Utilities Guide and Reference

 specified. The IGNORE clause specifies a list of one or more schemas to
ignore if they are identified by an SCH attribute. If an SCH attribute exists
in the XML Data Specifier for an imported XML document, and the schema
identified by the SCH attribute is included in the list of schemas to ignore,
then no schema validation will occur for the imported XML document.
If a schema is specified in the IGNORE clause, it cannot also be present in
the left side of a schema pair in the MAP clause.
The IGNORE clause applies only to the XDS. A schema that is mapped by
the MAP clause will not be subsequently ignored if specified by the
IGNORE clause.
IN tablespace-name
Identifies the table space in which the table will be created. The table space
must exist, and must be a REGULAR table space. If no other table space is
specified, all table parts are stored in this table space. If this clause is not
specified, the table is created in a table space created by the authorization
ID. If none is found, the table is placed into the default table space
USERSPACE1. If USERSPACE1 has been dropped, table creation fails.
INDEX IN tablespace-name
Identifies the table space in which any indexes on the table will be created.
This option is allowed only when the primary table space specified in the
IN clause is a DMS table space. The specified table space must exist, and
must be a REGULAR or LARGE DMS table space.

Note: Specifying which table space will contain an index can only be done
when the table is created.
insert-column
Specifies the name of a column in the table or the view into which data is
to be inserted.
INSERT
Adds the imported data to the table without changing the existing table
data.
INSERT_UPDATE
Adds rows of imported data to the target table, or updates existing rows
(of the target table) with matching primary keys.
INTO table-name
Specifies the database table into which the data is to be imported. This
table cannot be a system table, a declared temporary table or a summary
table.
One can use an alias for INSERT, INSERT_UPDATE, or REPLACE, except
in the case of an earlier server, when the fully qualified or the unqualified
table name should be used. A qualified table name is in the form:
schema.tablename. The schema is the user name under which the table was
created.
LOBS FROM lob-path
The names of the LOB data files are stored in the main data file (ASC,
DEL, or IXF), in the column that will be loaded into the LOB column. The
maximum number of paths that can be specified is 999. This will implicitly
activate the LOBSINFILE behavior.
This parameter is not valid when you import to a nickname.

Chapter 3. Import utility 95

 LONG IN tablespace-name
Identifies the table space in which the values of any long columns (LONG
VARCHAR, LONG VARGRAPHIC, LOB data types, or distinct types with
any of these as source types) will be stored. This option is allowed only if
the primary table space specified in the IN clause is a DMS table space.
The table space must exist, and must be a LARGE DMS table space.
MAP schema-sqlid
This option can only be used when the USING XDS parameter is
specified. Use the MAP clause to specify alternate schemas to use in place
of those specified by the SCH attribute of an XML Data Specifier (XDS) for
each imported XML document. The MAP clause specifies a list of one or
more schema pairs, where each pair represents a mapping of one schema
to another. The first schema in the pair represents a schema that is referred
to by an SCH attribute in an XDS. The second schema in the pair
represents the schema that should be used to perform schema validation.
If a schema is present in the left side of a schema pair in the MAP clause,
it cannot also be specified in the IGNORE clause.
Once a schema pair mapping is applied, the result is final. The mapping
operation is non-transitive, and therefore the schema chosen will not be
subsequently applied to another schema pair mapping.
A schema cannot be mapped more than once, meaning that it cannot
appear on the left side of more than one pair.
METHOD
L Specifies the start and end column numbers from which to import
data. A column number is a byte offset from the beginning of a
row of data. It is numbered starting from 1.

Note: This method can only be used with ASC files, and is the
only valid option for that file type.
N Specifies the names of the columns in the data file to be imported.
The case of these column names must match the case of the
corresponding names in the system catalogs. Each table column
that is not nullable should have a corresponding entry in the
METHOD N list. For example, given data fields F1, F2, F3, F4, F5,
and F6, and table columns C1 INT, C2 INT NOT NULL, C3 INT
NOT NULL, and C4 INT, method N (F2, F1, F4, F3) is a valid
request, while method N (F2, F1) is not valid.

Note: This method can only be used with IXF files.

P Specifies the field numbers of the input data fields to be imported.

Note: This method can only be used with IXF or DEL files, and is
the only valid option for the DEL file type.
MODIFIED BY filetype-mod
Specifies file type modifier options. See “File type modifiers for the import
utility” on page 103.
NOTIMEOUT
Specifies that the import utility will not time out while waiting for locks.
This option supersedes the locktimeout database configuration parameter.
Other applications are not affected.

96 Data Movement Utilities Guide and Reference

NULL INDICATORS null-indicator-list
This option can only be used when the METHOD L parameter is specified.
That is, the input file is an ASC file. The null indicator list is a
comma-separated list of positive integers specifying the column number of
each null indicator field. The column number is the byte offset of the null
indicator field from the beginning of a row of data. There must be one
entry in the null indicator list for each data field defined in the METHOD
L parameter. A column number of zero indicates that the corresponding
data field always contains data.
A value of Y in the NULL indicator column specifies that the column data
is NULL. Any character other than Y in the NULL indicator column
specifies that the column data is not NULL, and that column data specified
by the METHOD L option will be imported.
The NULL indicator character can be changed using the MODIFIED BY
option, with the nullindchar file type modifier.
OF filetype
Specifies the format of the data in the input file:
v ASC (non-delimited ASCII format)
v DEL (delimited ASCII format), which is used by a variety of database
manager and file manager programs
v WSF (work sheet format), which is used by programs such as:
– Lotus 1-2-3
– Lotus Symphony
v IXF (Integration Exchange Format, PC version) is a binary format that is
used exclusively by DB2.
The WSF file type is not supported when you import to a nickname.
REPLACE
Deletes all existing data from the table by truncating the data object, and
inserts the imported data. The table definition and the index definitions are
not changed. This option can only be used if the table exists. If this option
is used when moving data between hierarchies, only the data for an entire
hierarchy, not individual subtables, can be replaced.
This parameter is not valid when you import to a nickname.
This option does not honor the CREATE TABLE statement's NOT
LOGGED INITIALLY (NLI) clause or the ALTER TABLE statement's
ACTIVE NOT LOGGED INITIALLY clause.
If an import with the REPLACE option is performed within the same
transaction as a CREATE TABLE or ALTER TABLE statement where the
NLI clause is invoked, the import will not honor the NLI clause. All inserts
will be logged.
Workaround 1
Delete the contents of the table using the DELETE statement, then
invoke the import with INSERT statement
Workaround 2
Drop the table and recreate it, then invoke the import with INSERT
statement.
This limitation applies to DB2 Universal Database Version 7 and DB2 UDB
Version 8

Chapter 3. Import utility 97

 REPLACE_CREATE

Note: The REPLACE_CREATE parameter is deprecated and may be

removed in a future release. For additional details, see “IMPORT command
options CREATE and REPLACE_CREATE are deprecated”.
If the table exists, deletes all existing data from the table by truncating the
data object, and inserts the imported data without changing the table
definition or the index definitions.
If the table does not exist, creates the table and index definitions, as well as
the row contents, in the code page of the database. See Imported table
re-creation for a list of restrictions.
This option can only be used with IXF files. If this option is used when
moving data between hierarchies, only the data for an entire hierarchy, not
individual subtables, can be replaced.
This parameter is not valid when you import to a nickname.
RESTARTCOUNT n
Specifies that an import operation is to be started at record n+1. The first n
records are skipped. This option is functionally equivalent to
SKIPCOUNT. RESTARTCOUNT and SKIPCOUNT are mutually
exclusive.
ROWCOUNT n
Specifies the number n of physical records in the file to be imported
(inserted or updated). Allows a user to import only n rows from a file,
starting from the record determined by the SKIPCOUNT or
RESTARTCOUNT options. If the SKIPCOUNT or RESTARTCOUNT
options are not specified, the first n rows are imported. If SKIPCOUNT m
or RESTARTCOUNT m is specified, rows m+1 to m+n are imported. When
compound inserts are used, user specified ROWCOUNT n is rounded up
to the first integer multiple of the compound count value.
SKIPCOUNT n
Specifies that an import operation is to be started at record n+1. The first n
records are skipped. This option is functionally equivalent to
RESTARTCOUNT. SKIPCOUNT and RESTARTCOUNT are mutually
exclusive.
STARTING sub-table-name
A keyword for hierarchy only, requesting the default order, starting from
sub-table-name. For PC/IXF files, the default order is the order stored in the
input file. The default order is the only valid order for the PC/IXF file
format.
sub-table-list
For typed tables with the INSERT or the INSERT_UPDATE option, a list
of sub-table names is used to indicate the sub-tables into which data is to
be imported.
traversal-order-list
For typed tables with the INSERT, INSERT_UPDATE, or the REPLACE
option, a list of sub-table names is used to indicate the traversal order of
the importing sub-tables in the hierarchy.
UNDER sub-table-name
Specifies a parent table for creating one or more sub-tables.

98 Data Movement Utilities Guide and Reference

WARNINGCOUNT n
Stops the import operation after n warnings. Set this parameter if no
warnings are expected, but verification that the correct file and table are
being used is desired. If the import file or the target table is specified
incorrectly, the import utility will generate a warning for each row that it
attempts to import, which will cause the import to fail. If n is zero, or this
option is not specified, the import operation will continue regardless of the
number of warnings issued.
XML FROM xml-path
Specifies one or more paths that contain the XML files.
XMLPARSE
Specifies how XML documents are parsed. If this option is not specified,
the parsing behavior for XML documents will be determined by the value
of the CURRENT XMLPARSE OPTION special register.
STRIP WHITESPACE
Specifies to remove whitespace when the XML document is parsed.
PRESERVE WHITESPACE
Specifies not to remove whitespace when the XML document is
parsed.
XMLVALIDATE
Specifies that XML documents are validated against a schema, when
applicable.
USING XDS
XML documents are validated against the XML schema identified
by the XML Data Specifier (XDS) in the main data file. By default,
if the XMLVALIDATE option is invoked with the USING XDS
clause, the schema used to perform validation will be determined
by the SCH attribute of the XDS. If an SCH attribute is not present
in the XDS, no schema validation will occur unless a default
schema is specified by the DEFAULT clause.
The DEFAULT, IGNORE, and MAP clauses can be used to modify
the schema determination behavior. These three optional clauses
apply directly to the specifications of the XDS, and not to each
other. For example, if a schema is selected because it is specified by
the DEFAULT clause, it will not be ignored if also specified by the
IGNORE clause. Similarly, if a schema is selected because it is
specified as the first part of a pair in the MAP clause, it will not be
re-mapped if also specified in the second part of another MAP
clause pair.
USING SCHEMA schema-sqlid
XML documents are validated against the XML schema with the
specified SQL identifier. In this case, the SCH attribute of the XML
Data Specifier (XDS) will be ignored for all XML columns.
USING SCHEMALOCATION HINTS
XML documents are validated against the schemas identified by
XML schema location hints in the source XML documents. If a
schemaLocation attribute is not found in the XML document, no
validation will occur. When the USING SCHEMALOCATION
HINTS clause is specified, the SCH attribute of the XML Data
Specifier (XDS) will be ignored for all XML columns.

Chapter 3. Import utility 99

 See examples of the XMLVALIDATE option below.

Usage notes

Be sure to complete all table operations and release all locks before starting an
import operation. This can be done by issuing a COMMIT after closing all cursors
opened WITH HOLD, or by issuing a ROLLBACK.

The import utility adds rows to the target table using the SQL INSERT statement.
The utility issues one INSERT statement for each row of data in the input file. If an
INSERT statement fails, one of two actions result:
v If it is likely that subsequent INSERT statements can be successful, a warning
message is written to the message file, and processing continues.
v If it is likely that subsequent INSERT statements will fail, and there is potential
for database damage, an error message is written to the message file, and
processing halts.

The utility performs an automatic COMMIT after the old rows are deleted during a
REPLACE or a REPLACE_CREATE operation. Therefore, if the system fails, or the
application interrupts the database manager after the table object is truncated, all
of the old data is lost. Ensure that the old data is no longer needed before using
these options.

If the log becomes full during a CREATE, REPLACE, or REPLACE_CREATE

operation, the utility performs an automatic COMMIT on inserted records. If the
system fails, or the application interrupts the database manager after an automatic
COMMIT, a table with partial data remains in the database. Use the REPLACE or
the REPLACE_CREATE option to rerun the whole import operation, or use
INSERT with the RESTARTCOUNT parameter set to the number of rows
successfully imported.

Updates from the IMPORT command will always be committed at the end of an
IMPORT task. The IMPORT command can also perform automatic commits during
its execution to reduce the size of the lock list and the active log space. The
IMPORT command will rollback if the active log becomes full during IMPORT
processing.
v By default, automatic commits are not performed for the INSERT or the
INSERT_UPDATE option. They are, however, performed if the
COMMITCOUNT parameter is not zero.
v Offline import does not perform automatic COMMITs if any of the following
conditions are true:
– The target is a view, not a table
– Compound inserts are used
– Buffered inserts are used
v By default, online import performs automatic commit to free both the active log
space and the lock list. Automatic commits are not performed only if a
COMMITCOUNT value of zero is specified.

Whenever the import utility performs a COMMIT, two messages are written to the
message file: one indicates the number of records to be committed, and the other is
written after a successful COMMIT. When restarting the import operation after a
failure, specify the number of records to skip, as determined from the last
successful COMMIT.

100 Data Movement Utilities Guide and Reference

The import utility accepts input data with minor incompatibility problems (for
example, character data can be imported using padding or truncation, and numeric
data can be imported with a different numeric data type), but data with major
incompatibility problems is not accepted.

You cannot REPLACE or REPLACE_CREATE an object table if it has any

dependents other than itself, or an object view if its base table has any dependents
(including itself). To replace such a table or a view, do the following:
1. Drop all foreign keys in which the table is a parent.
2. Run the import utility.
3. Alter the table to recreate the foreign keys.

If an error occurs while recreating the foreign keys, modify the data to maintain
referential integrity.

Referential constraints and foreign key definitions are not preserved when
recreating tables from PC/IXF files. (Primary key definitions are preserved if the
data was previously exported using SELECT *.)

Importing to a remote database requires enough disk space on the server for a
copy of the input data file, the output message file, and potential growth in the
size of the database.

If an import operation is run against a remote database, and the output message
file is very long (more than 60 KB), the message file returned to the user on the
client might be missing messages from the middle of the import operation. The
first 30 KB of message information and the last 30 KB of message information are
always retained.

Importing PC/IXF files to a remote database is much faster if the PC/IXF file is on
a hard drive rather than on diskettes.

The database table or hierarchy must exist before data in the ASC, DEL, or WSF
file formats can be imported; however, if the table does not already exist, IMPORT
CREATE or IMPORT REPLACE_CREATE creates the table when it imports data
from a PC/IXF file. For typed tables, IMPORT CREATE can create the type
hierarchy and the table hierarchy as well.

PC/IXF import should be used to move data (including hierarchical data) between
databases. If character data containing row separators is exported to a delimited
ASCII (DEL) file and processed by a text transfer program, fields containing the
row separators will shrink or expand. The file copying step is not necessary if the
source and the target databases are both accessible from the same client.

The data in ASC and DEL files is assumed to be in the code page of the client
application performing the import. PC/IXF files, which allow for different code
pages, are recommended when importing data in different code pages. If the
PC/IXF file and the import utility are in the same code page, processing occurs as
for a regular application. If the two differ, and the FORCEIN option is specified,
the import utility assumes that data in the PC/IXF file has the same code page as
the application performing the import. This occurs even if there is a conversion
table for the two code pages. If the two differ, the FORCEIN option is not
specified, and there is a conversion table, all data in the PC/IXF file will be
converted from the file code page to the application code page. If the two differ,

Chapter 3. Import utility 101

 the FORCEIN option is not specified, and there is no conversion table, the import
operation will fail. This applies only to PC/IXF files on DB2 clients on the AIX
operating system.

For table objects on an 8 KB page that are close to the limit of 1012 columns,
import of PC/IXF data files might cause DB2 to return an error, because the
maximum size of an SQL statement was exceeded. This situation can occur only if
the columns are of type CHAR, VARCHAR, or CLOB. The restriction does not
apply to import of DEL or ASC files. If PC/IXF files are being used to create a
new table, an alternative is use db2look to dump the DDL statement that created
the table, and then to issue that statement through the CLP.

DB2 Connect can be used to import data to DRDA servers such as DB2 for
OS/390, DB2 for VM and VSE, and DB2 for OS/400. Only PC/IXF import
(INSERT option) is supported. The RESTARTCOUNT parameter, but not the
COMMITCOUNT parameter, is also supported.

When using the CREATE option with typed tables, create every sub-table defined
in the PC/IXF file; sub-table definitions cannot be altered. When using options
other than CREATE with typed tables, the traversal order list enables one to
specify the traverse order; therefore, the traversal order list must match the one
used during the export operation. For the PC/IXF file format, one need only
specify the target sub-table name, and use the traverse order stored in the file.

The import utility can be used to recover a table previously exported to a PC/IXF
file. The table returns to the state it was in when exported.

Data cannot be imported to a system table, a declared temporary table, or a

summary table.

Views cannot be created through the import utility.

Importing a multiple-part PC/IXF file whose individual parts are copied from a
Windows system to an AIX system is supported. Only the name of the first file
must be specified in the IMPORT command. For example, IMPORT FROM data.ixf
OF IXF INSERT INTO TABLE1. The file data.002, etc should be available in the same
directory as data.ixf.

On the Windows operating system:

v Importing logically split PC/IXF files is not supported.
v Importing bad format PC/IXF or WSF files is not supported.

Security labels in their internal format might contain newline characters. If you
import the file using the DEL file format, those newline characters can be mistaken
for delimiters. If you have this problem use the older default priority for delimiters
by specifying the delprioritychar file type modifier in the IMPORT command.

Federated considerations

When using the IMPORT command and the INSERT, UPDATE, or

INSERT_UPDATE command parameters, you must ensure that you have
CONTROL privilege on the participating nickname. You must ensure that the
nickname you want to use when doing an import operation already exists. There
are also several restrictions you should be aware of as shown in the IMPORT
command parameters section.

102 Data Movement Utilities Guide and Reference

 Some data sources, such as ODBC, do not support importing into nicknames.

File type modifiers for the import utility

Table 20. Valid file type modifiers for the import utility: All file formats
Modifier Description
compound=x x is a number between 1 and 100 inclusive. Uses nonatomic compound SQL to
insert the data, and x statements will be attempted each time.

If this modifier is specified, and the transaction log is not sufficiently large, the
import operation will fail. The transaction log must be large enough to
accommodate either the number of rows specified by COMMITCOUNT, or the
number of rows in the data file if COMMITCOUNT is not specified. It is
therefore recommended that the COMMITCOUNT option be specified to avoid
transaction log overflow.

This modifier is incompatible with INSERT_UPDATE mode, hierarchical tables,

and the following modifiers: usedefaults, identitymissing, identityignore,
generatedmissing, and generatedignore.
generatedignore This modifier informs the import utility that data for all generated columns is
present in the data file but should be ignored. This results in all values for the
generated columns being generated by the utility. This modifier cannot be used
with the generatedmissing modifier.
generatedmissing If this modifier is specified, the utility assumes that the input data file contains no
data for the generated columns (not even NULLs), and will therefore generate a
value for each row. This modifier cannot be used with the generatedignore
modifier.
identityignore This modifier informs the import utility that data for the identity column is
present in the data file but should be ignored. This results in all identity values
being generated by the utility. The behavior will be the same for both
GENERATED ALWAYS and GENERATED BY DEFAULT identity columns. This
means that for GENERATED ALWAYS columns, no rows will be rejected. This
modifier cannot be used with the identitymissing modifier.
identitymissing If this modifier is specified, the utility assumes that the input data file contains no
data for the identity column (not even NULLs), and will therefore generate a
value for each row. The behavior will be the same for both GENERATED
ALWAYS and GENERATED BY DEFAULT identity columns. This modifier cannot
be used with the identityignore modifier.
lobsinfile lob-path specifies the path to the files containing LOB data.

Each path contains at least one file that contains at least one LOB pointed to by a
Lob Location Specifier (LLS) in the data file. The LLS is a string representation of
the location of a LOB in a file stored in the LOB file path. The format of an LLS is
filename.ext.nnn.mmm/, where filename.ext is the name of the file that contains
the LOB, nnn is the offset in bytes of the LOB within the file, and mmm is the
length of the LOB in bytes. For example, if the string db2exp.001.123.456/ is
stored in the data file, the LOB is located at offset 123 in the file db2exp.001, and
is 456 bytes long.

The LOBS FROM clause specifies where the LOB files are located when the
“lobsinfile” modifier is used. The LOBS FROM clause will implicitly activate the
LOBSINFILE behavior. The LOBS FROM clause conveys to the IMPORT utility
the list of paths to search for the LOB files while importing the data.

To indicate a null LOB, enter the size as -1. If the size is specified as 0, it is
treated as a 0 length LOB. For null LOBS with length of -1, the offset and the file
name are ignored. For example, the LLS of a null LOB might be db2exp.001.7.-1/.

Chapter 3. Import utility 103

Table 20. Valid file type modifiers for the import utility: All file formats (continued)
Modifier Description
no_type_id Valid only when importing into a single sub-table. Typical usage is to export data
from a regular table, and then to invoke an import operation (using this modifier)
to convert the data into a single sub-table.
nodefaults If a source column for a target table column is not explicitly specified, and the
table column is not nullable, default values are not loaded. Without this option, if
a source column for one of the target table columns is not explicitly specified, one
of the following occurs:
v If a default value can be specified for a column, the default value is loaded
v If the column is nullable, and a default value cannot be specified for that
column, a NULL is loaded
v If the column is not nullable, and a default value cannot be specified, an error
is returned, and the utility stops processing.
norowwarnings Suppresses all warnings about rejected rows.
rowchangetimestampignore This modifier informs the import utility that data for the row change timestamp
column is present in the data file but should be ignored. This results in all ROW
CHANGE TIMESTAMP being generated by the utility. The behavior will be the
same for both GENERATED ALWAYS and GENERATED BY DEFAULT columns.
This means that for GENERATED ALWAYS columns, no rows will be rejected.
This modifier cannot be used with the rowchangetimestampmissing modifier.
rowchangetimestampmissing If this modifier is specified, the utility assumes that the input data file contains no
data for the row change timestamp column (not even NULLs), and will therefore
generate a value for each row. The behavior will be the same for both
GENERATED ALWAYS and GENERATED BY DEFAULT columns. This modifier
cannot be used with the rowchangetimestampignore modifier.
seclabelchar Indicates that security labels in the input source file are in the string format for
security label values rather than in the default encoded numeric format. IMPORT
converts each security label into the internal format as it is loaded. If a string is
not in the proper format the row is not loaded and a warning (SQLSTATE 01H53)
is returned. If the string does not represent a valid security label that is part of
the security policy protecting the table then the row is not loaded and a warning
(SQLSTATE 01H53, SQLCODE SQL3243W)) is returned.

This modifier cannot be specified if the seclabelname modifier is specified,

otherwise the import fails and an error (SQLCODE SQL3525N) is returned.
seclabelname Indicates that security labels in the input source file are indicated by their name
rather than the default encoded numeric format. IMPORT will convert the name
to the appropriate security label if it exists. If no security label exists with the
indicated name for the security policy protecting the table the row is not loaded
and a warning (SQLSTATE 01H53, SQLCODE SQL3244W) is returned.

This modifier cannot be specified if the seclabelchar modifier is specified,

otherwise the import fails and an error (SQLCODE SQL3525N) is returned.
Note: If the file type is ASC, any spaces following the name of the security label
will be interpreted as being part of the name. To avoid this use the striptblanks
file type modifier to make sure the spaces are removed.

104 Data Movement Utilities Guide and Reference

Table 20. Valid file type modifiers for the import utility: All file formats (continued)
Modifier Description
usedefaults If a source column for a target table column has been specified, but it contains no
data for one or more row instances, default values are loaded. Examples of
missing data are:
v For DEL files: two adjacent column delimiters (",,") or two adjacent column
delimiters separated by an arbitrary number of spaces (", ,") are specified for a
column value.
v For DEL/ASC/WSF files: A row that does not have enough columns, or is not
long enough for the original specification.
Note: For ASC files, NULL column values are not considered explicitly
missing, and a default will not be substituted for NULL column values. NULL
column values are represented by all space characters for numeric, date, time,
and /timestamp columns, or by using the NULL INDICATOR for a column of
any type to indicate the column is NULL.
Without this option, if a source column contains no data for a row instance, one
of the following occurs:
v For DEL/ASC/WSF files: If the column is nullable, a NULL is loaded. If the
column is not nullable, the utility rejects the row.

Table 21. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL)
Modifier Description
codepage=x x is an ASCII character string. The value is interpreted as the code page of the
data in the input data set. Converts character data from this code page to the
application code page during the import operation.

The following rules apply:

v For pure DBCS (graphic) mixed DBCS, and EUC, delimiters are restricted to the
range of x00 to x3F, inclusive.
v nullindchar must specify symbols included in the standard ASCII set between
code points x20 and x7F, inclusive. This refers to ASCII symbols and code
points.
Note:
1. The codepage modifier cannot be used with the lobsinfile modifier.
2. If data expansion occurs when the code page is converted from the
application code page to the database code page, the data might be truncated
and loss of data can occur.
dateformat="x" x is the format of the date in the source file.2 Valid date elements are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 1 - 12;
mutually exclusive with M)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31;
mutually exclusive with D)
DDD - Day of the year (three digits ranging
from 001 - 366; mutually exclusive
with other day or month elements)

A default value of 1 is assigned for each element that is not specified. Some
examples of date formats are:
"D-M-YYYY"
"MM.DD.YYYY"
"YYYYDDD"

Chapter 3. Import utility 105

Table 21. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
implieddecimal The location of an implied decimal point is determined by the column definition;
it is no longer assumed to be at the end of the value. For example, the value
12345 is loaded into a DECIMAL(8,2) column as 123.45, not 12345.00.
timeformat="x" x is the format of the time in the source file.2 Valid time elements are:
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24
for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24
for a 24 hour system; mutually exclusive
with H)
M - Minute (one or two digits ranging
from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M)
S - Second (one or two digits ranging
from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
TT - Meridian indicator (AM or PM)

A default value of 0 is assigned for each element that is not specified. Some
examples of time formats are:
"HH:MM:SS"
"HH.MM TT"
"SSSSS"

106 Data Movement Utilities Guide and Reference

Table 21. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
timestampformat="x" x is the format of the time stamp in the source file.2 Valid time stamp elements
are:
YYYY - Year (four digits ranging from 0000 - 9999)
M - Month (one or two digits ranging from 1 - 12)
MM - Month (two digits ranging from 01 - 12;
mutually exclusive with M and MMM)
MMM - Month (three-letter case-insensitive abbreviation for
the month name; mutually exclusive with M and MM)
D - Day (one or two digits ranging from 1 - 31)
DD - Day (two digits ranging from 1 - 31; mutually exclusive with D)
DDD - Day of the year (three digits ranging from 001 - 366;
mutually exclusive with other day or month elements)
H - Hour (one or two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system)
HH - Hour (two digits ranging from 0 - 12
for a 12 hour system, and 0 - 24 for a 24 hour system;
mutually exclusive with H)
M - Minute (one or two digits ranging from 0 - 59)
MM - Minute (two digits ranging from 0 - 59;
mutually exclusive with M, minute)
S - Second (one or two digits ranging from 0 - 59)
SS - Second (two digits ranging from 0 - 59;
mutually exclusive with S)
SSSSS - Second of the day after midnight (5 digits
ranging from 00000 - 86399; mutually
exclusive with other time elements)
UUUUUU - Microsecond (6 digits ranging from 000000 - 999999;
mutually exclusive with all other microsecond elements)
UUUUU - Microsecond (5 digits ranging from 00000 - 99999,
maps to range from 000000 - 999990;
mutually exclusive with all other microseond elements)
UUUU - Microsecond (4 digits ranging from 0000 - 9999,
maps to range from 000000 - 999900;
mutually exclusive with all other microseond elements)
UUU - Microsecond (3 digits ranging from 000 - 999,
maps to range from 000000 - 999000;
mutually exclusive with all other microseond elements)
UU - Microsecond (2 digits ranging from 00 - 99,
maps to range from 000000 - 990000;
mutually exclusive with all other microseond elements)
U - Microsecond (1 digit ranging from 0 - 9,
maps to range from 000000 - 900000;
mutually exclusive with all other microseond elements)
TT - Meridian indicator (AM or PM)

A default value of 1 is assigned for unspecified YYYY, M, MM, D, DD, or DDD

elements. A default value of 'Jan' is assigned to an unspecified MMM element. A
default value of 0 is assigned for all other unspecified elements. Following is an
example of a time stamp format:
"YYYY/MM/DD HH:MM:SS.UUUUUU"

The valid values for the MMM element include: 'jan', 'feb', 'mar', 'apr', 'may', 'jun',
'jul', 'aug', 'sep', 'oct', 'nov' and 'dec'. These values are case insensitive.

The following example illustrates how to import data containing user defined
date and time formats into a table called schedule:
db2 import from delfile2 of del
modified by timestampformat="yyyy.mm.dd hh:mm tt"
insert into schedule

Chapter 3. Import utility 107

Table 21. Valid file type modifiers for the import utility: ASCII file formats (ASC/DEL) (continued)
Modifier Description
usegraphiccodepage If usegraphiccodepage is given, the assumption is made that data being imported
into graphic or double-byte character large object (DBCLOB) data fields is in the
graphic code page. The rest of the data is assumed to be in the character code
page. The graphic code page is associated with the character code page. IMPORT
determines the character code page through either the codepage modifier, if it is
specified, or through the code page of the application if the codepage modifier is
not specified.

This modifier should be used in conjunction with the delimited data file
generated by drop table recovery only if the table being recovered has graphic
data.

Restrictions

The usegraphiccodepage modifier MUST NOT be specified with DEL files created
by the EXPORT utility, as these files contain data encoded in only one code page.
The usegraphiccodepage modifier is also ignored by the double-byte character
large objects (DBCLOBs) in files.
xmlchar Specifies that XML documents are encoded in the character code page.

This option is useful for processing XML documents that are encoded in the
specified character code page but do not contain an encoding declaration.

For each document, if a declaration tag exists and contains an encoding attribute,
the encoding must match the character code page, otherwise the row containing
the document will be rejected. Note that the character codepage is the value
specified by the codepage file type modifier, or the application codepage if it is
not specified. By default, either the documents are encoded in Unicode, or they
contain a declaration tag with an encoding attribute.
xmlgraphic Specifies that XML documents are encoded in the specified graphic code page.

This option is useful for processing XML documents that are encoded in a specific
graphic code page but do not contain an encoding declaration.

For each document, if a declaration tag exists and contains an encoding attribute,
the encoding must match the graphic code page, otherwise the row containing
the document will be rejected. Note that the graphic code page is the graphic
component of the value specified by the codepage file type modifier, or the
graphic component of the application code page if it is not specified. By default,
documents are either encoded in Unicode, or they contain a declaration tag with
an encoding attribute.
Note: If the xmlgraphic modifier is specified with the IMPORT command, the
XML document to be imported must be encoded in the UTF-16 code page.
Otherwise, the XML document may be rejected with a parsing error, or it may be
imported into the table with data corruption.

Table 22. Valid file type modifiers for the import utility: ASC (non-delimited ASCII) file format
Modifier Description
nochecklengths If nochecklengths is specified, an attempt is made to import each row, even if the
source data has a column definition that exceeds the size of the target table
column. Such rows can be successfully imported if code page conversion causes
the source data to shrink; for example, 4-byte EUC data in the source could
shrink to 2-byte DBCS data in the target, and require half the space. This option
is particularly useful if it is known that the source data will fit in all cases despite
mismatched column definitions.

108 Data Movement Utilities Guide and Reference

Table 22. Valid file type modifiers for the import utility: ASC (non-delimited ASCII) file format (continued)
Modifier Description
nullindchar=x x is a single character. Changes the character denoting a null value to x. The
default value of x is Y.3

This modifier is case sensitive for EBCDIC data files, except when the character is
an English letter. For example, if the null indicator character is specified to be the
letter N, then n is also recognized as a null indicator.
reclen=x x is an integer with a maximum value of 32 767. x characters are read for each
row, and a new-line character is not used to indicate the end of the row.
striptblanks Truncates any trailing blank spaces when loading data into a variable-length field.
If this option is not specified, blank spaces are kept.

In the following example, striptblanks causes the import utility to truncate

trailing blank spaces:
db2 import from myfile.asc of asc
modified by striptblanks
method l (1 10, 12 15) messages msgs.txt
insert into staff

This option cannot be specified together with striptnulls. These are mutually
exclusive options. This option replaces the obsolete t option, which is supported
for earlier compatibility only.
striptnulls Truncates any trailing NULLs (0x00 characters) when loading data into a
variable-length field. If this option is not specified, NULLs are kept.

This option cannot be specified together with striptblanks. These are mutually
exclusive options. This option replaces the obsolete padwithzero option, which is
supported for earlier compatibility only.

Table 23. Valid file type modifiers for the import utility: DEL (delimited ASCII) file format
Modifier Description
chardelx x is a single character string delimiter. The default value is a double quotation
mark ("). The specified character is used in place of double quotation marks to
enclose a character string.34 If you want to explicitly specify the double quotation
mark as the character string delimiter, it should be specified as follows:
modified by chardel""

The single quotation mark (') can also be specified as a character string delimiter.
In the following example, chardel’’ causes the import utility to interpret any
single quotation mark (') it encounters as a character string delimiter:
db2 "import from myfile.del of del
modified by chardel’’
method p (1, 4) insert into staff (id, years)"
coldelx x is a single character column delimiter. The default value is a comma (,). The
specified character is used in place of a comma to signal the end of a column.34

In the following example, coldel; causes the import utility to interpret any
semicolon (;) it encounters as a column delimiter:
db2 import from myfile.del of del
modified by coldel;
messages msgs.txt insert into staff
decplusblank Plus sign character. Causes positive decimal values to be prefixed with a blank
space instead of a plus sign (+). The default action is to prefix positive decimal
values with a plus sign.

Chapter 3. Import utility 109

Table 23. Valid file type modifiers for the import utility: DEL (delimited ASCII) file format (continued)
Modifier Description
decptx x is a single character substitute for the period as a decimal point character. The
default value is a period (.). The specified character is used in place of a period as
a decimal point character.34

In the following example, decpt; causes the import utility to interpret any
semicolon (;) it encounters as a decimal point:
db2 "import from myfile.del of del
modified by chardel’’
decpt; messages msgs.txt insert into staff"
delprioritychar The current default priority for delimiters is: record delimiter, character delimiter,
column delimiter. This modifier protects existing applications that depend on the
older priority by reverting the delimiter priorities to: character delimiter, record
delimiter, column delimiter. Syntax:
db2 import ... modified by delprioritychar ...

For example, given the following DEL data file:

"Smith, Joshua",4000,34.98<row delimiter>
"Vincent,<row delimiter>, is a manager", ...
... 4005,44.37<row delimiter>

With the delprioritychar modifier specified, there will be only two rows in this
data file. The second <row delimiter> will be interpreted as part of the first data
column of the second row, while the first and the third <row delimiter> are
interpreted as actual record delimiters. If this modifier is not specified, there will
be three rows in this data file, each delimited by a <row delimiter>.
keepblanks Preserves the leading and trailing blanks in each field of type CHAR, VARCHAR,
LONG VARCHAR, or CLOB. Without this option, all leading and trailing blanks
that are not inside character delimiters are removed, and a NULL is inserted into
the table for all blank fields.
nochardel The import utility will assume all bytes found between the column delimiters to
be part of the column's data. Character delimiters will be parsed as part of
column data. This option should not be specified if the data was exported using
DB2 (unless nochardel was specified at export time). It is provided to support
vendor data files that do not have character delimiters. Improper usage might
result in data loss or corruption.

This option cannot be specified with chardelx, delprioritychar or nodoubledel.

These are mutually exclusive options.
nodoubledel Suppresses recognition of double character delimiters.

Table 24. Valid file type modifiers for the import utility: IXF file format
Modifier Description
forcein Directs the utility to accept data despite code page mismatches, and to suppress
translation between code pages.

Fixed length target fields are checked to verify that they are large enough for the
data. If nochecklengths is specified, no checking is done, and an attempt is made
to import each row.
indexixf Directs the utility to drop all indexes currently defined on the existing table, and
to create new ones from the index definitions in the PC/IXF file. This option can
only be used when the contents of a table are being replaced. It cannot be used
with a view, or when a insert-column is specified.

110 Data Movement Utilities Guide and Reference

Table 24. Valid file type modifiers for the import utility: IXF file format (continued)
Modifier Description
indexschema=schema Uses the specified schema for the index name during index creation. If schema is
not specified (but the keyword indexschema is specified), uses the connection user
ID. If the keyword is not specified, uses the schema in the IXF file.
nochecklengths If nochecklengths is specified, an attempt is made to import each row, even if the
source data has a column definition that exceeds the size of the target table
column. Such rows can be successfully imported if code page conversion causes
the source data to shrink; for example, 4-byte EUC data in the source could
shrink to 2-byte DBCS data in the target, and require half the space. This option
is particularly useful if it is known that the source data will fit in all cases despite
mismatched column definitions.
forcecreate Specifies that the table should be created with possible missing or limited
information after returning SQL3311N during an import operation.

Table 25. IMPORT behavior when using codepage and usegraphiccodepage

codepage=N usegraphiccodepage IMPORT behavior
Absent Absent All data in the file is assumed to be in the application
code page.
Present Absent All data in the file is assumed to be in code page N.

Warning: Graphic data will be corrupted when

imported into the database if N is a single-byte code
page.
Absent Present Character data in the file is assumed to be in the
application code page. Graphic data is assumed to be in
the code page of the application graphic data.

If the application code page is single-byte, then all data

is assumed to be in the application code page.

Warning: If the application code page is single-byte,

graphic data will be corrupted when imported into the
database, even if the database contains graphic columns.
Present Present Character data is assumed to be in code page N. Graphic
data is assumed to be in the graphic code page of N.

If N is a single-byte or double-byte code page, then all

data is assumed to be in code page N.

Warning: Graphic data will be corrupted when

imported into the database if N is a single-byte code
page.

Note:
1. The import utility does not issue a warning if an attempt is made to use
unsupported file types with the MODIFIED BY option. If this is attempted,
the import operation fails, and an error code is returned.
2. Double quotation marks around the date format string are mandatory. Field
separators cannot contain any of the following: a-z, A-Z, and 0-9. The field
separator should not be the same as the character delimiter or field delimiter
in the DEL file format. A field separator is optional if the start and end

Chapter 3. Import utility 111

 positions of an element are unambiguous. Ambiguity can exist if (depending
on the modifier) elements such as D, H, M, or S are used, because of the
variable length of the entries.
For time stamp formats, care must be taken to avoid ambiguity between the
month and the minute descriptors, since they both use the letter M. A month
field must be adjacent to other date fields. A minute field must be adjacent to
other time fields. Following are some ambiguous time stamp formats:
"M" (could be a month, or a minute)
"M:M" (Which is which?)
"M:YYYY:M" (Both are interpreted as month.)
"S:M:YYYY" (adjacent to both a time value and a date value)

In ambiguous cases, the utility will report an error message, and the operation
will fail.
Following are some unambiguous time stamp formats:
"M:YYYY" (Month)
"S:M" (Minute)
"M:YYYY:S:M" (Month....Minute)
"M:H:YYYY:M:D" (Minute....Month)
Some characters, such as double quotation marks and back slashes, must be
preceded by an escape character (for example, \).
3. Character values provided for the chardel, coldel, or decpt file type modifiers
must be specified in the code page of the source data.
The character code point (instead of the character symbol), can be specified
using the syntax xJJ or 0xJJ, where JJ is the hexadecimal representation of the
code point. For example, to specify the # character as a column delimiter, use
one of the following:
... modified by coldel# ...
... modified by coldel0x23 ...
... modified by coldelX23 ...
4. Delimiter considerations for moving data lists restrictions that apply to the
characters that can be used as delimiter overrides.
5. The following file type modifiers are not allowed when importing into a
nickname:
v indexixf
v indexschema
v dldelfiletype
v nodefaults
v usedefaults
v no_type_idfiletype
v generatedignore
v generatedmissing
v identityignore
v identitymissing
v lobsinfile
6. The WSF file format is not supported for XML columns.
7. The CREATE mode is not supported for XML columns.
8. All XML data must reside in XML files that are separate from the main data
file. An XML Data Specifier (XDS) (or a NULL value) must exist for each XML
column in the main data file.

112 Data Movement Utilities Guide and Reference

 9. XML documents are assumed to be in Unicode format or to contain a
declaration tag that includes an encoding attribute, unless the XMLCHAR or
XMLGRAPHIC file type modifier is specified.
10. Rows containing documents that are not well-formed will be rejected.
11. If the XMLVALIDATE option is specified, documents that successfully
validate against their matching schema will be annotated with the schema
information as they are inserted. Rows containing documents that fail to
validate against their matching schema will be rejected. To successfully
perform the validation, the privileges held by the user invoking the import
must include at least one of the following:
v SYSADM or DBADM authority
v USAGE privilege on the XML schema to be used in the validation
12. When importing into a table containing an implicitly hidden row change
timestamp column, the implicitly hidden property of the column is not
honoured. Therefore, the rowchangetimestampmissing file type modifier must
be specified in the import command if data for the column is not present in
the data to be imported and there is no explicit column list present.

db2Import - Import data into a table, hierarchy, nickname or

view
Inserts data from an external file with a supported file format into a table,
hierarchy, nickname or view. The load utility is faster than this function. The load
utility, however, does not support loading data at the hierarchy level or loading
into a nickname.

Authorization
v IMPORT using the INSERT option requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on each participating table, view or nickname
– INSERT and SELECT privilege on each participating table or view
v IMPORT to an existing table using the INSERT_UPDATE option, requires one of
the following:
– sysadm
– dbadm
– CONTROL privilege on the table, view or nickname
– INSERT, SELECT, UPDATE and DELETE privilege on each participating table
or view
v IMPORT to an existing table using the REPLACE or REPLACE_CREATE option,
requires one of the following:
– sysadm
– dbadm
– CONTROL privilege on the table or view
– INSERT, SELECT, and DELETE privilege on the table or view
v IMPORT to a new table using the CREATE or REPLACE_CREATE option,
requires one of the following:
– sysadm
– dbadm

Chapter 3. Import utility 113

 – CREATETAB authority on the database and USE privilege on the table space,
as well as one of:
- IMPLICIT_SCHEMA authority on the database, if the implicit or explicit
schema name of the table does not exist
- CREATEIN privilege on the schema, if the schema name of the table refers
to an existing schema
v IMPORT to a table or a hierarchy that does not exist using the CREATE, or the
REPLACE_CREATE option, requires one of the following:
– sysadm
– dbadm
– CREATETAB authority on the database, and one of:
- IMPLICIT_SCHEMA authority on the database, if the schema name of the
table does not exist
- CREATEIN privilege on the schema, if the schema of the table exists
- CONTROL privilege on every sub-table in the hierarchy, if the
REPLACE_CREATE option on the entire hierarchy is used
v IMPORT to an existing hierarchy using the REPLACE option requires one of the
following:
– sysadm
– dbadm
– CONTROL privilege on every sub-table in the hierarchy

Required connection

Database. If implicit connect is enabled, a connection to the default database is

established.

API include file

db2ApiDf.h

API and data structure syntax

SQL_API_RC SQL_API_FN
db2Import (
db2Uint32 versionNumber,
void * pParmStruct,
struct sqlca * pSqlca);

typedef SQL_STRUCTURE db2ImportStruct

{
char *piDataFileName;
struct sqlu_media_list *piLobPathList;
struct sqldcol *piDataDescriptor;
struct sqlchar *piActionString;
char *piFileType;
struct sqlchar *piFileTypeMod;
char *piMsgFileName;
db2int16 iCallerAction;
struct db2ImportIn *piImportInfoIn;
struct db2ImportOut *poImportInfoOut;
db2int32 *piNullIndicators;
struct sqllob *piLongActionString;
} db2ImportStruct;

typedef SQL_STRUCTURE db2ImportIn

{
db2Uint64 iRowcount;
db2Uint64 iRestartcount;

114 Data Movement Utilities Guide and Reference

 db2Uint64 iSkipcount;
db2int32 *piCommitcount;
db2Uint32 iWarningcount;
db2Uint16 iNoTimeout;
db2Uint16 iAccessLevel;
db2Uint16 *piXmlParse;
struct db2DMUXmlValidate *piXmlValidate;
} db2ImportIn;

typedef SQL_STRUCTURE db2ImportOut

{
db2Uint64 oRowsRead;
db2Uint64 oRowsSkipped;
db2Uint64 oRowsInserted;
db2Uint64 oRowsUpdated;
db2Uint64 oRowsRejected;
db2Uint64 oRowsCommitted;
} db2ImportOut;

typedef SQL_STRUCTURE db2DMUXmlMapSchema

{
struct db2Char iMapFromSchema;
struct db2Char iMapToSchema;
} db2DMUXmlMapSchema;

typedef SQL_STRUCTURE db2DMUXmlValidateXds

{
struct db2Char *piDefaultSchema;
db2Uint32 iNumIgnoreSchemas;
struct db2Char *piIgnoreSchemas;
db2Uint32 iNumMapSchemas;
struct db2DMUXmlMapSchema *piMapSchemas;
} db2DMUXmlValidateXds;

typedef SQL_STRUCTURE db2DMUXmlValidateSchema

{
struct db2Char *piSchema;
} db2DMUXmlValidateSchema;

typedef SQL_STRUCTURE db2DMUXmlValidate

{
db2Uint16 iUsing;
struct db2DMUXmlValidateXds *piXdsArgs;
struct db2DMUXmlValidateSchema *piSchemaArgs;
} db2DMUXmlValidate;

SQL_API_RC SQL_API_FN
db2gImport (
db2Uint32 versionNumber,
void * pParmStruct,
struct sqlca * pSqlca);

typedef SQL_STRUCTURE db2gImportStruct

{
char *piDataFileName;
struct sqlu_media_list *piLobPathList;
struct sqldcol *piDataDescriptor;
struct sqlchar *piActionString;
char *piFileType;
struct sqlchar *piFileTypeMod;
char *piMsgFileName;
db2int16 iCallerAction;
struct db2gImportIn *piImportInfoIn;
struct dbg2ImportOut *poImportInfoOut;
db2int32 *piNullIndicators;
db2Uint16 iDataFileNameLen;
db2Uint16 iFileTypeLen;

Chapter 3. Import utility 115

 db2Uint16 iMsgFileNameLen;
struct sqllob *piLongActionString;
} db2gImportStruct;

typedef SQL_STRUCTURE db2gImportIn

{
db2Uint64 iRowcount;
db2Uint64 iRestartcount;
db2Uint64 iSkipcount;
db2int32 *piCommitcount;
db2Uint32 iWarningcount;
db2Uint16 iNoTimeout;
db2Uint16 iAccessLevel;
db2Uint16 *piXmlParse;
struct db2DMUXmlValidate *piXmlValidate;
} db2gImportIn;

typedef SQL_STRUCTURE db2gImportOut

{
db2Uint64 oRowsRead;
db2Uint64 oRowsSkipped;
db2Uint64 oRowsInserted;
db2Uint64 oRowsUpdated;
db2Uint64 oRowsRejected;
db2Uint64 oRowsCommitted;
} db2gImportOut;

db2Import API parameters

versionNumber
Input. Specifies the version and release level of the structure passed in as
the second parameter pParmStruct.
pParmStruct
Input/Output. A pointer to the db2ImportStruct structure.
pSqlca
Output. A pointer to the sqlca structure.

db2ImportStruct data structure parameters

piDataFileName
Input. A string containing the path and the name of the external input file
from which the data is to be imported.
piLobPathList
Input. Pointer to an sqlu_media_list with its media_type field set to
SQLU_LOCAL_MEDIA, and its sqlu_media_entry structure listing paths
on the client where the LOB files can be found. This parameter is not valid
when you import to a nickname.
piDataDescriptor
Input. Pointer to an sqldcol structure containing information about the
columns being selected for import from the external file. The value of the
dcolmeth field determines how the remainder of the information provided
in this parameter is interpreted by the import utility. Valid values for this
parameter are:
SQL_METH_N
Names. Selection of columns from the external input file is by
column name.

116 Data Movement Utilities Guide and Reference

 SQL_METH_P
Positions. Selection of columns from the external input file is by
column position.
SQL_METH_L
Locations. Selection of columns from the external input file is by
column location. The database manager rejects an import call with
a location pair that is invalid because of any one of the following
conditions:
v Either the beginning or the ending location is not in the range
from 1 to the largest signed 2-byte integer.
v The ending location is smaller than the beginning location.
v The input column width defined by the location pair is not
compatible with the type and the length of the target column.
A location pair with both locations equal to zero indicates that a
nullable column is to be filled with NULLs.
SQL_METH_D
Default. If piDataDescriptor is NULL, or is set to SQL_METH_D,
default selection of columns from the external input file is done. In
this case, the number of columns and the column specification
array are both ignored. For DEL, IXF, or WSF files, the first n
columns of data in the external input file are taken in their natural
order, where n is the number of database columns into which the
data is to be imported.
piActionString
Deprecated. Replaced by piLongActionString.
piLongActionString
Input. Pointer to an sqllob structure containing a 4-byte long field,
followed by an array of characters specifying an action that affects the
table.
The character array is of the form:
{INSERT | INSERT_UPDATE | REPLACE | CREATE | REPLACE_CREATE}
INTO {tname[(tcolumn-list)] |
[{ALL TABLES | (tname[(tcolumn-list)][, tname[(tcolumn-list)]])}]
[IN] HIERARCHY {STARTING tname | (tname[, tname])}
[UNDER sub-table-name | AS ROOT TABLE]}
INSERT
Adds the imported data to the table without changing the existing
table data.
INSERT_UPDATE
Adds the imported rows if their primary key values are not in the
table, and uses them for update if their primary key values are
found. This option is only valid if the target table has a primary
key, and the specified (or implied) list of target columns being
imported includes all columns for the primary key. This option
cannot be applied to views.
REPLACE
Deletes all existing data from the table by truncating the table
object, and inserts the imported data. The table definition and the
index definitions are not changed. (Indexes are deleted and
replaced if indexixf is in FileTypeMod, and FileType is SQL_IXF.) If
the table is not already defined, an error is returned.

Chapter 3. Import utility 117

 Note: If an error occurs after the existing data is deleted, that data
is lost.
This parameter is not valid when you import to a nickname.
CREATE

Note: The CREATE parameter is deprecated and may be removed

in a future release. For additional details, see “IMPORT command
options CREATE and REPLACE_CREATE are deprecated”.
Creates the table definition and the row contents using the
information in the specified PC/IXF file, if the specified table is not
defined. If the file was previously exported by DB2, indexes are
also created. If the specified table is already defined, an error is
returned. This option is valid for the PC/IXF file format only. This
parameter is not valid when you import to a nickname.
REPLACE_CREATE

Note: The REPLACE_CREATE parameter is deprecated and may

be removed in a future release. For additional details, see
“IMPORT command options CREATE and REPLACE_CREATE are
deprecated”.
Replaces the table contents using the PC/IXF row information in
the PC/IXF file, if the specified table is defined. If the table is not
already defined, the table definition and row contents are created
using the information in the specified PC/IXF file. If the PC/IXF
file was previously exported by DB2, indexes are also created. This
option is valid for the PC/IXF file format only.

Note: If an error occurs after the existing data is deleted, that data
is lost.
This parameter is not valid when you import to a nickname.
tname The name of the table, typed table, view, or object view into which
the data is to be inserted. An alias for REPLACE,
INSERT_UPDATE, or INSERT can be specified, except in the case
of an earlier server, when a qualified or unqualified name should
be specified. If it is a view, it cannot be a read-only view.
tcolumn-list
A list of table or view column names into which the data is to be
inserted. The column names must be separated by commas. If
column names are not specified, column names as defined in the
CREATE TABLE or the ALTER TABLE statement are used. If no
column list is specified for typed tables, data is inserted into all
columns within each sub-table.
sub-table-name
Specifies a parent table when creating one or more sub-tables
under the CREATE option.
ALL TABLES
An implicit keyword for hierarchy only. When importing a
hierarchy, the default is to import all tables specified in the
traversal-order-list.
HIERARCHY
Specifies that hierarchical data is to be imported.

118 Data Movement Utilities Guide and Reference

 STARTING
Keyword for hierarchy only. Specifies that the default order,
starting from a given sub-table name, is to be used.
UNDER
Keyword for hierarchy and CREATE only. Specifies that the new
hierarchy, sub-hierarchy, or sub-table is to be created under a given
sub-table.
AS ROOT TABLE
Keyword for hierarchy and CREATE only. Specifies that the new
hierarchy, sub-hierarchy, or sub-table is to be created as a
stand-alone hierarchy.
The tname and the tcolumn-list parameters correspond to the tablename
and the colname lists of SQL INSERT statements, and have the same
restrictions.
The columns in tcolumn-list and the external columns (either specified or
implied) are matched according to their position in the list or the structure
(data from the first column specified in the sqldcol structure is inserted
into the table or view field corresponding to the first element of the
tcolumn-list).
If unequal numbers of columns are specified, the number of columns
actually processed is the lesser of the two numbers. This could result in an
error (because there are no values to place in some non-nullable table
fields) or an informational message (because some external file columns are
ignored).
This parameter is not valid when you import to a nickname.
piFileType
Input. A string that indicates the format of the data within the external file.
Supported external file formats are:
SQL_ASC
Non-delimited ASCII.
SQL_DEL
Delimited ASCII, for exchange with dBase, BASIC, and the IBM
Personal Decision Series programs, and many other database
managers and file managers.
SQL_IXF
PC version of the Integration Exchange Format, the preferred
method for exporting data from a table so that it can be imported
later into the same table or into another database manager table.
SQL_WSF
Worksheet formats for exchange with Lotus Symphony and 1-2-3
programs. The WSF file type is not supported when you import to
a nickname.
piFileTypeMod
Input. A pointer to a structure containing a 2-byte long field, followed by
an array of characters that specify one or more processing options. If this
pointer is NULL, or the structure pointed to has zero characters, this action
is interpreted as selection of a default specification.
Not all options can be used with all of the supported file types. See related
link "File type modifiers for the import utility".

Chapter 3. Import utility 119

 piMsgFileName
Input. A string containing the destination for error, warning, and
informational messages returned by the utility. It can be the path and the
name of an operating system file or a standard device. If the file already
exists, it is appended to. If it does not exist, a file is created.
iCallerAction
Input. An action requested by the caller. Valid values are:
SQLU_INITIAL
Initial call. This value must be used on the first call to the API. If
the initial call or any subsequent call returns and requires the
calling application to perform some action prior to completing the
requested import operation, the caller action must be set to one of
the following:
SQLU_CONTINUE
Continue processing. This value can only be used on subsequent
calls to the API, after the initial call has returned with the utility
requesting user input (for example, to respond to an end of tape
condition). It specifies that the user action requested by the utility
has completed, and the utility can continue processing the initial
request.
SQLU_TERMINATE
Terminate processing. This value can only be used on subsequent
calls to the API, after the initial call has returned with the utility
requesting user input (for example, to respond to an end of tape
condition). It specifies that the user action requested by the utility
was not performed, and the utility is to terminate processing the
initial request.
piImportInfoIn
Input. Pointer to the db2ImportIn structure.
poImportInfoOut
Output. Pointer to the db2ImportOut structure.
piNullIndicators
Input. For ASC files only. An array of integers that indicate whether or not
the column data is nullable. The number of elements in this array must
match the number of columns in the input file; there is a one-to-one
ordered correspondence between the elements of this array and the
columns being imported from the data file. Therefore, the number of
elements must equal the dcolnum field of the piDataDescriptor parameter.
Each element of the array contains a number identifying a column in the
data file that is to be used as a null indicator field, or a zero indicating that
the table column is not nullable. If the element is not zero, the identified
column in the data file must contain a Y or an N. A Y indicates that the
table column data is NULL, and N indicates that the table column data is
not NULL.
piXmlPathList
Input. Pointer to an sqlu_media_list with its media_type field set to
SQLU_LOCAL_MEDIA, and its sqlu_media_entry structure listing paths
on the client where the XML files can be found.

120 Data Movement Utilities Guide and Reference

db2ImportIn data structure parameters
iRowcount
Input. The number of physical records to be loaded. Allows a user to load
only the first iRowcount rows in a file. If iRowcount is 0, import will
attempt to process all the rows from the file.
iRestartcount
Input. The number of records to skip before starting to insert or update
records. Functionally equivalent to iSkipcount parameter. iRestartcount
and iSkipcount parameters are mutually exclusive.
iSkipcount
Input. The number of records to skip before starting to insert or update
records. Functionally equivalent to iRestartcount.
piCommitcount
Input. The number of records to import before committing them to the
database. A commit is performed whenever piCommitcount records are
imported. A NULL value specifies the default commit count value, which
is zero for offline import and AUTOMATIC for online import.
Commitcount AUTOMATIC is specified by passing in the value
DB2IMPORT_COMMIT_AUTO.
iWarningcount
Input. Stops the import operation after iWarningcount warnings. Set this
parameter if no warnings are expected, but verification that the correct file
and table are being used is desired. If the import file or the target table is
specified incorrectly, the import utility will generate a warning for each
row that it attempts to import, which will cause the import to fail.
If iWarningcount is 0, or this option is not specified, the import operation
will continue regardless of the number of warnings issued.
iNoTimeout
Input. Specifies that the import utility will not time out while waiting for
locks. This option supersedes the locktimeout database configuration
parameter. Other applications are not affected. Valid values are:
DB2IMPORT_LOCKTIMEOUT
Indicates that the value of the locktimeout configuration parameter
is respected.
DB2IMPORT_NO_LOCKTIMEOUT
Indicates there is no timeout.
iAccessLevel
Input. Specifies the access level. Valid values are:
- SQLU_ALLOW_NO_ACCESS
Specifies that the import utility locks the table exclusively.
- SQLU_ALLOW_WRITE_ACCESS
Specifies that the data in the table should still be accessible to
readers and writers while the import is in progress.
An intent exclusive (IX) lock on the target table is acquired when the first
row is inserted. This allows concurrent readers and writers to access table
data. Online mode is not compatible with the REPLACE, CREATE, or
REPLACE_CREATE import options. Online mode is not supported in
conjunction with buffered inserts. The import operation will periodically
commit inserted data to prevent lock escalation to a table lock and to avoid

Chapter 3. Import utility 121

 running out of active log space. These commits will be performed even if
the piCommitCount parameter was not used. During each commit, import
will lose its IX table lock, and will attempt to reacquire it after the commit.
This parameter is required when you import to a nickname and
piCommitCount parameter must be specified with a valid number
(AUTOMATIC is not considered a valid option).
piXmlParse
Input. Type of parsing that should occur for XML documents. Valid values
found in the db2ApiDf header file in the include directory, are:
DB2DMU_XMLPARSE_PRESERVE_WS
Whitespace should be preserved.
DB2DMU_XMLPARSE_STRIP_WS
Whitespace should be stripped.
piXmlValidate
Input. Pointer to the db2DMUXmlValidate structure. Indicates that XML
schema validation should occur for XML documents.

db2ImportOut data structure parameters

oRowsRead
Output. Number of records read from the file during import.
oRowsSkipped
Output. Number of records skipped before inserting or updating begins.
oRowsInserted
Output. Number of rows inserted into the target table.
oRowsUpdated
Output. Number of rows in the target table updated with information from
the imported records (records whose primary key value already exists in
the table).
oRowsRejected
Output. Number of records that could not be imported.
oRowsCommitted
Output. Number of records imported successfully and committed to the
database.

db2DMUXmlMapSchema data structure parameters

iMapFromSchema
Input. The SQL identifier of the XML schema to map from.
iMapToSchema
Input. The SQL identifier of the XML schema to map to.

db2DMUXmlValidateXds data structure parameters

piDefaultSchema
Input. The SQL identifier of the XML schema that should be used for
validation when an XDS does not contain an SCH attribute.
iNumIgnoreSchemas
Input. The number of XML schemas that will be ignored during XML
schema validation if they are referred to by an SCH attribute in XDS.

122 Data Movement Utilities Guide and Reference

piIgnoreSchemas
Input. The list of XML schemas that will be ignored during XML schema
validation if they are referred to by an SCH attribute in XDS.
iNumMapSchemas
Input. The number of XML schemas that will be mapped during XML
schema validation. The first schema in the schema map pair represents a
schema that is referred to by an SCH attribute in an XDS. The second
schema in the pair represents the schema that should be used to perform
schema validation.
piMapSchemas
Input. The list of XML schema pairs, where each pair represents a mapping
of one schema to a different one. The first schema in the pair represents a
schema that is referred to by an SCH attribute in an XDS. The second
schema in the pair represents the schema that should be used to perform
schema validation.

db2DMUXmlValidateSchema data structure parameters

piSchema
Input. The SQL identifier of the XML schema to use.

db2DMUXmlValidate data structure parameters

iUsing
Input. A specification of what to use to perform XML schema validation.
Valid values found in the db2ApiDf header file in the include directory, are:
- DB2DMU_XMLVAL_XDS
Validation should occur according to the XDS. This corresponds to
the CLP "XMLVALIDATE USING XDS" clause.
- DB2DMU_XMLVAL_SCHEMA
Validation should occur according to a specified schema. This
corresponds to the CLP "XMLVALIDATE USING SCHEMA"
clause.
- DB2DMU_XMLVAL_SCHEMALOC_HINTS
Validation should occur according to schemaLocation hints found
within the XML document. This corresponds to the
"XMLVALIDATE USING SCHEMALOCATION HINTS" clause.
piXdsArgs
Input. Pointer to a db2DMUXmlValidateXds structure, representing
arguments that correspond to the CLP "XMLVALIDATE USING XDS"
clause.
This parameter applies only when the iUsing parameter in the same
structure is set to DB2DMU_XMLVAL_XDS.
piSchemaArgs
Input. Pointer to a db2DMUXmlValidateSchema structure, representing
arguments that correspond to the CLP "XMLVALIDATE USING
SCHEMA" clause.
This parameter applies only when the iUsing parameter in the same
structure is set to DB2DMU_XMLVAL_SCHEMA.

Chapter 3. Import utility 123

 db2gImportStruct data structure specific parameters
iDataFileNameLen
Input. Specifies the length in bytes of piDataFileName parameter.
iFileTypeLen
Input. Specifies the length in bytes of piFileType parameter.
iMsgFileNameLen
Input. Specifies the length in bytes of piMsgFileName parameter.

Usage notes

Before starting an import operation, you must complete all table operations and
release all locks in one of two ways:
v Close all open cursors that were defined with the WITH HOLD clause, and
commit the data changes by executing the COMMIT statement.
v Roll back the data changes by executing the ROLLBACK statement.

The import utility adds rows to the target table using the SQL INSERT statement.

The utility issues one INSERT statement for each row of data in the input file. If an
INSERT statement fails, one of two actions result:
v If it is likely that subsequent INSERT statements can be successful, a warning
message is written to the message file, and processing continues.
v If it is likely that subsequent INSERT statements will fail, and there is potential
for database damage, an error message is written to the message file, and
processing halts.

The utility performs an automatic COMMIT after the old rows are deleted during a
REPLACE or a REPLACE_CREATE operation. Therefore, if the system fails, or the
application interrupts the database manager after the table object is truncated, all
of the old data is lost. Ensure that the old data is no longer needed before using
these options.

If the log becomes full during a CREATE, REPLACE, or REPLACE_CREATE

operation, the utility performs an automatic COMMIT on inserted records. If the
system fails, or the application interrupts the database manager after an automatic
COMMIT, a table with partial data remains in the database. Use the REPLACE or
the REPLACE_CREATE option to rerun the whole import operation, or use
INSERT with the iRestartcount parameter set to the number of rows successfully
imported.

By default, automatic COMMITs are not performed for the INSERT or the
INSERT_UPDATE option. They are, however, performed if the *piCommitcount
parameter is not zero. A full log results in a ROLLBACK.

Whenever the import utility performs a COMMIT, two messages are written to the
message file: one indicates the number of records to be committed, and the other is
written after a successful COMMIT. When restarting the import operation after a
failure, specify the number of records to skip, as determined from the last
successful COMMIT.

124 Data Movement Utilities Guide and Reference

The import utility accepts input data with minor incompatibility problems (for
example, character data can be imported using padding or truncation, and numeric
data can be imported with a different numeric data type), but data with major
incompatibility problems is not accepted.

One cannot REPLACE or REPLACE_CREATE an object table if it has any

dependents other than itself, or an object view if its base table has any dependents
(including itself). To replace such a table or a view, do the following:
1. Drop all foreign keys in which the table is a parent.
2. Run the import utility.
3. Alter the table to recreate the foreign keys.

If an error occurs while recreating the foreign keys, modify the data to maintain
referential integrity.

Referential constraints and foreign key definitions are not preserved when creating
tables from PC/IXF files. (Primary key definitions are preserved if the data was
previously exported using SELECT *.)

Importing to a remote database requires enough disk space on the server for a
copy of the input data file, the output message file, and potential growth in the
size of the database.

If an import operation is run against a remote database, and the output message
file is very long (more than 60 KB), the message file returned to the user on the
client may be missing messages from the middle of the import operation. The first
30 KB of message information and the last 30 KB of message information are
always retained.

Non-default values for piDataDescriptor, or specifying an explicit list of table

columns in piLongActionString, makes importing to a remote database slower.

The database table or hierarchy must exist before data in the ASC, DEL, or WSF
file formats can be imported; however, if the table does not already exist, IMPORT
CREATE or IMPORT REPLACE_CREATE creates the table when it imports data
from a PC/IXF file. For typed tables, IMPORT CREATE can create the type
hierarchy and the table hierarchy as well.

PC/IXF import should be used to move data (including hierarchical data) between
databases. If character data containing row separators is exported to a delimited
ASCII (DEL) file and processed by a text transfer program, fields containing the
row separators will shrink or expand.

The data in ASC and DEL files is assumed to be in the code page of the client
application performing the import. PC/IXF files, which allow for different code
pages, are recommended when importing data in different code pages. If the
PC/IXF file and the import utility are in the same code page, processing occurs as
for a regular application. If the two differ, and the FORCEIN option is specified,
the import utility assumes that data in the PC/IXF file has the same code page as
the application performing the import. This occurs even if there is a conversion
table for the two code pages. If the two differ, the FORCEIN option is not
specified, and there is a conversion table, all data in the PC/IXF file will be
converted from the file code page to the application code page. If the two differ,
the FORCEIN option is not specified, and there is no conversion table, the import
operation will fail. This applies only to PC/IXF files on DB2 for AIX clients.

Chapter 3. Import utility 125

 For table objects on an 8KB page that are close to the limit of 1012 columns, import
of PC/IXF data files may cause DB2 to return an error, because the maximum size
of an SQL statement was exceeded. This situation can occur only if the columns
are of type CHAR, VARCHAR, or CLOB. The restriction does not apply to import
of DEL or ASC files.

DB2 Connect can be used to import data to DRDA servers such as DB2 for
OS/390, DB2 for VM and VSE, and DB2 for OS/400. Only PC/IXF import
(INSERT option) is supported. The restartcnt parameter, but not the commitcnt
parameter, is also supported.

When using the CREATE option with typed tables, create every sub-table defined
in the PC/IXF file; sub-table definitions cannot be altered. When using options
other than CREATE with typed tables, the traversal order list enables one to
specify the traverse order; therefore, the traversal order list must match the one
used during the export operation. For the PC/IXF file format, one need only
specify the target sub-table name, and use the traverse order stored in the file. The
import utility can be used to recover a table previously exported to a PC/IXF file.
The table returns to the state it was in when exported.

Data cannot be imported to a system table, a declared temporary table, or a

summary table.

Views cannot be created through the import utility.

On the Windows operating system:

v Importing logically split PC/IXF files is not supported.
v Importing bad format PC/IXF or WSF files is not supported.

Federated considerations

When using the db2Import API and the INSERT, UPDATE, or INSERT_UPDATE
parameters, you must ensure that you have CONTROL privilege on the
participating nickname. You must ensure that the nickname you wish to use when
doing an import operation already exists.

Import sessions - CLP examples

Example 1
The following example shows how to import information frommyfile.ixf to the
STAFF table:
db2 import from myfile.ixf of ixf messages msg.txt insert into staff

SQL3150N The H record in the PC/IXF file has product "DB2 01.00", date
"19970220", and time "140848".

SQL3153N The T record in the PC/IXF file has name "myfile",

qualifier " ", and source " ".

SQL3109N The utility is beginning to load data from file "myfile".

SQL3110N The utility has completed processing. "58" rows were read from the
input file.

SQL3221W ...Begin COMMIT WORK. Input Record Count = "58".

SQL3222W ...COMMIT of any database changes was successful.

126 Data Movement Utilities Guide and Reference

SQL3149N "58" rows were processed from the input file. "58" rows were
successfully inserted into the table. "0" rows were rejected.

Example 2
The following example shows how to import into a table that has identity
columns:

TABLE1 has 4 columns:

v C1 VARCHAR(30)
v C2 INT GENERATED BY DEFAULT AS IDENTITY
v C3 DECIMAL(7,2)
v C4 CHAR(1)

TABLE2 is the same as TABLE1, except that C2 is a GENERATED ALWAYS

identity column.

Data records in DATAFILE1 (DEL format):

"Liszt"
"Hummel",,187.43, H
"Grieg",100, 66.34, G
"Satie",101, 818.23, I

Data records in DATAFILE2 (DEL format):

"Liszt", 74.49, A
"Hummel", 0.01, H
"Grieg", 66.34, G
"Satie", 818.23, I

The following command generates identity values for rows 1 and 2, since no
identity values are supplied in DATAFILE1 for those rows. Rows 3 and 4, however,
are assigned the user-supplied identity values of 100 and 101, respectively.
db2 import from datafile1.del of del replace into table1

To import DATAFILE1 into TABLE1 so that identity values are generated for all
rows, issue one of the following commands:
db2 import from datafile1.del of del method P(1, 3, 4)
replace into table1 (c1, c3, c4)
db2 import from datafile1.del of del modified by identityignore
replace into table1

To import DATAFILE2 into TABLE1 so that identity values are generated for each
row, issue one of the following commands:
db2 import from datafile2.del of del replace into table1 (c1, c3, c4)
db2 import from datafile2.del of del modified by identitymissing
replace into table1

If DATAFILE1 is imported into TABLE2 without using any of the identity-related

file type modifiers, rows 1 and 2 will be inserted, but rows 3 and 4 will be rejected,
because they supply their own non-NULL values, and the identity column is
GENERATED ALWAYS.

Example 3
The following example shows how to import into a table that has null indicators:

TABLE1 has 5 columns:

Chapter 3. Import utility 127

 v COL1 VARCHAR 20 NOT NULL WITH DEFAULT
v COL2 SMALLINT
v COL3 CHAR 4
v COL4 CHAR 2 NOT NULL WITH DEFAULT
v COL5 CHAR 2 NOT NULL

ASCFILE1 has 6 elements:

v ELE1 positions 01 to 20
v ELE2 positions 21 to 22
v ELE5 positions 23 to 23
v ELE3 positions 24 to 27
v ELE4 positions 28 to 31
v ELE6 positions 32 to 32
v ELE6 positions 33 to 40

Data Records:
1...5....10...15...20...25...30...35...40
Test data 1 XXN 123abcdN
Test data 2 and 3 QQY wxyzN
Test data 4,5 and 6 WWN6789 Y

The following command imports records from ASCFILE1 into TABLE1:

db2 import from ascfile1 of asc
method L (1 20, 21 22, 24 27, 28 31)
null indicators (0, 0, 23, 32)
insert into table1 (col1, col5, col2, col3)

Note:
1. Since COL4 is not provided in the input file, it will be inserted into TABLE1
with its default value (it is defined NOT NULL WITH DEFAULT).
2. Positions 23 and 32 are used to indicate whether COL2 and COL3 of TABLE1
will be loaded NULL for a given row. If there is a Y in the column's null
indicator position for a given record, the column will be NULL. If there is an N,
the data values in the column's data positions of the input record (as defined in
L(........)) are used as the source of column data for the row. In this example,
neither column in row 1 is NULL; COL2 in row 2 is NULL; and COL3 in row 3
is NULL.
3. In this example, the NULL INDICATORS for COL1 and COL5 are specified as
0 (zero), indicating that the data is not nullable.
4. The NULL INDICATOR for a given column can be anywhere in the input
record, but the position must be specified, and the Y or N values must be
supplied.

128 Data Movement Utilities Guide and Reference

Chapter 4. Load utility
Load overview
The load utility is capable of efficiently moving large quantities of data into newly
created tables, or into tables that already contain data. The utility can handle most
data types, including XML, large objects (LOBs), and user-defined types (UDTs).
The load utility is faster than the import utility, because it writes formatted pages
directly into the database, while the import utility performs SQL INSERTs. The
load utility does not fire triggers, and does not perform referential or table
constraints checking (other than validating the uniqueness of the indexes).

The load process consists of four distinct phases (see Figure 3):
1. Load
During the load phase, data is loaded into the table, and index keys and table
statistics are collected, if necessary. Save points, or points of consistency, are
established at intervals specified through the SAVECOUNT parameter in the
LOAD command. Messages are generated, indicating how many input rows
were successfully loaded at the time of the save point.
2. Build
During the build phase, indexes are produced based on the index keys
collected during the load phase. The index keys are sorted during the load
phase, and index statistics are collected (if the STATISTICS USE PROFILE
option was specified, and profile indicates collecting index statistics). The
statistics are similar to those collected through the RUNSTATS command.
3. Delete
During the delete phase, the rows that caused a unique or primary key
violation are removed from the table. These deleted rows are stored in the load
exception table, if one was specified.
4. Index copy
During the index copy phase, the index data is copied from a system
temporary table space to the original table space. This will only occur if a
system temporary table space was specified for index creation during a load
operation with the READ ACCESS option specified.

Load Load Build Build Delete Delete Index Copy Index Copy
Phase Phase Phase Phase Phase Phase Phase Phase
Starts Ends Starts Ends Starts Ends Starts Ends
Figure 3. The Four Phases of the Load Process: Load, Build, Delete, and Index Copy

Note: After you invoke the load utility, you can use the LIST UTILITIES command
to monitor the progress of the load operation.

The following information is required when loading data:

v The path and the name of the input file, named pipe, or device.
v The name or alias of the target table.
v The format of the input source. This format can be DEL, ASC, PC/IXF, or
CURSOR.

© Copyright IBM Corp. 1993, 2010 129

 v Whether the input data is to be appended to the table, or is to replace the
existing data in the table.
v A message file name, if the utility is invoked through the application
programming interface (API), db2Load.

Load modes
v INSERT
In this mode, load appends input data to the table without making any changes
to the existing data.
v REPLACE
In this mode, load deletes existing data from the table and populates it with the
input data.
v RESTART
In this mode, an interrupted load is resumed. In most cases, the load is resumed
from the phase it failed in. If that phase was the load phase, the load is resumed
from the last successful consistency point.
v TERMINATE
In this mode, a failed load operation is rolled back.

The options you can specify include:

v That the data to be loaded resides on the client, if the load utility is invoked
from a remotely connected client. Note that XML and LOB data are always read
from the server, even you specify the CLIENT option.
v The method to use for loading the data: column location, column name, or
relative column position.
v How often the utility is to establish consistency points.
v The names of the table columns into which the data is to be inserted.
v Whether or not preexisting data in the table can be queried while the load
operation is in progress.
v Whether the load operation should wait for other utilities or applications to
finish using the table or force the other applications off before proceeding.
v An alternate system temporary table space in which to build the index.
v The paths and the names of the input files in which LOBs are stored.

Note: The load utility does not honor the COMPACT lob option.
v A message file name. During load operations, you can specify that message files
be created to contain the error, warning, and informational messages associated
with those operations. Specify the name of these files with the MESSAGES
parameter.

Note:
1. You can only view the contents of a message file after the operation is
finished. If you wish to view load messages while a load operation is
running, you can use the LOAD QUERY command.
2. Each message in a message file begins on a new line and contains
information provided by the DB2 message retrieval facility.
v Whether column values being loaded have implied decimal points.
v Whether the utility should modify the amount of free space available after a
table is loaded.
v Whether statistics are to be gathered during the load process. This option is only
supported if the load operation is running in REPLACE mode. Statistics are

130 Data Movement Utilities Guide and Reference

 collected according to the profile defined for the table. The profile must be
created by the RUNSTATS command before the LOAD command is executed. If
the profile does not exist and the load operation is instructed to collect statistics
according to the profile, the load will fail, and an error message will be returned.
If data is appended to a table, statistics are not collected. To collect current
statistics on an appended table, invoke the RUNSTATS utility following
completion of the load process. If gathering statistics on a table with a unique
index, and duplicate keys are deleted during the delete phase, statistics are not
updated to account for the deleted records. If you expect to have a significant
number of duplicate records, do not collect statistics during the load operation.
Instead, invoke the RUNSTATS utility following completion of the load process.
v Whether to keep a copy of the changes made. This is done to enable rollforward
recovery of the database. This option is not supported if rollforward recovery is
disabled for the database; that is, if the database configuration parameters
logarchmeth1 and logarchmeth2 are set to OFF. If no copy is made, and rollforward
recovery is enabled, the table space is left in Backup Pending state at the
completion of the load operation.
Logging is required for fully recoverable databases. The load utility almost
completely eliminates the logging associated with the loading of data. In place of
logging, you have the option of making a copy of the loaded portion of the
table. If you have a database environment that allows for database recovery
following a failure, you can do one of the following:
– Explicitly request that a copy of the loaded portion of the table be made.
– Take a backup of the table spaces in which the table resides immediately after
the completion of the load operation.
If the database configuration parameter logindexbuild is set, and if the load
operation is invoked with the COPY YES recoverability option and the
INCREMENTAL indexing option, the load logs all index modifications. The
benefit of using these options is that when you roll forward through the log
records for this load, you also recover the indexes (whereas normally the indexes
are not recovered unless the load uses the REBUILD indexing mode).
If you are loading a table that already contains data, and the database is
non-recoverable, ensure that you have a backed-up copy of the database, or the
table spaces for the table being loaded, before invoking the load utility, so that
you can recover from errors.
If you want to perform a sequence of multiple load operations on a recoverable
database, the sequence of operations will be faster if you specify that each load
operation is non-recoverable, and take a backup at the end of the load sequence,
than if you invoke each of the load operations with the COPY YES option. You
can use the NONRECOVERABLE option to specify that a load transaction is to
be marked as non-recoverable, and that it will not be possible to recover it by a
subsequent rollforward operation. The rollforward utility will skip the
transaction, and will mark the table into which data was being loaded as
"invalid". The utility will also ignore any subsequent transactions against that
table. After the rollforward operation is completed, such a table can only be
dropped (see Figure 4 on page 132). With this option, table spaces are not put in
backup pending state following the load operation, and a copy of the loaded
data does not have to be made during the load operation.

Chapter 4. Load utility 131

 full DB rollforward load to table X transaction to rollforward table X
restore begins ignored table X ignored ends dropped

(recovery time-line)

Figure 4. Non-recoverable Processing During a Roll Forward Operation

v The fully qualified path to be used when creating temporary files during a load
operation. The name is specified by the TEMPFILES PATH parameter of the
LOAD command. The default value is the database path. The path resides on
the server machine, and is accessed by the DB2 instance exclusively. Therefore,
any path name qualification given to this parameter must reflect the directory
structure of the server, not the client, and the DB2 instance owner must have
read and write permission on the path.

Privileges and authorities required to use load

Privileges enable users to create or access database resources. Authority levels
provide a method of grouping privileges and higher-level database manager
maintenance and utility operations. Together, these act to control access to the
database manager and its database objects. Users can access only those objects for
which they have the appropriate authorization; that is, the required privilege or
authority.

To load data into a table, you must have one of the following:
v SYSADM authority
v DBADM authority
v LOAD authority on the database and
– INSERT privilege on the table when the load utility is invoked in INSERT
mode, TERMINATE mode (to terminate a previous load insert operation), or
RESTART mode (to restart a previous load insert operation)
– INSERT and DELETE privilege on the table when the load utility is invoked
in REPLACE mode, TERMINATE mode (to terminate a previous load replace
operation), or RESTART mode (to restart a previous load replace operation)
– INSERT privilege on the exception table, if such a table is used as part of the
load operation.
– SELECT privilege on SYSCAT.TABLES is required in some cases where LOAD
queries the catalog tables.

Since all load processes (and all DB2 server processes, in general), are owned by
the instance owner, and all of these processes use the identification of the instance
owner to access needed files, the instance owner must have read access to input
data files. These input data files must be readable by the instance owner, regardless
of who invokes the command.

If the REPLACE option is specified, the session authorization ID must have the
authority to drop the table.

132 Data Movement Utilities Guide and Reference

 On Windows, and Windows.NET operating systems where DB2 is running as a
Windows service, if you are loading data from files that reside on a network drive,
you must configure the DB2 service to run under a user account that has read
access to these files.

Note:
v To load data into a table that has protected columns, the session authorization
ID must have LBAC credentials that allow write access to all protected columns
in the table.
v To load data into a table that has protected rows, the session authorization ID
must have been granted a security label for write access that is part of the
security policy protecting the table.

LOAD authority
Users having LOAD authority at the database level, as well as INSERT privilege on
a table, can use the LOAD command to load data into a table.

Users having LOAD authority at the database level, as well as INSERT privilege on
a table, can LOAD RESTART or LOAD TERMINATE if the previous load operation
is a load to insert data.

Users having LOAD authority at the database level, as well as the INSERT and
DELETE privileges on a table, can use the LOAD REPLACE command.

If the previous load operation was a load replace, the DELETE privilege must also
have been granted to that user before the user can LOAD RESTART or LOAD
TERMINATE.

If the exception tables are used as part of a load operation, the user must have
INSERT privilege on the exception tables.

The user with this authority can perform QUIESCE TABLESPACES FOR TABLE,
RUNSTATS, and LIST TABLESPACES commands.

Loading data
The load utility is capable of efficiently moving large quantities of data into newly
created tables, or into tables that already contain data.

Before you begin

Before invoking the load utility, you must be connected to (or be able to implicitly
connect to) the database into which the data will be loaded. Since the utility will
issue a COMMIT statement, you should complete all transactions and release all
locks by issuing either a COMMIT or a ROLLBACK statement before invoking the
load utility. Data is loaded in the sequence that appears in the input file, except
when using multidimensional clustering (MDC) tables, partitioned tables, or the
anyorder file type modifier. If a particular sequence is desired, sort the data before
attempting a load operation. If clustering is required, the data should be sorted on
the clustering index prior to loading. When loading data into multidimensional
clustered tables (MDC), sorting is not required prior to the load operation, and
data is clustered according to the MDC table definition. When loading data into
partitioned tables, sorting is not required prior to the load operation, and data is
partitioned according to the table definition.

Chapter 4. Load utility 133

 About this task

These are some of the restrictions that apply to the load utility (i.e., this list is not
exhaustive):
v Loading data into nicknames is not supported.
v Loading data into typed tables, or tables with structured type columns, is not
supported.
v Loading data into declared temporary tables is not supported.
v XML data can only be read from the server side; if you want to have the XML
files read from the client, use the import utility.
v You cannot create or drop tables in a table space that is in Backup Pending state.
v You cannot load data into a database accessed through DB2 Connect or a server
level prior to DB2 Version 2. Options that are only available with the current
cannot be used with a server from the previous release.
v If an error occurs during a LOAD REPLACE operation, the original data in the
table is lost. Retain a copy of the input data to allow the load operation to be
restarted.
v Triggers are not activated on newly loaded rows. Business rules associated with
triggers are not enforced by the load utility.
v Loading encrypted data is not supported.

These are some of the restrictions that apply to the load utility when loading into a
partitioned table (i.e., this list is not exhaustive):
v Consistency points are not supported when the number of partitioning agents is
greater than one.
v Loading data into a subset of data partitions while keeping the remaining data
partitions fully online is not supported.
v The exception table used by a load operation or a set integrity pending
operation cannot be partitioned.
v A unique index cannot be rebuilt when the load utility is running in insert mode
or restart mode, and the load target table has any detached dependents.

The load utility can be invoked through the command line processor (CLP), the
Load wizard in the Control Center, or an application programming interface (API)
db2Load.

Using the Load wizard

Procedure
1. From the Control Center, expand the object tree until you find the Tables folder.
2. Click on the Tables folder. Any existing tables are displayed in the pane on the
right side of the window (the contents pane).
3. In the contents pane, right-click on the table you want, and select Load from
the pop-up menu. The Load wizard opens.
4. Specify the required information on each page of the wizard to successfully
load your data.

Results

Detailed information about the Load wizard is provided through its online help
facility.

134 Data Movement Utilities Guide and Reference

 Example

Issuing a LOAD command by using the CLP

The following is an example of a LOAD command issued through the CLP:

db2 load from stafftab.ixf of ixf messages staff.msgs
insert into userid.staff copy yes use tsm data buffer 4000

In this example:
v Any warning or error messages are placed in the staff.msgs file.
v A copy of the changes made is stored in Tivoli® Storage Manager (TSM).
v Four thousand pages of buffer space are to be used during the load operation.

The following is another example of a LOAD command issued through the CLP:
db2 load from stafftab.ixf of ixf messages staff.msgs
tempfiles path /u/myuser replace into staff

In this example:
v The table data is being replaced.
v The TEMPFILES PATH parameter is used to specify /u/myuser as the server path
into which temporary files will be written.

Note: These examples use relative path names for the load input file. Relative path
names are only allowed on calls from a client on the same database partition as the
database. The use of fully qualified path names is recommended.

What to do next

After you invoke the load utility, you can use the LIST UTILITIES command to
monitor the progress of the load operation. In the case of a load operation
performed in either INSERT mode, REPLACE mode, or RESTART mode, detailed
progress monitoring support is available. Issue the LIST UTILITIES command with
the SHOW DETAILS option to view detailed information about the current load
phase. Details are not available for a load operation performed in TERMINATE
mode. The LIST UTILITIES command will simply show that a load terminate
utility is currently running.

A load operation maintains unique constraints, range constraints for partitioned

tables, generated columns, and LBAC security rules. For all other constraints, the
table is placed in the Set Integrity Pending state at the beginning of a load
operation. After the load operation is complete, the SET INTEGRITY statement
must be used to take the table out of Set Integrity Pending state.

Loading XML data

The load utility can be used for the efficient movement of large volumes of XML
data into tables.

When loading data into an XML table column, you can use the XML FROM option
to specify the paths of the input XML data file or files. For example, to load data
from an XML file "/home/user/xmlpath/xmlfile1.xml" you could use the
following command:
LOAD FROM data1.del OF DEL XML FROM /home/user/xmlpath INSERT INTO USER.T1

Chapter 4. Load utility 135

 The delimited ASCII input file "data1.del" contains an XML data specifier (XDS)
that describes the location of the XML data to load. For example, the following
XDS describes an XML document at offset 123 bytes in file "xmldata.ext" that is 456
bytes in length:
<XDS FIL=’xmldata.ext’ OFF=’123’ LEN=’456’ />

Validating inserted documents against schemas

The XMLVALIDATE option allows XML documents to be validated against XML

schemas as they are loaded. In the following example, incoming XML documents
are validated against the schema identified by the XDS in the delimited ASCII
input file "data2.del":
LOAD FROM data2.del OF DEL XML FROM /home/user/xmlpath XMLVALIDATE
USING XDS INSERT INTO USER.T2

In this case, the XDS contains an SCH attribute with the fully qualified SQL
identifier of the XML schema to use for validation, "S1.SCHEMA_A":
<XDS FIL=’xmldata.ext’ OFF=’123’ LEN=’456’ SCH=’S1.SCHEMA_A’ />

Specifying parse options

You can use the XMLPARSE option to specify whether whitespace in the loaded
XML documents is preserved or stripped. In the following example, all loaded
XML documents are validated against the schema with SQL identifier
"S2.SCHEMA_A" and these documents are parsed with whitespace preserved:
LOAD FROM data2.del OF DEL XML FROM /home/user/xmlpath XMLPARSE PRESERVE
WHITESPACE XMLVALIDATE USING SCHEMA S2.SCHEMA_A INSERT INTO USER.T1

Load considerations for partitioned tables

All of the existing load features are supported when the target table is partitioned
with the exception of the following general restrictions:
v Consistency points are not supported when the number of partitioning agents is
greater than one.
v Loading data into a subset of data partitions while the remaining data partitions
remain fully online is not supported.
v The exception table used by a load operation cannot be partitioned.
v A unique index cannot be rebuilt when the load utility is running in insert mode
or restart mode, and the load target table has any detached dependents.
v Similar to loading MDC tables, exact ordering of input data records is not
preserved when loading partitioned tables. Ordering is only maintained within
the cell or data partition.
v Load operations utilizing multiple formatters on each database partition only
preserve approximate ordering of input records. Running a single formatter on
each database partition, groups the input records by cell or table partitioning
key. To run a single formatter on each database partition, explicitly request
CPU_PARALLELISM of 1.

General load behavior

The load utility inserts data records into the correct data partition. There is no
requirement to use an external utility, such as a splitter, to partition the input data
before loading.

The load utility does not access any detached or attached data partitions. Data is
inserted into visible data partitions only. Visible data partitions are neither attached

136 Data Movement Utilities Guide and Reference

nor detached. In addition, a load replace operation does not truncate detached or
attached data partitions. Since the load utility acquires locks on the catalog system
tables, the load utility waits for any uncommitted ALTER TABLE transactions.
Such transactions acquire an exclusive lock on the relevant rows in the catalog
tables, and the exclusive lock must terminate before the load operation can
proceed. This means that there can be no uncommitted ALTER TABLE ...ATTACH,
DETACH, or ADD PARTITION transactions while load operation is running. Any
input source records destined for an attached or detached data partition are
rejected, and can be retrieved from the exception table if one is specified. An
informational message is written to the message file to indicate some of the target
table data partitions were in an attached or detached state. Locks on the relevant
catalog table rows corresponding to the target table prevent users from changing
the partitioning of the target table by issuing any ALTER TABLE ...ATTACH,
DETACH, or ADD PARTITION operations while the load utility is running.

Handling of invalid rows

When the load utility encounters a record that does not belong to any of the visible
data partitions the record is rejected and the load utility continues processing. The
number of records rejected because of the range constraint violation is not
explicitly displayed, but is included in the overall number of rejected records.
Rejecting a record because of the range violation does not increase the number of
row warnings. A single message (SQL0327N) is written to the load utility message
file indicating that range violations are found, but no per-record messages are
logged. In addition to all columns of the target table, the exception table includes
columns describing the type of violation that had occurred for a particular row.
Rows containing invalid data, including data that cannot be partitioned, are
written to the dump file.

Because exception table inserts are expensive, you can control which constraint
violations are inserted into the exception table. For instance, the default behavior of
the load utility is to insert rows that were rejected because of a range constraint or
unique constraint violation, but were otherwise valid, into the exception table. You
can turn off this behavior by specifying, respectively, NORANGEEXC or
NOUNIQUEEXC with the FOR EXCEPTION clause. If you specify that these
constraint violations should not be inserted into the exception table, or you do not
specify an exception table, information about rows violating the range constraint or
unique constraint is lost.

History file
If the target table is partitioned, the corresponding history file entry does not
include a list of the table spaces spanned by the target table. A different operation
granularity identifier ('R' instead of 'T') indicates that a load operation ran against
a partitioned table.

Terminating a load operation

Terminating a load replace completely truncates all visible data partitions,
terminating a load insert truncates all visible data partitions to their lengths before
the load. Indexes are invalidated during a termination of an ALLOW READ
ACCESS load operation that failed in the load copy phase. Indexes are also
invalidated when terminating an ALLOW NO ACCESS load operation that
touched the index (It is invalidated because the indexing mode is rebuild, or a key
was inserted during incremental maintenance leaving the index in an inconsistent
state). Loading data into multiple targets does not have any effect on load recovery
operations except for the inability to restart the load operation from a consistency

Chapter 4. Load utility 137

 point taken during the load phase In this case, the SAVECOUNT load option is
ignored if the target table is partitioned. This behavior is consistent with loading
data into a MDC target table.

Generated columns
If a generated column is in any of the partitioning, dimension, or distribution keys,
the generatedoverride file type modifier is ignored and the load utility generates
values as if the generatedignore file type modifier is specified. Loading an
incorrect generated column value in this case can place the record in the wrong
physical location, such as the wrong data partition, MDC block or database
partition. For example, once a record is on a wrong data partition, set integrity has
to move it to a different physical location, which cannot be accomplished during
online set integrity operations.

Data availability
The current ALLOW READ ACCESS load algorithm extends to partitioned tables.
An ALLOW READ ACCESS load operation allows concurrent readers to access the
whole table, including both loading and non-loading data partitions.

Data partition states

After a successful load, visible data partitions might change to either or both Set
Integrity Pending or Read Access Only table state, under certain conditions. Data
partitions might be placed in these states if there are constraints on the table which
the load operation cannot maintain. Such constraints might include check
constraints and detached materialized query tables. A failed load operation leaves
all visible data partitions in the Load Pending table state.

Error isolation
Error isolation at the data partition level is not supported. Isolating the errors
means continuing a load on data partitions that did not run into an error and
stopping on data partitions that did run into an error. Errors can be isolated
between different database partitions, but the load utility cannot commit
transactions on a subset of visible data partitions and roll back the remaining
visible data partitions.

Other considerations
v Incremental indexing is not supported if any of the indexes are marked invalid.
An index is considered invalid if it requires a rebuild or if detached dependents
require validation with the SET INTEGRITY statement.
v Loading into tables partitioned using any combination of partitioned by range,
distributed by hash, or organized by dimension algorithms is also supported.
v For log records which include the list of object and table space IDs affected by
the load, the size of these log records (LOAD START and COMMIT (PENDING
LIST)) could grow considerably and hence reduce the amount of active log space
available to other applications.
v When a table is both partitioned and distributed, a partitioned database load
might not affect all database partitions. Only the objects on the output database
partitions are changed.
v During a load operation, memory consumption for partitioned tables increases
with the number of tables. Note, that the total increase is not linear as only a
small percentage of the overall memory requirement is proportional to the
number of data partitions.

138 Data Movement Utilities Guide and Reference

LBAC-protected data load considerations
For a successful load operation into a table with protected rows, you must have
LBAC (label-based access control) credentials. You must also provide a valid
security label, or a security label that can be converted to a valid label, for the
security policy currently associated with the target table.

If you do not have valid LBAC credentials, the load fails and an error (SQLSTATE
42512) is returned. In cases where the input data does not contain a security label
or that security label is not in its internal binary format, you can use several file
type modifiers to allow your load to proceed.

When you load data into a table with protected rows, the target table has one
column with a data type of DB2SECURITYLABEL. If the input row of data does
not contain a value for that column, that row is rejected unless the usedefaults file
type modifier is specified in the load command, in which case the security label
you hold for write access from the security policy protecting the table is used. If
you do not hold a security label for write access, the row is rejected and processing
continues on to the next row.

When you load data into a table that has protected rows and the input data does
include a value for the column with a data type of DB2SECURITYLABEL, the
same rules are followed as when you insert data into that table. If the security
label protecting the row being loaded (the one in that row of the data file) is one
that you are able to write to, then that security label is used to protect the row. (In
other words, it is written to the column that has a data type of
DB2SECURITYLABEL.) If you are not able to write to a row protected by that
security label, what happens depends on how the security policy protecting the
source table was created:
v If the CREATE SECURITY POLICY statement that created the policy included
the option RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL, the row
is rejected.
v If the CREATE SECURITY POLICY statement did not include the option or if it
instead included the OVERRIDE NOT AUTHORIZED WRITE SECURITY
LABEL option, the security label in the data file for that row is ignored and the
security label you hold for write access is used to protect that row. No error or
warning is issued in this case. If you do not hold a security label for write
access, the row is rejected and processing continues on to the next row.

Delimiter considerations
When loading data into a column with a data type of DB2SECURITYLABEL, the
value in the data file is assumed by default to be the actual bytes that make up the
internal representation of that security label. However, some raw data might
contain newline characters which could be misinterpreted by the LOAD command
as delimiting the row. If you have this problem, use the delprioritychar file type
modifier to ensure that the character delimiter takes precedence over the row
delimiter. When you use delprioritychar, any record or column delimiters that
are contained within character delimiters are not recognized as being delimiters.
Using the delprioritychar file type modifier is safe to do even if none of the
values contain a newline character, but it does slow the load down slightly.

If the data being loaded is in ASC format, you might have to take an extra step in
order to prevent any trailing white space from being included in the loaded
security labels and security label names. ASCII format uses column positions as
delimiters, so this might occur when loading into variable-length fields. Use the
striptblanks file type modifier to truncate any trailing blank spaces.

Chapter 4. Load utility 139

 Nonstandard security label values
You can also load data files in which the values for the security labels are strings
containing the values of the components in the security label, for example,
S:(ALPHA,BETA). To do so you must use the file type modifier seclabelchar.
When you use seclabelchar, a value for a column with a data type of
DB2SECURITYLABEL is assumed to be a string constant containing the security
label in the string format for security labels. If a string is not in the proper format,
the row is not inserted and a warning (SQLSTATE 01H53) is returned. If the string
does not represent a valid security label that is part of the security policy
protecting the table, the row is not inserted and a warning (SQLSTATE 01H53) is
returned.

You can also load a data file in which the values of the security label column are
security label names. To load this sort of file you must use the file type modifier
seclabelname. When you use seclabelname, all values for columns with a data type
of DB2SECURITYLABEL are assumed to be string constants containing the names
of existing security labels. If no security label exists with the indicated name for
the security policy protecting the table, the row is not loaded and a warning
(SQLSTATE 01H53) is returned.

Rejected rows
Rows that are rejected during the load are sent to either a dumpfile or an
exception table (if they are specified in the LOAD command), depending on the
reason why the rows were rejected. Rows that are rejected due to parsing errors
are sent to the dumpfile. Rows that violate security policies are sent to the
exception table.

Examples

For all examples, the input data file myfile.del is in DEL format. All are loading
data into a table named REPS, which was created with this statement:
create table reps (row_label db2securitylabel,
id integer,
name char(30))
security policy data_access_policy

For this example, the input file is assumed to contain security labels in the default
format:
db2 load from myfile.del of del modified by delprioritychar insert into reps

For this example, the input file is assumed to contain security labels in the security
label string format:
db2 load from myfile.del of del modified by seclabelchar insert into reps

For this example, the input file is assumed to contain security labels names for the
security label column:
db2 load from myfile.del of del modified by seclabelname insert into reps

Identity column load considerations

The load utility can be used to load data into a table containing an identity column
whether or not the input data has identity column values.

If no identity-related file type modifiers are used, the utility works according to the
following rules:

140 Data Movement Utilities Guide and Reference

v If the identity column is GENERATED ALWAYS, an identity value is generated
for a table row whenever the corresponding row in the input file is missing a
value for the identity column, or a NULL value is explicitly given. If a
non-NULL value is specified for the identity column, the row is rejected
(SQL3550W).
v If the identity column is GENERATED BY DEFAULT, the load utility makes use
of user-supplied values, if they are provided; if the data is missing or explicitly
NULL, a value is generated.

The load utility does not perform any extra validation of user-supplied identity
values beyond what is normally done for values of the identity column's data type
(that is, SMALLINT, INT, BIGINT, or DECIMAL). Duplicate values are not
reported.

In most cases the load utility cannot guarantee that identity column values are
assigned to rows in the same order that these rows appear in the data file. Because
the assignment of identity column values is managed in parallel by the load utility,
those values are assigned in arbitrary order. The exceptions to this are as follows:
v In single-partition databases, rows are not processed in parallel when
CPU_PARALLELISM is set to 1. In this case, identity column values are
implicitly assigned in the same order that rows appear in the data file
parameter.
v In multi-partition databases, identity column values are assigned in the same
order that the rows appear in the data file if the identity column is in the
distribution key and if there is a single partitioning agent (that is, if you do not
specify multiple partitioning agents or the anyorder file type modifier).

When loading a table in a partitioned database where the table has an identity
column in the partitioning key and the identityoverride modifier is not specified,
the SAVECOUNT option cannot be specified. When there is an identity column in
the partitioning key and identity values are being generated, restarting a load from
the load phase on at least one database partition requires restarting the whole load
from the beginning of the load phase, which means that there can't be any
consistency points.

Note: A load RESTART operation is not permitted if all of the following criteria
are met:
v The table being loaded is in a partitioned database environment, and it contains
at least one identity column that is either in the distribution key or is referenced
by a generated column that is part of the distribution key.
v The identityoverride modifier is not specified.
v The previous load operation that failed included loading database partitions that
failed after the load phase.
A load TERMINATE or REPLACE operation should be issued instead.

There are three mutually exclusive ways you can simplify the loading of data into
tables that contain an identity column: the identitymissing, the identityignore,
and the identityoverride file type modifiers.

Loading data without identity columns

The identitymissing modifier makes loading a table with an identity column more
convenient if the input data file does not contain any values (not even NULLS) for
the identity column. For example, consider a table defined with the following SQL
statement:

Chapter 4. Load utility 141

 create table table1 (c1 varchar(30),
c2 int generated by default as identity,
c3 decimal(7,2),
c4 char(1))

If you want to load TABLE1 with data from a file (load.del) that has been
exported from a table that does not have an identity column, see the following
example:
Robert, 45.2, J
Mike, 76.9, K
Leo, 23.4, I

One way to load this file would be to explicitly list the columns to be loaded
through the LOAD command as follows:
db2 load from load.del of del replace into table1 (c1, c3, c4)

For a table with many columns, however, this syntax might be cumbersome and
prone to error. An alternate method of loading the file is to use the
identitymissing file type modifier as follows:
db2 load from load.del of del modified by identitymissing
replace into table1

This command would result in the three columns in the data file being loaded into
c1, c3, and c4 of TABLE1. A value will be generated for each row in c2.

Loading data with identity columns

The identityignore modifier indicates to the load utility that even though the
input data file contains data for the identity column, the data should be ignored,
and an identity value should be generated for each row. For example, a user might
want to load TABLE1, as defined above, from a data file (load.del) containing the
following data:
Robert, 1, 45.2, J
Mike, 2, 76.9, K
Leo, 3, 23.4, I

If the user-supplied values of 1, 2, and 3 are not used for the identity column, you
can issue the following LOAD command:
db2 load from load.del of del method P(1, 3, 4)
replace into table1 (c1, c3, c4)

Again, this approach might be cumbersome and prone to error if the table has
many columns. The identityignore modifier simplifies the syntax as follows:
db2 load from load.del of del modified by identityignore
replace into table1

Loading data with user-supplied values

The identityoverride modifier is used for loading user-supplied values into a
table with a GENERATED ALWAYS identity column. This can be quite useful
when migrating data from another database system, and the table must be defined
as GENERATED ALWAYS, or when loading a table from data that was recovered
using the DROPPED TABLE RECOVERY option on the ROLLFORWARD
DATABASE command. When this modifier is used, any rows with no data (or
NULL data) for the identity column are rejected (SQL3116W). You should also note
that when using this modifier, it is possible to violate the uniqueness property of
GENERATED ALWAYS columns.In this situation, perform a load TERMINATE
operation, followed by a subsequent load INSERT or REPLACE operation.

142 Data Movement Utilities Guide and Reference

Generated column load considerations
You can load data into a table containing (nonidentity) generated columns whether
or not the input data has generated column values. The load utility generates the
column values.

If no generated column-related file type modifiers are used, the load utility works
according to the following rules:
v Values are created for generated columns when the corresponding row of the
data file is missing a value for the column or a NULL value is supplied. If a
non-NULL value is supplied for a generated column, the row is rejected
(SQL3550W).
v If a NULL value is created for a generated column that is not nullable, the entire
row of data is rejected (SQL0407N). This could occur if, for example, a
non-nullable generated column is defined as the sum of two table columns that
include NULL values in the data file.

There are three mutually exclusive ways you can simplify the loading of data into
tables that contain a generated column: the generatedmissing, the
generatedignore, and the generatedoverride file type modifiers.

Loading data without generated columns

The generatedmissing modifier makes loading a table with generated columns
more convenient if the input data file does not contain any values (not even
NULLS) for all generated columns present in the table. For example, consider a
table defined with the following SQL statement:
CREATE TABLE table1 (c1 INT,
c2 INT,
g1 INT GENERATED ALWAYS AS (c1 + c2),
g2 INT GENERATED ALWAYS AS (2 * c1),
c3 CHAR(1))

If you want to load TABLE1 with data from a file (load.del) that has been
exported from a table that does not have any generated columns, see the following
example:
1, 5, J
2, 6, K
3, 7, I

One way to load this file would be to explicitly list the columns to be loaded
through the LOAD command as follows:
DB2 LOAD FROM load.del of del REPLACE INTO table1 (c1, c2, c3)

For a table with many columns, however, this syntax might be cumbersome and
prone to error. An alternate method of loading the file is to use the
generatedmissing file type modifier as follows:
DB2 LOAD FROM load.del of del MODIFIED BY generatedmissing
REPLACE INTO table1

This command will result in the three columns of data file being loaded into c1, c2,
and c3 of TABLE1. Due to the generatedmissing modifier, values for columns g1
and g2 of TABLE1 will be generated automatically and will not map to any of the
data file columns.

Loading data with generated columns

The generatedignore modifier indicates to the load utility that even though the

Chapter 4. Load utility 143

 input data file contains data for all generated columns present in the target table,
the data should be ignored, and the computed values should be loaded into each
generated column. For example, if you want to load TABLE1, as defined above,
from a data file (load.del) containing the following data:
1, 5, 10, 15, J
2, 6, 11, 16, K
3, 7, 12, 17, I

The user-supplied, non-NULL values of 10, 11, and 12 (for g1), and 15, 16, and 17
(for g2) result in the row being rejected (SQL3550W) if no generated-column
related file type modifiers are used. To avoid this, the user could issue the
following LOAD command:
DB2 LOAD FROM load.del of del method P(1, 2, 5)
REPLACE INTO table1 (c1, c2, c3)

Again, this approach might be cumbersome and prone to error if the table has
many columns. The generatedignore modifier simplifies the syntax as follows:
DB2 LOAD FROM load.del of del MODIFIED BY generatedignore
REPLACE INTO table1

This command will result in the columns of data file being loaded into c1 (with the
data 1, 2, 3), c2 (with the data 5,6,7), and c3 (with the data J, K, I) of TABLE1. Due
to the generatedignore modifier, values for columns g1 and g2 of TABLE1 will be
generated automatically and the data file columns (10, 11, 12 and 15, 16, 17) will be
ignored.

Loading data with user-supplied values

The generatedoverride modifier is used for loading user-supplied values into a
table with generated columns. This can be useful when migrating data from
another database system, or when loading a table from data that was recovered
using the RECOVER DROPPED TABLE option of the ROLLFORWARD
DATABASE command. When this modifier is used, any rows with no data (or
NULL data) for non-nullable generated columns are rejected (SQL3116W).

When this modifier is used, the table is placed in the Set Integrity Pending state
after the load operation. To take the table out of Set Integrity Pending state
without verifying the user-supplied values, issue the following command:
SET INTEGRITY FOR table-name GENERATED COLUMN IMMEDIATE
UNCHECKED

To take the table out of the Set Integrity Pending state and force verification of the
user-supplied values, issue the following command:
SET INTEGRITY FOR table-name IMMEDIATE CHECKED

If a generated column is in any of the partitioning, dimension, or distribution keys,

the generatedoverride modifier is ignored and the load utility generates values as
if the generatedignore modifier is specified. This is done to avoid a scenario where
a user-supplied generated column value conflicts with its generated column
definition, which would place the resulting record in the wrong physical location,
such as the wrong data partition, MDC block, or database partition.

Note: There is one case where load does NOT support generating column values:
when one of the generated column expressions contains a user-defined function
that is FENCED. If you attempt to load into such a table the load operation fails.
However, you can provide your own values for these types of generated columns
by using the generatedoverride file type modifier.

144 Data Movement Utilities Guide and Reference

 Considerations for using a Version 7 or earlier client with a Version 8 or later
server
If you initiate a load operation between a Version 7 or earlier client and a Version 8
or later server, the load utility places tables with generated columns in the Set
Integrity Pending state. If a table has been placed in Set Integrity Pending state
because a Version 7 or earlier client was used to load data into a table with
generated columns, issue the following statement to remove that state and force
the generation of values:
SET INTEGRITY FOR table-name IMMEDIATE CHECKED FORCE GENERATED;

Moving data using the CURSOR file type

By specifying the CURSOR file type when using the LOAD command, you can
load the results of an SQL query directly into a target table without creating an
intermediate exported file.

Additionally, you can load data from another database by referencing a nickname
within the SQL query, by using the DATABASE option within the DECLARE
CURSOR statement, or by using the sqlu_remotefetch_entry media entry when
using the API interface.

There are three approaches for moving data using the CURSOR file type. The first
approach uses the Command Line Processor (CLP), the second the API, and the
third uses the ADMIN_CMD procedure. The key differences between the CLP and
the ADMIN_CMD procedure are outlined in the following table.
Table 26. Differences between the CLP and ADMIN_CMD procedure.
Differences CLP ADMIN_CMD_procedure
Syntax The query statement as well The query statement as well
as the source database used as the source database used
by the cursor are defined by the cursor is defined
outside of the LOAD within the LOAD command
command using a DECLARE using the LOAD from
CURSOR statement. (DATABASE database-alias
query-statement)

Chapter 4. Load utility 145

 Table 26. Differences between the CLP and ADMIN_CMD procedure. (continued)
Differences CLP ADMIN_CMD_procedure
User authorization for If the data is in a different If the data is in a different
accessing a different database database than the one you database than the one you
currently connect to, the are currently connected to,
DATABASE keyword must the DATABASE keyword
be used in the DECLARE must be used in the LOAD
CURSOR statement. You can command before the query
specify the user id and statement. The user id and
password in the same password explicitly specified
statement as well. If the user for the source database
id and password are not connection are required to
specified in the DECLARE access the target database.
CURSOR statement, the user You cannot specify a userid
id and password explicitly or password for the source
specified for the source database. Therefore, if no
database connection are used userid and password were
to access the target database. specified when the
connection to the target
database was made, or the
userid and password
specified cannot be used to
authenticate against the
source database, the
ADMIN_CMD procedure
cannot be used to perform
the load.

To execute a LOAD FROM CURSOR operation from the CLP, a cursor must first be
declared against an SQL query. Once this is declared, you can issue the LOAD
command using the declared cursor's name as the cursorname and CURSOR as the
file type.

For example:
1. Suppose a source and target table both reside in the same database with the
following definitions:
Table ABC.TABLE1 has 3 columns:
v ONE INT
v TWO CHAR(10)
v THREE DATE
Table ABC.TABLE2 has 3 columns:
v ONE VARCHAR
v TWO INT
v THREE DATE
Executing the following CLP commands will load all the data from
ABC.TABLE1 into ABC.TABLE2:
DECLARE mycurs CURSOR FOR SELECT TWO, ONE, THREE FROM abc.table1
LOAD FROM mycurs OF cursor INSERT INTO abc.table2

Note: The above example shows how to load from an SQL query through the
CLP. However, loading from an SQL query can also be accomplished through
the db2Load API. Define the piSourceList of the sqlu_media_list structure to use
the sqlu_statement_entry structure and SQLU_SQL_STMT media type and define
the piFileType value as SQL_CURSOR.

146 Data Movement Utilities Guide and Reference

2. Suppose the source and target tables reside in different databases with the
following definitions:

Table ABC.TABLE1 in database 'dbsource' has 3 columns:

v ONE INT
v TWO CHAR(10)
v THREE DATE

Table ABC.TABLE2 in database 'dbtarget' has 3 columns:

v ONE VARCHAR
v TWO INT
v THREE DATE

Provided that you have enabled federation and cataloged the data source
('dsdbsource'), you can declare a nickname against the source database, then
declare a cursor against this nickname, and invoke the LOAD command with the
FROM CURSOR option, as demonstrated in the following example:
CREATE NICKNAME myschema1.table1 FOR dsdbsource.abc.table1
DECLARE mycurs CURSOR FOR SELECT TWO,ONE,THREE FROM myschema1.table1
LOAD FROM mycurs OF cursor INSERT INTO abc.table2

Or, you can use the DATABASE option of the DECLARE CURSOR statement, as
demonstrated in the following example:
DECLARE mycurs CURSOR DATABASE dbsource USER dsciaraf USING mypasswd
FOR SELECT TWO,ONE,THREE FROM abc.table1
LOAD FROM mycurs OF cursor INSERT INTO abc.table2

Using the DATABASE option of the DECLARE CURSOR statement (also known as
the remotefetch media type when using the Load API) has some benefits over the
nickname approach:

Performance

Fetching of data using the remotefetch media type is tightly integrated within a
load operation. There are fewer layers of transition to fetch a record compared to
the nickname approach. Additionally, when source and target tables are distributed
identically in a multi-partition database, the load utility can parallelize the fetching
of data, which can further improve performance.

Ease of use

There is no need to enable federation, define a remote datasource, or declare a

nickname. Specifying the DATABASE option (and the USER and USING options if
necessary) is all that is required.

While this method can be used with cataloged databases, the use of nicknames
provides a robust facility for fetching from various data sources which cannot
simply be cataloged.

To support this remotefetch functionality, the load utility makes use of

infrastructure which supports the SOURCEUSEREXIT facility. The load utility
spawns a process which executes as an application to manage the connection to the
source database and perform the fetch. This application is associated with its own
transaction and is not associated with the transaction under which the load utility
is running.

Chapter 4. Load utility 147

 Note:
1. The previous example shows how to load from an SQL query against a
cataloged database through the CLP using the DATABASE option of the
DECLARE CURSOR statement. However, loading from an SQL query against a
cataloged database can also be done through the db2Load API, by defining the
piSourceList and piFileTypevalues of the db2LoadStruct structure to use the
sqlu_remotefetch_entry media entry and SQLU_REMOTEFETCH media type
respectively.
2. As demonstrated in the previous example, the source column types of the SQL
query do not need to be identical to their target column types, although they
do have to be compatible.

Restrictions

When loading from a cursor defined using the DATABASE option (or equivalently
when using the sqlu_remotefetch_entry media entry with the db2Load API), the
following restrictions apply:
1. The SOURCEUSEREXIT option cannot be specified concurrently.
2. The METHOD N option is not supported.
3. The usedefaults file type modifier is not supported.

Propagating dependent immediate staging tables

If the table being loaded is an underlying table of a staging table with the
immediate propagate attribute, and if the load operation is done in insert mode,
the subsequent propagation into the dependent immediate staging tables is
incremental.

During incremental propagation, the rows corresponding to the appended rows in

the underlying tables are appended into the staging tables. Incremental
propagation is faster in the case of large underlying tables with small amounts of
appended data. Performance is also improved if the staging table is used to refresh
its dependent deferred materialized query table. There are cases in which
incremental propagation is not allowed, and the staging table is marked
incomplete. That is, the staging byte of the CONST_CHECKED column has a value
of F. In this state, the staging table can not be used to refresh its dependent
deferred materialized query table, and a full refresh is required in the materialized
query table maintenance process.

If a table is in incomplete state and the INCREMENTAL option has been specified,
but incremental propagation of the table is not possible, an error is returned. If any
of the following have taken place, the system turns off immediate data propagation
and sets the table state to incomplete:
v A load replace operation has taken place on an underlying table of the staging
table, or the NOT LOGGED INITIALLY WITH EMPTY TABLE option has been
activated after the last integrity check on the underlying table.
v The dependent materialized query table of the staging table, or the staging table
has been loaded in REPLACE or INSERT mode.
v An underlying table has been taken out of Set Integrity Pending state before the
staging table has been propagated by using the FULL ACCESS option during
integrity checking.
v An underlying table of the staging table has been checked for integrity
non-incrementally.

148 Data Movement Utilities Guide and Reference

 v The table space containing the staging table or its underlying table has been
rolled forward to a point in time, and the staging table and its underlying table
reside in different table spaces.

If the staging table has a W value in the CONST_CHECKED column of the

SYSCAT.TABLES catalog, and the NOT INCREMENTAL option is not specified,
incremental propagation to the staging table takes place and the
CONST_CHECKED column of SYSCAT.TABLES is marked as U to indicate that not
all data has been verified by the system.

The following example illustrates a load insert operation into the underlying table
UT1 of staging table G1 and its dependent deferred materialized query table AST1.
In this scenario, both the integrity checking for UT1 and the refreshing of AST1 are
processed incrementally:
LOAD FROM IMTFILE1.IXF of IXF INSERT INTO UT1;
LOAD FROM IMTFILE2.IXF of IXF INSERT INTO UT1;
SET INTEGRITY FOR UT1,G1 IMMEDIATE CHECKED;

REFRESH TABLE AST1 INCREMENTAL;

Refreshing dependent immediate materialized query tables

If the underlying table of an immediate refresh materialized query table is loaded
using the INSERT option, executing the SET INTEGRITY statement on the
dependent materialized query tables defined with REFRESH IMMEDIATE results
in an incremental refresh of the materialized query table.

During an incremental refresh, the rows corresponding to the appended rows in

the underlying tables are updated and inserted into the materialized query tables.
Incremental refresh is faster in the case of large underlying tables with small
amounts of appended data. There are cases in which incremental refresh is not
allowed, and full refresh (that is, recomputation of the materialized query table
definition query) is used.

When the INCREMENTAL option is specified, but incremental processing of the

materialized query table is not possible, an error is returned if:
v A load replace operation has taken place into an underlying table of the
materialized query table or the NOT LOGGED INITIALLY WITH EMPTY
TABLE option has been activated since the last integrity check on the underlying
table.
v The materialized query table has been loaded (in either REPLACE or INSERT
mode).
v An underlying table has been taken out of Set Integrity Pending state before the
materialized query table is refreshed by using the FULL ACCESS option during
integrity checking.
v An underlying table of the materialized query table has been checked for
integrity non-incrementally.
v The materialized query table was in Set Integrity Pending state before migration.
v The table space containing the materialized query table or its underlying table
has been rolled forward to a point in time, and the materialized query table and
its underlying table reside in different table spaces.

If the materialized query table has one or more W values in the CONST_CHECKED
column of the SYSCAT.TABLES catalog, and if the NOT INCREMENTAL option is
not specified in the SET INTEGRITY statement, the table is incrementally refreshed

Chapter 4. Load utility 149

 and the CONST_CHECKED column of SYSCAT.TABLES is marked U to indicate
that not all data has been verified by the system.

The following example illustrates a load insert operation into the underlying table
UTI of the materialized query table AST1. UT1 is checked for data integrity and is
placed in the no data movement mode. UT1 is put back into full access state once
the incremental refresh of AST1 is complete. In this scenario, both the integrity
checking for UT1 and the refreshing of AST1 are processed incrementally.
LOAD FROM IMTFILE1.IXF of IXF INSERT INTO UT1;
LOAD FROM IMTFILE2.IXF of IXF INSERT INTO UT1;
SET INTEGRITY FOR UT1 IMMEDIATE CHECKED;
REFRESH TABLE AST1;

Multidimensional clustering considerations

The following restrictions apply when loading data into multidimensional
clustering (MDC) tables:
v The SAVECOUNT option of the LOAD command is not supported.
v The totalfreespace file type modifier is not supported since these tables
manage their own free space.
v The anyorder file type modifier is required for MDC tables. If a load is executed
into an MDC table without the anyorder modifier, it will be explicitly enabled by
the utility.

When using the LOAD command with an MDC table, violations of unique
constraints are be handled as follows:
v If the table included a unique key prior to the load operation and duplicate
records are loaded into the table, the original record remains and the new
records are deleted during the delete phase.
v If the table did not include a unique key prior to the load operation and both a
unique key and duplicate records are loaded into the table, only one of the
records with the unique key is loaded and the others are deleted during the
delete phase.

Note: There is no explicit technique for determining which record is loaded and
which is deleted.

Performance Considerations

To improve the performance of the load utility when loading MDC tables, the
util_heap_sz database configuration parameter value should be increased. The
mdc-load algorithm performs significantly better when more memory is available
to the utility. This reduces disk I/O during the clustering of data that is performed
during the load phase. Beginning in version 9.5, the value of the DATA BUFFER
option of the LOAD command can temporarily exceed util_heap_sz if more memory
is available in the system.

MDC load operations always have a build phase since all MDC tables have block
indexes.

During the load phase, extra logging for the maintenance of the block map is
performed. There are approximately two extra log records per extent allocated. To
ensure good performance, the logbufsz database configuration parameter should be
set to a value that takes this into account.

150 Data Movement Utilities Guide and Reference

 A system temporary table with an index is used to load data into MDC tables. The
size of the table is proportional to the number of distinct cells loaded. The size of
each row in the table is proportional to the size of the MDC dimension key. To
minimize disk I/O caused by the manipulation of this table during a load
operation, ensure that the buffer pool for the temporary table space is large
enough.

Moving data using a customized application (user exit)

The load SOURCEUSEREXIT option provides a facility through which the load
utility can execute a customized script or executable, referred to herein as a user
exit.

The purpose of the user exit is to populate one or more named pipes with data
that is simultaneously read from by the load utility. In a multi-partition database,
multiple instances of the user exit can be invoked concurrently to achieve
parallelism of the input data.

As Figure 5 shows, the load utility creates a one or more named pipes and spawns
a process to execute your customized executable. Your user exit feeds data into the
named pipe(s) while the load utility simultaneously reads.

Figure 5. The load utility reads from the pipe and processes the incoming data.

The data fed into the pipe must reflect the load options specified, including the file
type and any file type modifiers. The load utility does not directly read the data
files specified. Instead, the data files specified are passed as arguments to your
user exit when it is executed.

Chapter 4. Load utility 151

 Invoking your user exit

The user exit must reside in the bin subdirectory of the DB2 installation directory
(often known as sqllib). The load utility invokes the user exit executable with the
following command line arguments:
<base pipename> <number of source media>
<source media 1> <source media 2> ... <user exit ID>
<number of user exits> <database partition number>

Where:
<base pipename >
Is the base name for named-pipes that the load utility creates and reads
data from. The utility creates one pipe for every source file provided to the
LOAD command, and each of these pipes is appended with .xxx, where
xxx is the index of the source file provided. For example, if there are 2
source files provided to the LOAD command, and the <base pipename>
argument passed to the user exit is pipe123, then the two named pipes that
your user exit should feed with data are pipe123.000 and pipe123.001. In
a partitioned database environment, the load utility appends the database
partition (DBPARTITION) number .yyy to the base pipe name, resulting in
the pipe name pipe123.xxx.yyy..
<number of source media>
Is the number of media arguments which follow.
<source media 1> <source media 2> ...
Is the list of one or more source files specified in the LOAD command.
Each source file is placed inside double quotation marks.
<user exit ID>
Is a special value useful when the PARALLELIZE option is enabled. This
integer value (from 1 to N, where N is the total number of user exits being
spawned) identifies a particular instance of a running user exit. When the
PARALLELIZE option is not enabled, this value defaults to 1.
<number of user exits>
Is a special value useful when the PARALLELIZE option is enabled. This
value represents the total number of concurrently running user exits. When
the PARALLELIZE option is not enabled, this value defaults to 1.
<database partition number>
Is a special value useful when the PARALLELIZE option is enabled. This is
the database partition (DBPARTITION) number on which the user exit is
executing. When the PARALLELIZE option is not enabled, this value
defaults to 0.

Additional options and features

The following section describes additional SOURCEUSEREXIT facility options:

REDIRECT
This option allows you to pass data into the STDIN handle or capture data
from the STDOUT and STDERR handles of the user exit process.
INPUT FROM BUFFER <buffer>
Allows you to pass information directly into the STDIN input stream of
your user exit. After spawning the process which executes the user exit, the
load utility acquires the file-descriptor to the STDIN of this new process
and passes in the buffer provided. The user exit reads from STDIN to

152 Data Movement Utilities Guide and Reference

 acquire the information. The load utility simply sends the contents of
<buffer> to the user exit using STDIN and does not interpret or modify its
contents. For example, if your user exit is designed to read two values
from STDIN, an eight-byte userid and an eight-byte password, your user
exit executable written in C might contain the following lines:
rc = read (stdin, pUserID, 8);
rc = read (stdin, pPasswd, 8);

A user could pass this information using the INPUT FROM BUFFER
option as shown in the following LOAD command:
LOAD FROM myfile1 OF DEL INSERT INTO table1
SOURCEUSEREXIT myuserexit1 REDIRECT INPUT FROM BUFFER myuseridmypasswd

Note: The load utility limits the size of <buffer> to the maximum size of a
LOB value. However, from within the command line processor (CLP), the
size of <buffer> is restricted to the maximum size of a CLP statement.
From within CLP, it is also recommended that <buffer> contain only
traditional ASCII characters. These issues can be avoided if the load utility
is invoked using the db2Load API, or if the INPUT FROM FILE option is
used instead.
INPUT FROM FILE <filename>
Allows you to pass the contents of a client side file directly into the STDIN
input stream of your user exit. This option is almost identical to the INPUT
FROM BUFFER option, however this option avoids the potential CLP
limitation. The filename must be a fully qualified client side file and must
not be larger than the maximum size of a LOB value.
OUTPUT TO FILE <filename>
Allows you to capture the STDOUT and STDERR streams from your user
exit process into a server side file. After spawning the process which
executes the user exit executable, the load utility redirects the STDOUT
and STDERR handles from this new process into the filename specified.
This option is useful for debugging and logging errors and activity within
your user exit. The filename must be a fully qualified server side file.
When the PARALLELIZE option is enabled, one file exists per user exit
and each file appends a three-digit numeric identifier, such as filename.000.
PARALLELIZE
This option can increase the throughput of data coming into the load
utility by invoking multiple user exit processes simultaneously. This option
is only applicable to a multi-partition database. The number of user exit
instances invoked is equal to the number of partitioning agents if data is to
be distributed across multiple database partitions during the load
operation, otherwise it is equal to the number of loading agents.

The <user exit ID>, <number of user exits>, and <database partition number>
arguments passed into each user exit reflect the unique identifier (1 to N), the total
number of user exits (N), and the database partition (DBPARTITION) number on
which the user exit instance is running, respectively. You should ensure that any
data written to the named pipe by each user exit process is not duplicated by the
other concurrent processes. While there are many ways your user exit application
might accomplish this, these values could be helpful to ensure data is not
duplicated. For example, if each record of data contains a unique integer column
value, your user exit application could use the <user exit ID> and <number of user

Chapter 4. Load utility 153

 exits> values to ensure that each user exit instance returns a unique result set into
its named pipe. Your user exit application might use the MODULUS property in
the following way:
i = <user exit ID>
N = <number of user exits>

foreach record
{
if ((unique-integer MOD N) == i)
{
write this record to my named-pipe
}
}

The number of user exit processes spawned depends on the distribution mode
specified for database partitioning:
1. As Figure 6 on page 155 shows, one user exit process is spawned for every
pre-partitioning agent when PARTITION_AND_LOAD (default) or
PARTITION_ONLY without PARALLEL is specified. .

154 Data Movement Utilities Guide and Reference

Figure 6. The various tasks performed when PARTITION_AND_LOAD (default) or PARTITION_ONLY without
PARALLEL is specified.

2. As Figure 7 on page 156 shows, one user exit process is spawned for every
partitioning agent when PARTITION_AND_LOAD (default) or
PARTITION_ONLY with PARALLEL is specified.

Chapter 4. Load utility 155

Figure 7. The various tasks performed when PARTITION_AND_LOAD (default) or PARTITION_ONLY with PARALLEL
is specified.

3. As Figure 8 on page 157 shows, one user exit process is spawned for every load
agent when LOAD_ONLY or LOAD_ONLY_VERIFY_PART is specified.

156 Data Movement Utilities Guide and Reference

Figure 8. The various tasks performed when LOAD_ONLY or LOAD_ONLY_VERIFY_PART is specified.

Restrictions
v The LOAD_ONLY and LOAD_ONLY_VERIFY_PART partitioned-db-cfg mode
options are not supported when the SOURCEUSEREXIT PARALLELIZE option
is not specified.

Examples

Example 1: A Load userexit script that replaces all tab characters '\t' with comma
characters ',' from every record of the source media file. To invoke the Load utility
using this userexit script, use a command similar to the following:
DB2 LOAD FROM /path/file1 OF DEL INSERT INTO schema1.table1
SOURCEUSEREXIT example1.pl REDIRECT OUTPUT TO FILE /path/ue_msgs.txt

Note that the userexit must be placed into the sqllib/bin/ folder, and requires
execute permissions.

example1.pl:
#!/bin/perl

# Filename: example1.pl
#
# This script is a simple example of a userexit for the Load utility
# SOURCEUSEREXIT feature. This script will replace all tab characters ’\t’
# with comma characters ’,’ from every record of the source media file.

Chapter 4. Load utility 157

 #
# To invoke the Load utility using this userexit, use a command similar to:
#
# db2 LOAD FROM /path/file1 OF DEL INSERT INTO schema1.table1
# SOURCEUSEREXIT example1.pl REDIRECT OUTPUT TO FILE /path/ue_msgs.txt
#
# The userexit must be placed into the sqllib/bin/ folder, and requires
# execute permissions.
#--------------------------------------------------------------------
if ($#ARGV < 5)
{
print "Invalid number of arguments:\n@ARGV\n";
print "Load utility should invoke userexit with 5 arguments (or more):\n";
print "<base pipename> <number of source media> ";
print "<source media 1> <source media 2> ... <user exit ID> ";
print "<number of user exits> <database partition number> ";
print "<optional: redirected input> \n";
die;
}

# Open the output fifo file (the Load utility is reading from this pipe)
#-----------------------------------------------------------------------
$basePipeName = $ARGV[0];
$outputPipeName = sprintf("%s.000", $basePipeName);
open(PIPETOLOAD, ’>’, $outputPipeName) || die "Could not open $outputPipeName";

# Get number of Media Files

#--------------------------
$NumMediaFiles = $ARGV[1];

# Open each media file, read the contents, replace ’\t’ with ’,’, send to Load
#-----------------------------------------------------------------------------
for ($i=0; $i<$NumMediaFiles; $i++)
{
# Open the media file
#--------------------
$mediaFileName = $ARGV[2+$i];
open(MEDIAFILETOREAD, ’<’, $mediaFileName) || die "Could not open $mediaFileName";

# Read each record of data

#------------------------
while ( $line = <MEDIAFILETOREAD> )
{
# Replace ’\t’ characters with ’,’
#---------------------------------
$line =~ s/\t/,/g;

# send this record to Load for processing

#-----------------------------------------
print PIPETOLOAD $line;
}
# Close the media file
#---------------------
close MEDIAFILETOREAD;
}

# Close the fifo

#---------------
close PIPETOLOAD;

exit 0;

158 Data Movement Utilities Guide and Reference

Additional considerations for load

Parallelism and loading

The load utility takes advantage of a hardware configuration in which multiple
processors or multiple storage devices are used, such as in a symmetric
multiprocessor (SMP) environment.

There are several ways in which parallel processing of large amounts of data can
take place using the load utility. One way is through the use of multiple storage
devices, which allows for I/O parallelism during the load operation (see Figure 9).
Another way involves the use of multiple processors in an SMP environment,
which allows for intra-partition parallelism (see Figure 10). Both can be used
together to provide even faster loading of data.

I/O I/O I/O

Subagent Subagent Subagent

Disk Disk Disk

Figure 9. Taking Advantage of I/O Parallelism When Loading Data

Source data (DEL, ASC, IXF, CURSOR)

parse, parse, parse, parse,

convert fields, convert fields, convert fields, convert fields,
build record, build record, build record, build record,
insert into table insert into table insert into table insert into table

Database

Figure 10. Taking Advantage of Intra-partition Parallelism When Loading Data

Index creation during load operations

Indexes are built during the build phase of a load operation. There are four
indexing modes that can be specified in the LOAD command:
1. REBUILD. All indexes are rebuilt.
2. INCREMENTAL. Indexes are extended with new data.
3. AUTOSELECT. The load utility automatically decides between REBUILD or
INCREMENTAL mode. AUTOSELECT is the default. If a load REPLACE
operation is taking place, the REBUILD indexing mode is used. Otherwise, the
indexing mode chosen is based on the ratio of the amount of existing data in

Chapter 4. Load utility 159

 the table to the amount of newly loaded data. If the ratio is sufficiently large,
the INCREMENTAL indexing mode is chosen. Otherwise, the REBUILD
indexing mode is chosen.
4. DEFERRED. The load utility does not attempt index creation if this mode is
specified. Indexes are marked as needing a refresh, and a rebuild might be
forced the first time they are accessed. The DEFERRED option is not allowed in
any of the following situations:
v If the ALLOW READ ACCESS option is specified (it does not maintain the
indexes and index scanners require a valid index)
v If any unique indexes are defined against the table
v If XML data is being loaded (the XML Paths index is unique and is created
by default whenever an XML column is added to a table)

Load operations that specify the ALLOW READ ACCESS option require special
consideration in terms of space usage and logging depending on the type of
indexing mode chosen. When the ALLOW READ ACCESS option is specified, the
load utility keeps indexes available for queries even while they are being rebuilt.

When a load operation in ALLOW READ ACCESS mode specifies the INDEXING
MODE INCREMENTAL option, the load utility writes some log records that
protect the integrity of the index tree. The number of log records written is a
fraction of the number of inserted keys and is a number considerably less than
would be needed by a similar SQL insert operation. A load operation in ALLOW
NO ACCESS mode with the INDEXING MODE INCREMENTAL option specified
writes only a small log record beyond the normal space allocation logs.

Note: This is only true if you did not specify COPY YES and have the
logindexrebuild configuration parameter set to ON.

When a load operation in ALLOW READ ACCESS mode specifies the INDEXING
MODE REBUILD option, new indexes are built as a shadow either in the same table
space as the original index or in a system temporary table space. The original
indexes remain intact and are available during the load operation and are only
replaced by the new indexes at the end of the load operation while the table is
exclusively locked. If the load operation fails and the transaction is rolled back, the
original indexes remain intact.

By default, the shadow index is built in the same table space as the original index.
Since both the original index and the new index are maintained simultaneously,
there must be sufficient table space to hold both indexes at the same time. If the
load operation is aborted, the extra space used to build the new index is released.
If the load operation commits, the space used for the original index is released and
the new index becomes the current index. When the new indexes are built in the
same table space as the original indexes, replacing the original indexes takes place
almost instantaneously.

If the indexes are built within an SMS table space, you can see index files in the
table space directory with the .IN1 suffix and the .INX suffix. These suffixes do not
indicate which is the original index and which is the shadow index. However, if
the indexes are built in a DMS table space, you cannot see the new shadow index.

Improving index creation performance

Building new indexes in a system temporary table space

The new index can be built in a system temporary table space to avoid running

160 Data Movement Utilities Guide and Reference

out of space in the original table space. The USE <tablespace-name> option allows
the indexes to be rebuilt in a system temporary table space when using INDEXING
MODE REBUILD and ALLOW READ ACCESS options. The system temporary
table can be an SMS or a DMS table space, but the page size of the system
temporary table space must match the page size of the original index table space.

The USE <tablespace-name> option is ignored if the load operation is not in

ALLOW READ ACCESS mode, or if the indexing mode is incompatible. The USE
<tablespace-name> option is only supported for the INDEXING MODE REBUILD
or INDEXING MODE AUTOSELECT options. If the INDEXING MODE
AUTOSELECT option is specified and the load utility selects incremental
maintenance of the indexes, the USE <tablespace-name> is ignored.

A load restart operation can use an alternate table space for building an index,
even if the original load operation did not use an alternate table space. A load
restart operation cannot be issued in ALLOW READ ACCESS mode if the original
load operation was not issued in ALLOW READ ACCESS mode. Load terminate
operations do not rebuild indexes, so the USE <tablespace-name> is ignored.

During the build phase of the load operation, the indexes are built in the system
temporary table space. Then, during the index copy phase, the index is copied
from the system temporary table space to the original index table space. To make
sure that there is sufficient space in the original index table space for the new
index, space is allocated in the original table space during the build phase. So, if
the load operation runs out of index space, it will do so during the build phase. If
this happens, the original index is not lost.

The index copy phase occurs after the build and delete phases. Before the index
copy phase begins, the table is locked exclusively. That is, it is unavailable for read
access throughout the index copy phase. Since the index copy phase is a physical
copy, the table might be unavailable for a significant amount of time.

Note: If either the system temporary table space or the index table space are DMS
table spaces, the read from the system temporary table space can cause random
I/O on the system temporary table space and can cause a delay. The write to the
index table space is still optimized and the DISK_PARALLELISM values are used.

Considerations for large indexes

In order to improve performance when building large indexes during a load, it can
be useful to tune the sortheap database configuration parameter. sortheap allocates
the amount of memory dedicated to the sorting of index keys during a load
operation. For example, to direct the load utility to use 4000 pages of main
memory per index for key sorting, set sortheap to 4000 pages, disconnect all
applications from the database, and then issue the LOAD command.

If an index is so large that it cannot be sorted in memory, a sort spill, or an

overflow, occurs. That is, the data is divided among several "sort runs" and stored
in a temporary table space that is merged later. Use the sort_overflows monitor
element to determine whether or not a sort spill has occurred. If there is no way to
avoid a sort spill by increasing the size of the sortheap parameter, ensure that the
buffer pool for temporary table spaces be large enough to minimize the amount of
disk I/O that spilling causes. Furthermore, to achieve I/O parallelism during the
merging of sort runs, it is recommended that temporary table spaces be declared
with multiple containers, each residing on a different disk device. If there is more
than one index defined on a table, memory consumption increases proportionally
because the load operation keeps all keys in memory.

Chapter 4. Load utility 161

 Deferring index creation
Generally speaking, it is more efficient to allow indexes to be created during the
load operation by specifying either REBUILD or INCREMENTAL mode than it is
to have index creation deferred. As Figure 11 indicates, tables are normally built in
three steps: data loading, index building, and statistics collection. This causes
multiple data I/O during the load operation, index creation (there can be several
indexes for each table), and statistics collection (which causes I/O on the table data
and on all of the indexes). A much faster alternative is to let the load utility
complete all of these tasks in one pass through the data. It should be noted,
however, that unique indexes reduce load performance if duplicates are
encountered.

create load create create collect table available

table table index A index B stats for queries

Time

create create create load, with table available

table index A index B indexing for queries
(empty) (empty) and statistics

Time

Figure 11. Increasing load performance through concurrent indexing and statistics collection. Tables are normally built
in three steps: data loading, index building, and statistics collection. This causes multiple data I/O during the load
operation, during index creation (there can be several indexes for each table), and during statistics collection (which
causes I/O on the table data and on all of the indexes). A much faster alternative is to let the load utility complete all of
these tasks in one pass through the data.

At certain times, deferring index creation and invoking the CREATE INDEX
statement can improve performance. Sorting during index rebuild uses up to
sortheap pages. If more space is required, TEMP buffer pool is used and
(eventually) spilled to disk. If load spills, and thus decreases performance, it might
be advisable to run LOAD with INDEXING MODE DEFERRED and re-create the
index later. CREATE INDEX creates one index at a time, reducing memory usage
while scanning the table multiple times to collect keys.

Another advantage of building indexes with a CREATE INDEX statement instead

of concurrently with the load operation is that the CREATE INDEX statement can
use multiple processes, or threads, to sort keys if INTRA PARALLEL is on. The
actual building of the index is not executed in parallel.

Resolving indexing errors when loading XML data

Load operations that fail due to indexing errors can be resolved using the
db2diag.log logfile and the import utility together to identify and correct problem
values in the XML data.

About this task

If a load operation returns the error message SQL20305N (sqlcode -20305), this
indicates that one or more XML node values could not be indexed. The error
message will output the reason code for the error. Enter ? SQL20305N in the
command line processor to look up the explanation and user response for the
corresponding reason code.

For indexing problems during insert operations, a generated XQuery statement is

output to the db2diag.log logfile to help locate the failing XML node values within

162 Data Movement Utilities Guide and Reference

the document. See "Common XML indexing issues" for details about how to use
the XQuery statement to locate the failing XML node values.

For indexing problems during load operations, however, the generated XQuery
statements are not output to the db2diag.log logfile. To generate these XQuery
statements the import utility must be run on the failing rows that were not loaded.
Because the rejected rows do not exist in the table, the XQuery statements cannot
be run on the failing documents. To solve this problem, a new table with the same
definition must be created without any indexes. The failing rows can then be
loaded into the new table, and the XQuery statements can then be run on the new
table to locate the failing XML node values within the documents.

Perform the following steps to resolve the indexing errors:

Procedure
1. Determine which rows were rejected during the load operation using the record
numbers in the output information.
2. Create a .del file containing only the rejected rows.
3. Create a new table (for example, T2) with the same columns as the original
table (T1). Do not create any indexes on the new table.
4. Load the rejected rows into the new table T2.
5. For each rejected row in the original table T1:
a. Import the rejected rows to T1 to get the SQL20305N message. The import
will stop on the first error that it encounters.
b. Look in the db2diag.log logfile and get the generated XQuery statement. To
find the failing node values in the input document, search for the string
'SQL20305N' in the db2diag.log logfile and match the reason code number.
Following the reason code, you will find a set of instructions and then a
generated XQuery statement that you can use to locate the problem value in
the document that caused the error.
c. Modify the XQuery statement to use the new table T2.
d. Run the XQuery statement on T2 to locate the problem value in the
document.
e. Fix the problem value in the .xml file containing the document.
f. Return to Step a and import the rejected rows to T1 again. The row that
caused the import to stop should now be inserted successfully. If there is
another rejected row in the .del file, the import utility will stop on the next
error and output another SQL20305N message. Continue these steps until
the import runs successfully.

Example

In the following example, the index BirthdateIndex has been created on the date
data type. The REJECT INVALID VALUES option is specified, so the XML pattern
values for /Person/Confidential/Birthdate must all be valid for the date data type. If
any XML pattern value cannot be cast to this data type, an error is returned.

Using the XML documents below, five rows are supposed to be loaded but the first
and the fourth rows will be rejected because the Birthdate values cannot be
indexed. In the file person1.xml, the value March 16, 2002 is not in the correct date
format. In the file person4.xml, the value 20000-12-09 has an extra zero for the

Chapter 4. Load utility 163

 year, so it is a valid XML date value but it is outside of the range that DB2 allows
for a year (0001 to 9999). Some of the sample output has been edited to make the
example more concise.

The five XML files to load are as follows:

person1.xml (Birthdate value is not valid)

<?xml version="1.0"?>
<Person gender="Male">
<Name>
<Last>Cool</Last>
<First>Joe</First>
</Name>
<Confidential>
<Age unit="years">5</Age>
<Birthdate>March 16, 2002</Birthdate>
<SS>111-22-3333</SS>
</Confidential>
<Address>5224 Rose St. San Jose, CA 95123</Address>
</Person>

person2.xml (Birthdate value is valid)

<?xml version="1.0"?>
<Person gender="Male">
<Name>
<Last>Cool</Last>
<First>Joe</First>
</Name>
<Confidential>
<Age unit="years">5</Age>
<Birthdate>2002-03-16</Birthdate>
<SS>111-22-3333</SS>
</Confidential>
<Address>5224 Rose St. San Jose, CA 95123</Address>
</Person>

person3.xml (Birthdate value is valid)

<?xml version="1.0"?>
<Person gender="Female">
<Name>
<Last>McCarthy</Last>
<First>Laura</First>
</Name>
<Confidential>
<Age unit="years">6</Age>
<Birthdate>2001-03-12</Birthdate>
<SS>444-55-6666</SS>
</Confidential>
<Address>5960 Daffodil Lane, San Jose, CA 95120</Address>
</Person>

person4.xml (Birthdate value is not valid)

<?xml version="1.0"?>
<Person gender="Female">
<Name>
<Last>Wong</Last>
<First>Teresa</First>
</Name>
<Confidential>
<Age unit="years">7</Age>
<Birthdate>20000-12-09</Birthdate>

164 Data Movement Utilities Guide and Reference

 <SS>555-66-7777</SS>
</Confidential>
<Address>5960 Tulip Court, San Jose, CA 95120</Address>
</Person>

person5.xml (Birthdate value is valid)

<?xml version="1.0"?>
<Person gender="Male">
<Name>
<Last>Smith</Last>
<First>Chris</First>
</Name>
<Confidential>
<Age unit="years">10</Age>
<Birthdate>1997-04-23</Birthdate>
<SS>666-77-8888</SS>
</Confidential>
<Address>5960 Dahlia Street, San Jose, CA 95120</Address>
</Person>

The input file person.del contains:

1, <XDS FIL=’person1.xml’/>
2, <XDS FIL=’person2.xml’/>
3, <XDS FIL=’person3.xml’/>
4, <XDS FIL=’person4.xml’/>
5, <XDS FIL=’person5.xml’/>

The DDL and LOAD statements are as follows:

CREATE TABLE T1 (docID INT, XMLDoc XML);

CREATE INDEX BirthdateIndex ON T1(xmlDoc)

GENERATE KEY USING XMLPATTERN ’/Person/Confidential/Birthdate’ AS SQL DATE
REJECT INVALID VALUES;

LOAD FROM person.del OF DEL INSERT INTO T1

To resolve the indexing errors that would occur when you attempt to load the set
of XML files above, you would perform the following steps:
1. Determine which rows were rejected during the load operation using the record
numbers in the output information. In the following output, record number 1
and record number 4 were rejected.
SQL20305N An XML value cannot be inserted or updated because of an error
detected when inserting or updating the index identified by "IID = 3" on table
"LEECM.T1". Reason code = "5". For reason codes related to an XML schema the
XML schema identifier = "*N" and XML schema data type = "*N". SQLSTATE=23525

SQL3185W The previous error occurred while processing data from row "F0-1" of
the input file.

SQL20305N An XML value cannot be inserted or updated because of an error

detected when inserting or updating the index identified by "IID = 3" on table
"LEECM.T1". Reason code = "4". For reason codes related to an XML schema the
XML schema identifier = "*N" and XML schema data type = "*N". SQLSTATE=23525

SQL3185W The previous error occurred while processing data from row "F0-4" of
the input file.

SQL3227W Record token "F0-1" refers to user record number "1".

SQL3227W Record token "F0-4" refers to user record number "4".

SQL3107W There is at least one warning message in the message file.

Chapter 4. Load utility 165

 Number of rows read = 5
Number of rows skipped = 0
Number of rows loaded = 3
Number of rows rejected = 2
Number of rows deleted = 0
Number of rows committed = 5
2. Create a new file reject.del with the rejected rows.
1, <XDS FIL=’person1.xml’/>
4, <XDS FIL=’person4.xml’/>
3. Create a new table T2 with the same columns as the original table T1. Do not
create any indexes on the new table.
CREATE TABLE T2 LIKE T1
4. Load the rejected rows into the new table T2.
LOAD FROM reject.del OF DEL INSERT INTO T2;
5. For rejected row 1 in the original table T1:
a. Import the rejected rows to T1 to get the -20305 message
IMPORT FROM reject.del OF DEL INSERT INTO T1
SQL3109N The utility is beginning to load data from file "reject.del".

SQL3306N An SQL error "-20305" occurred while inserting a row into the
table.

SQL20305N An XML value cannot be inserted or updated because of an error

detected when inserting or updating the index identified by "IID = 3" on
table "LEECM.T1". Reason code = "5". For reason codes related to an XML
schema the XML schema identifier = "*N" and XML schema data type = "*N".
SQLSTATE=23525

SQL3110N The utility has completed processing. "1" rows were read from
the input file.
b. Look in the db2diag.log logfile and get the generated XQuery statement.
FUNCTION: DB2 UDB, Xml Storage and Index Manager, xmlsDumpXQuery, probe:608
DATA #1 : String, 36 bytes
SQL Code: SQL20305N ; Reason Code: 5
DATA #2 : String, 265 bytes
To locate the value in the document that caused the error, create a
table with one XML column and insert the failing document in the table.
Replace the table and column name in the query below with the created
table and column name and execute the following XQuery.
DATA #3 : String, 247 bytes
xquery for $i in db2-fn:xmlcolumn(
"LEECM.T1.XMLDOC")[/*:Person/*:Confidential/*:Birthdate="March 16, 2002"]
return
<Result>
<ProblemDocument> {$i} </ProblemDocument>
<ProblemValue>{$i/*:Person/*:Confidential/*:Birthdate/..} </ProblemValue>
</Result>;
c. Modify the XQuery statement to use the new table T2.
xquery for $i in db2-fn:xmlcolumn(
"LEECM.T2.XMLDOC")[/*:Person/*:Confidential/*:Birthdate="March 16, 2002"]
return
<Result>
<ProblemDocument> {$i} </ProblemDocument>
<ProblemValue>{$i/*:Person/*:Confidential/*:Birthdate/..} </ProblemValue>
</Result>;
d. Run the XQuery statement on table T2 to locate the problem value in the
document.
<Result><ProblemDocument><Person gender="Male">
<Name>
<Last>Cool</Last>

166 Data Movement Utilities Guide and Reference

 <First>Joe</First>
</Name>
<Confidential>
<Age unit="years">5</Age>
<Birthdate>March 16, 2002</Birthdate>
<SS>111-22-3333</SS>
</Confidential>
<Address>5224 Rose St. San Jose, CA 95123</Address>
</Person></ProblemDocument><ProblemValue><Confidential>
<Age unit="years">5</Age>
<Birthdate>March 16, 2002</Birthdate>
<SS>111-22-3333</SS>
</Confidential></ProblemValue></Result>
e. Fix the problem value in the file person1.xml containing the document.
March 16, 2002 is not in the correct date format so it is changed to
2002-03-16.
<?xml version="1.0"?>
<Person gender="Male">
<Name>
<Last>Cool</Last>
<First>Joe</First>
</Name>
<Confidential>
<Age unit="years">5</Age>
<Birthdate>2002-03-16</Birthdate>
<SS>111-22-3333</SS>
</Confidential>
<Address>5224 Rose St. San Jose, CA 95123</Address>
</Person>
f. Go back to step a. to import the rejected rows to table T1 again.
6. (First repetition of Step 5)
a. Import the rejected rows to table T1. The first row is now imported
successfully because two rows were read from the import file. A new error
occurs on the second row.
IMPORT FROM reject.del OF DEL INSERT INTO T1
SQL3109N The utility is beginning to load data from file "reject.del".

SQL3306N An SQL error "-20305" occurred while inserting a row into the
table.

SQL20305N An XML value cannot be inserted or updated because of an error

detected when inserting or updating the index identified by "IID = 3" on
table "LEECM.T1". Reason code = "4". For reason codes related to an XML
schema the XML schema identifier = "*N" and XML schema data type = "*N".
SQLSTATE=23525

SQL3110N The utility has completed processing. "2" rows were read from
the input file.
b. Look in the db2diag.log logfile and get the generated XQuery statement.
FUNCTION: DB2 UDB, Xml Storage and Index Manager, xmlsDumpXQuery, probe:608
DATA #1 : String, 36 bytes
SQL Code: SQL20305N ; Reason Code: 4
DATA #2 : String, 265 bytes
To locate the value in the document that caused the error, create a
table with one XML column and insert the failing document in the table.
Replace the table and column name in the query below with the created
table and column name and execute the following XQuery.
DATA #3 : String, 244 bytes
xquery for $i in db2-fn:xmlcolumn("LEECM.T1.XMLDOC")
[/*:Person/*:Confidential/*:Birthdate="20000-12-09"]
return

Chapter 4. Load utility 167

 <Result>
<ProblemDocument> {$i} </ProblemDocument>
<ProblemValue>{$i/*:Person/*:Confidential/*:Birthdate/..} </ProblemValue>
</Result>;
c. Modify the XQuery statement to use table T2.
xquery for $i in db2-fn:xmlcolumn("LEECM.T2.XMLDOC")
[/*:Person/*:Confidential/*:Birthdate="20000-12-09"]
return
<Result>
<ProblemDocument> {$i} </ProblemDocument>
<ProblemValue>{$i/*:Person/*:Confidential/*:Birthdate/..} </ProblemValue>
</Result>;
d. Run the XQuery statement to locate the problem value in the document.
<Result><ProblemDocument><Person gender="Female">
<Name>
<Last>Wong</Last>
<First>Teresa</First>
</Name>
<Confidential>
<Age unit="years">7</Age>
<Birthdate>20000-12-09</Birthdate>
<SS>555-66-7777</SS>
</Confidential>
<Address>5960 Tulip Court, San Jose, CA 95120</Address>
</Person></ProblemDocument><ProblemValue><Confidential>
<Age unit="years">7</Age>
<Birthdate>20000-12-09</Birthdate>
<SS>555-66-7777</SS>
</Confidential></ProblemValue></Result>
e. Fix the problem value in the file person4.xml containing the document. The
value 20000-12-09 has an extra zero for the year so it is outside of the range
that DB2 allows for a year (0001 to 9999).. The value is changed to
2000-12-09.
<?xml version="1.0"?>
<Person gender="Female">
<Name>
<Last>Wong</Last>
<First>Teresa</First>
</Name>
<Confidential>
<Age unit="years">7</Age>
<Birthdate>2000-12-09</Birthdate>
<SS>555-66-7777</SS>
</Confidential>
<Address>5960 Tulip Court, San Jose, CA 95120</Address>
</Person>
f. Go back to step a to import the rejected rows to T1 again.
7. (Second repetition of Step 5)
a. Import the rejected rows to T1.
IMPORT FROM reject.del OF DEL INSERT INTO T1
SQL3109N The utility is beginning to load data from file "reject.del".

SQL3110N The utility has completed processing. "2" rows were read from
the input file.

SQL3221W ...Begin COMMIT WORK. Input Record Count = "2".

SQL3222W ...COMMIT of any database changes was successful.

SQL3149N "2" rows were processed from the input file. "2" rows were
successfully inserted into the table. "0" rows were rejected.

168 Data Movement Utilities Guide and Reference

 Number of rows read = 2
Number of rows skipped = 0
Number of rows inserted = 2
Number of rows updated = 0
Number of rows rejected = 0
Number of rows committed = 2
The problem is now resolved. All of the rows of person.del are successfully
inserted into table T1.

Compression dictionary creation during load operations

LOAD INSERT and LOAD REPLACE operations that meet certain criteria trigger
automatic dictionary creation (ADC). Once enough data has been processed, ADC
occurs if the load is performed on a table that has the COMPRESS attribute
enabled and a compression dictionary is not present.

Data row compression uses a static dictionary-based compression algorithm to

compress data. However, the dictionary must first exist in the table for
compression to occur. During a load operation, the default behavior (indicated by
the KEEPDICTIONARY option) is to either abide by the existing dictionary or, if a
dictionary is not present, to generate one once a certain threshold (about 1 MB) of
data has been scanned. The load utility uses the data that exists in the target table
to build the dictionary, under the assumption that this data is representative of the
kind of data that will be stored in that table. In cases where there is insufficient
preexisting data in the target table, the load utility builds the dictionary once it has
sampled enough input data. In DB2 Version 9.5 Fix Pack 4 and earlier, the load
utility uses both the input data and preexisting data to build the dictionary in this
situation. In Version 9.5 Fix Pack 5 and later, the load utility uses only the input
data to build the dictionary.

When ADC occurs on range partitioned tables, each partition is treated like an
individual table. There will not be any cross-partition dictionaries. ADC does not
occur on partitions already containing dictionaries, and the dictionary generated
for each partition is based only on the preexisting data (and, if necessary, the
loaded data) in that partition. In Version 9.5 Fix Pack 5 and later, if the preexisting
data in a partition is less than the minimum threshold, the dictionary is generated
based only on the loaded data.

Any load performed in the INSERT mode implicitly follows the

KEEPDICTIONARY behavior. However, for LOAD REPLACE operations, you
have an additional choice: the RESETDICTIONARY option.

LOAD REPLACE using the KEEPDICTIONARY option

A LOAD REPLACE operation that uses the KEEPDICTIONARY option keeps the
existing dictionary and uses it to compress the loaded data, as long as the target
table has the COMPRESS attribute enabled. If a dictionary does not exist, the load
utility generates a new one (provided the data that is being loaded into the table
surpasses the 1 MB threshold) for tables with the COMPRESS attribute enabled.
Since the target table's data is being replaced, the load utility uses only the input
data to build the dictionary. After the dictionary has been created, it is inserted
into the table and the load operation continues.

LOAD REPLACE using the RESETDICTIONARY option

There are two key implications of using the RESETDICTIONARY option when
loading into a table with the COMPRESS attribute on. First, ADC occurs as long as
any amount of data will exist in the target table once the LOAD REPLACE
operation has completed. In other words, the new compression dictionary can be

Chapter 4. Load utility 169

 based on a single row of data. The other implication is that the existing dictionary
is deleted but is not replaced (the target table will no longer have a compression
dictionary) if any of the following situations are true:
v The operation is performed on a table with the COMPRESS attribute off
v Nothing was loaded (zero rows), in which case ADM5591W is printed to the
notification log

Note: If you issue a LOAD TERMINATE operation after a LOAD REPLACE with
the RESETDICTIONARY option, an existing compression dictionary will be
deleted and not replaced.

Performance impact
ADC affects the performance of a load operation as a result of:
v The initial scan of table data
For LOAD INSERT operations in DB2 Version 9.5 Fix Pack 4 and earlier, all of
the preexisting table data, not just the minimum threshold for ADC, is scanned
prior to building the compression dictionary. Therefore, the time used for this
scan increases with table size.
v The additional processing to build the compression dictionary
The time actually used for building the dictionary is minimal. Moreover, once
the dictionary has been built, ADC is turned off, by default.

Options for improving load performance

There are various command parameters that you can use to optimize load
performance. There are also a number of file type modifiers unique to load which
can, in some cases, significantly improve that utility's performance.

Command parameters

The load utility attempts to deliver the best performance possible by determining
optimal values for DISK_PARALLELISM, CPU_PARALLELISM, and DATA
BUFFER, if these parameters have not be specified by the user. Optimization is
done based on the size and the free space available in the utility heap. Consider
using the autonomic DISK_PARALLELISM and CPU_PARALLELISM settings
before attempting to tune these parameters for your particular needs.

Following is information about the performance implications of various options

available through the load utility:
ALLOW READ ACCESS
This option allows you to query a table while a load operation is in
progress. You can only view data that existed in the table prior to the load
operation. If the INDEXING MODE INCREMENTAL option is also
specified, and the load operation fails, the subsequent load terminate
operation might have to correct inconsistencies in the index. This requires
an index scan which involves considerable I/O. If the ALLOW READ
ACCESS option is also specified for the load terminate operation, the
buffer pool is used for I/O.
COPY YES or NO
Use this parameter to specify whether a copy of the input data is to be
made during a load operation. COPY YES, which is only applicable when
forward recovery is enabled, reduces load performance because all of the
loading data is copied during the load operation. The increased I/O
activity might increase the load time on an I/O-bound system. Specifying

170 Data Movement Utilities Guide and Reference

 multiple devices or directories (on different disks) can offset some of the
performance penalty resulting from this operation. COPY NO, which is
only applicable when forward recovery is enabled, does not affect load
performance. However, all table spaces related to the loaded table will be
placed in a Backup Pending state, and those table spaces must be backed
up before the table can be accessed.
CPU_PARALLELISM
Use this parameter to exploit the number of processes running per
database partition (if this is part of your machine's capability), and
significantly improve load performance. The parameter specifies the
number of processes or threads used by the load utility to parse, convert,
and format data records. The maximum number allowed is 30. If there is
insufficient memory to support the specified value, the utility adjusts the
value. If this parameter is not specified, the load utility selects a default
value that is based on the number of CPUs on the system.
Record order in the source data is preserved (see Figure 12) regardless of
the value of this parameter, provided that:
v the anyorder file type modifier is not specified
v the PARTITIONING_DBPARTNUMS option (and more than one
partition is to be used for partitioning) is not specified
If tables include either LOB or LONG VARCHAR data,
CPU_PARALLELISM is set to 1. Parallelism is not supported in this case.
Although use of this parameter is not restricted to symmetric
multiprocessor (SMP) hardware, you might not obtain any discernible
performance benefit from using it in non-SMP environments.

User DB2 LOAD Table

records: (with SMP exploitation) records:
A,B,C,D A,B,C,D

Figure 12. Record Order in the Source Data is Preserved When the Number of Processes Running Per Database
Partition is Exploited During a Load Operation

DATA BUFFER
The DATA BUFFER parameter specifies the total amount of memory, in 4
KB units, allocated to the load utility as a buffer. It is recommended that
this buffer be several extents in size. The data buffer is allocated from the
utility heap; however, the data buffer can exceed the setting for the
util_heap_sz database configuration parameter as long as there is available
memory in the system
DISK_PARALLELISM
The DISK_PARALLELISM parameter specifies the number of processes or
threads used by the load utility to write data records to disk. Use this
parameter to exploit available containers when loading data, and
significantly improve load performance. The maximum number allowed is
the greater of four times the CPU_PARALLELISM value (actually used by
the load utility), or 50. By default, DISK_PARALLELISM is equal to the
sum of the table space containers on all table spaces containing objects for
the table being loaded, except where this value exceeds the maximum
number allowed.
NONRECOVERABLE
If forward recovery is enabled, use this parameter if you do not need to be

Chapter 4. Load utility 171

 able to recover load transactions against a table upon rollforward. A
NONRECOVERABLE load and a COPY NO load have identical
performance. However, there is a significant difference in terms of potential
data loss. A NONRECOVERABLE load marks a table as not rollforward
recoverable while leaving the table fully accessible. This can create a
problematic situation in which if you need to rollforward through the load
operation, then the loaded data as well as all subsequent updates to the
table will be lost. A COPY NO load places all dependent table spaces in
the Backup Pending state which renders the table inaccessible until a
backup is performed. Because you are forced to take a backup after that
type of load, you will not risk losing the loaded data or subsequent
updates to the table. That is to say, a COPY NO load is totally recoverable.

Note: When these load transactions are encountered during subsequent

restore and rollforward recovery operations, the table is not updated, and
is marked invalid. Further actions against this table are ignored. After the
rollforward operation is complete, the table can only be dropped.
SAVECOUNT
Use this parameter to set an interval for the establishment of consistency
points during the load phase of a load operation. The synchronization of
activities performed to establish a consistency point takes time. If done too
frequently, there is a noticeable reduction in load performance. If a very
large number of rows is to be loaded, it is recommended that a large
SAVECOUNT value be specified (for example, a value of 10 million in the
case of a load operation involving 100 million records).
A load restart operation automatically continues from the last consistency
point, provided that the load restart operation resumes from the load
phase.
STATISTICS USE PROFILE
Collect statistics specified in table statistics profile. Use this parameter to
collect data distribution and index statistics more efficiently than through
invocation of the RUNSTATS utility following completion of the load
operation, even though performance of the load operation itself decreases
(particularly when DETAILED INDEXES ALL is specified).
For optimal performance, applications require the best data distribution
and index statistics possible. Once the statistics are updated, applications
can use new access paths to the table data based on the latest statistics.
New access paths to a table can be created by rebinding the application
packages using the BIND command. The table statistics profile is created
by running the RUNSTATS command with the SET PROFILE options.
When loading data into large tables, it is recommended that a larger value
for the stat_heap_sz (statistics heap size) database configuration parameter
be specified.
USE <tablespace-name>
When an ALLOW READ ACCESS load is taking place and the indexing
mode is REBUILD, this parameter allows an index to be rebuilt in a system
temporary table space and copied back to the index table space during the
index copy phase of a load operation.
By default, the fully rebuilt index (also known as the shadow index) is built
in the same table space as the original index. This might cause resource
problems as both the original and the shadow index reside in the same
table space simultaneously. If the shadow index is built in the same table

172 Data Movement Utilities Guide and Reference

 space as the original index, the original index is instantaneously replaced
by the shadow. However, if the shadow index is built in a system
temporary table space, the load operation requires an index copy phase
which copies the index from a system temporary table space to the index
table space. There is considerable I/O involved in the copy. If either of the
table spaces is a DMS table space, the I/O on the system temporary table
space might not be sequential. The values specified by the
DISK_PARALLELISM option are respected during the index copy phase.
WARNINGCOUNT
Use this parameter to specify the number of warnings that can be returned
by the utility before a load operation is forced to terminate. Set the
WARNINGCOUNT parameter to a relatively low number if you are
expecting only a few or no warnings. The load operation stops after the
WARNINGCOUNT number is reached. This gives you the opportunity to
correct problems before attempting to complete the load operation.

File type modifiers

ANYORDER
By default, the load utility preserves record order of source data. When load is
operating under an SMP environment, synchronization between parallel processing
is required to ensure that order is preserved.

In an SMP environment, specifying the anyorder file type modifier instructs the
load utility to not preserve the order, which improves efficiency by avoiding the
synchronization necessary to preserve that order. However, if the data to be loaded
is presorted, anyorder might corrupt the presorted order, and the benefits of
presorting are lost for subsequent queries.

Note: The anyorder file type modifier has no effect if CPU_PARALLELISM is 1,

and it is not compatible with the SAVECOUNT option.

BINARYNUMERICS, ZONEDDECIMAL and PACKEDDECIMAL

For fixed length non-delimited ASCII (ASC) source data, representing numeric data
in binary can result in improved performance when loading. If the packeddecimal
file type modifier is specified, decimal data is interpreted by the load utility to be
in packed decimal format (two digits per byte). If the zoneddecimal file type
modifier is specified, decimal data is interpreted by the load utility to be in zoned
decimal format (one digit per byte). For all other numeric types, if the
binarynumerics file type modifier is specified, data is interpreted by the load
utility to be in binary format.

Note:
v When the binarynumerics, packeddecimal, or zoneddecimal file type modifiers
are specified, numeric data is interpreted in big-endian (high byte first) format,
regardless of platform.
v The packeddecimal and zoneddecimal file type modifiers are mutually exclusive.
v The packeddecimal and zoneddecimal file type modifiers only apply to the
decimal target columns, and the binary data must match the target column
definitions.
v The reclen file type modifier must be specified when the binarynumerics,
packeddecimal, or zoneddecimal file type modifiers are specified.

Chapter 4. Load utility 173

 FASTPARSE
Use with caution. In situations where the data being loaded is known to be valid,
it can be unnecessary to have load perform the same amount of syntax checking as
with more suspect data. In fact, decreasing the scope of this step can improve
load's performance by about 10 or 20 percent. This can be done by using the
fastparse file type modifier, which reduces the data checking that is performed on
user-supplied column values from ASC and DEL files.

NOROWWARNINGS
During a load operation, warning messages about rejected rows are written to a
specified file. However, if the load utility has to process a large volume of rejected,
invalid or truncated records, it can adversely affect load's performance. In cases
where many warnings are anticipated, it is useful to use the norowwarnings file
type modifier to suppress the recording of these warnings.

PAGEFREESPACE, INDEXFREESPACE, and TOTALFREESPACE

As data is inserted and updated in tables over time, the need for table and index
reorganization grows. One solution is to increase the amount of free space for
tables and indexes using pagefreespace, indexfreespace, and totalfreespace. The
first two modifiers, which take precedence over the PCTFREE value, specify the
percentage of data and index pages that is to be left as free space, while
totalfreespace specifies the percentage of the total number of pages that is to be
appended to the table as free space.

Load features for maintaining referential integrity

Although the load utility is typically more efficient than the import utility, it
requires a number of features to ensure the referential integrity of the information
being loaded:
v Table locks, which provide concurrency control and prevent uncontrolled data
access during a load operation
v Table states and table space states, which can either control access to data or
elicit specific user actions
v Load exception tables, which ensure that rows of invalid data are not simply
deleted without your knowledge

Checking for integrity violations following a load operation

Following a load operation, the loaded table might be in set integrity pending state
in either READ or NO ACCESS mode if any of the following conditions exist:
v The table has table check constraints or referential integrity constraints defined
on it.
v The table has generated columns and a V7 or earlier client was used to initiate
the load operation.
v The table has descendent immediate materialized query tables or descendent
immediate staging tables referencing it.
v The table is a staging table or a materialized query table.
The STATUS flag of the SYSCAT.TABLES entry corresponding to the loaded table
indicates the set integrity pending state of the table. For the loaded table to be
fully usable, the STATUS must have a value of N and the ACCESS MODE must have a
value of F, indicating that the table is fully accessible and in normal state.

174 Data Movement Utilities Guide and Reference

If the loaded table has descendent tables, the SET INTEGRITY PENDING
CASCADE parameter can be specified to indicate whether or not the set integrity
pending state of the loaded table should be immediately cascaded to the
descendent tables.

If the loaded table has constraints as well as descendent foreign key tables,
dependent materialized query tables and dependent staging tables, and if all of the
tables are in normal state prior to the load operation, the following will result
based on the load parameters specified:
INSERT, ALLOW READ ACCESS, and SET INTEGRITY PENDING CASCADE
IMMEDIATE
The loaded table, its dependent materialized query tables and dependent
staging tables are placed in set integrity pending state with read access.
INSERT, ALLOW READ ACCESS, and SET INTEGRITY PENDING CASCADE
DEFERRED
Only the loaded table is placed in set integrity pending with read access.
Descendent foreign key tables, descendent materialized query tables and
descendent staging tables remain in their original states.
INSERT, ALLOW NO ACCESS, and SET INTEGRITY PENDING CASCADE
IMMEDIATE
The loaded table, its dependent materialized query tables and dependent
staging tables are placed in set integrity pending state with no access.
INSERT or REPLACE, ALLOW NO ACCESS, and SET INTEGRITY PENDING
CASCADE DEFERRED
Only the loaded table is placed in set integrity pending state with no
access. Descendent foreign key tables, descendent immediate materialized
query tables and descendent immediate staging tables remain in their
original states.
REPLACE, ALLOW NO ACCESS, and SET INTEGRITY PENDING CASCADE
IMMEDIATE
The table and all its descendent foreign key tables, descendent immediate
materialized query tables, and descendent immediate staging tables are
placed in set integrity pending state with no access.

Note: Specifying the ALLOW READ ACCESS option in a load replace operation
results in an error.

To remove the set integrity pending state, use the SET INTEGRITY statement. The
SET INTEGRITY statement checks a table for constraints violations, and takes the
table out of set integrity pending state. If all the load operations are performed in
INSERT mode, the SET INTEGRITY statement can be used to incrementally process
the constraints (that is, it checks only the appended portion of the table for
constraints violations). For example:
db2 load from infile1.ixf of ixf insert into table1
db2 set integrity for table1 immediate checked

Only the appended portion of TABLE1 is checked for constraint violations.

Checking only the appended portion for constraints violations is faster than
checking the entire table, especially in the case of a large table with small amounts
of appended data.

If a table is loaded with the SET INTEGRITY PENDING CASCADE DEFERRED

option specified, and the SET INTEGRITY statement is used to check for integrity

Chapter 4. Load utility 175

 violations, the descendent tables are placed in set integrity pending state with no
access. To take the tables out of this state, you must issue an explicit request.

If a table with dependent materialized query tables or dependent staging tables is

loaded using the INSERT option, and the SET INTEGRITY statement is used to
check for integrity violations, the table is taken out of set integrity pending state
and placed in No Data Movement state. This is done to facilitate the subsequent
incremental refreshes of the dependent materialized query tables and the
incremental propagation of the dependent staging tables. In the No Data
Movement state, operations that might cause the movement of rows within the
table are not allowed.

You can override the No Data Movement state by specifying the FULL ACCESS
option when you issue the SET INTEGRITY statement. The table is fully accessible,
however a full re-computation of the dependent materialized query tables takes
place in subsequent REFRESH TABLE statements and the dependent staging tables
are forced into an incomplete state.

If the ALLOW READ ACCESS option is specified for a load operation, the table
remains in read access state until the SET INTEGRITY statement is used to check
for constraints violations. Applications can query the table for data that existed
prior to the load operation once it has been committed, but will not be able to
view the newly loaded data until the SET INTEGRITY statement is issued.

Several load operations can take place on a table before checking for constraints
violations. If all of the load operations are completed in ALLOW READ ACCESS
mode, only the data that existed in the table prior to the first load operation is
available for queries.

One or more tables can be checked in a single invocation of this statement. If a

dependent table is to be checked on its own, the parent table can not be in set
integrity pending state. Otherwise, both the parent table and the dependent table
must be checked at the same time. In the case of a referential integrity cycle, all the
tables involved in the cycle must be included in a single invocation of the SET
INTEGRITY statement. It might be convenient to check the parent table for
constraints violations while a dependent table is being loaded. This can only occur
if the two tables are not in the same table space.

When issuing the SET INTEGRITY statement, you can specify the INCREMENTAL
option to explicitly request incremental processing. In most cases, this option is not
needed, because the DB2 database selects incremental processing. If incremental
processing is not possible, full processing is used automatically. When the
INCREMENTAL option is specified, but incremental processing is not possible, an
error is returned if:
v New constraints are added to the table while it is in set integrity pending state.
v A load replace operation takes place, or the NOT LOGGED INITIALLY WITH
EMPTY TABLE option is activated, after the last integrity check on the table.
v A parent table is load replaced or checked for integrity non-incrementally.
v The table is in set integrity pending state before migration. Full processing is
required the first time the table is checked for integrity after migration.
v The table space containing the table or its parent is rolled forward to a point in
time and the table and its parent reside in different table spaces.

If a table has one or more W values in the CONST_CHECKED column of the

SYSCAT.TABLES catalog, and if the NOT INCREMENTAL option is not specified

176 Data Movement Utilities Guide and Reference

 in the SET INTEGRITY statement, the table is incrementally processed and the
CONST_CHECKED column of SYSCAT.TABLES is marked as U to indicate that not
all data has been verified by the system.

The SET INTEGRITY statement does not activate any DELETE triggers as a result
of deleting rows that violate constraints, but once the table is removed from set
integrity pending state, triggers are active. Thus, if you correct data and insert
rows from the exception table into the loaded table, any INSERT triggers defined
on the table are activated. The implications of this should be considered. One
option is to drop the INSERT trigger, insert rows from the exception table, and
then recreate the INSERT trigger.

Checking for constraint violations using SET INTEGRITY

Typically, you need to manually perform integrity processing for a table in three
situations: After loading data into a table; when altering a table by adding
constraints on the table; and when altering a table to add a generated column.

Before you begin

v To turn on constraint checking for a table and performing integrity processing
on the table, you need one of the following:
– SYSADM or DBADM authority
– CONTROL privileges on the tables being checked, and if exceptions are being
posted to one or more tables, INSERT privilege on the exception tables
– CONTROL privilege on all descendent foreign key tables, descendent
immediate materialized query tables, and descendent immediate staging
tables that will implicitly be placed in the Set Integrity Pending state by the
statement
– LOAD authority, and if exceptions are being posted to one or more tables:
- SELECT and DELETE privilege on each table being checked
- INSERT privilege on the exception tables
v To turn on constraint checking for a table without performing integrity
processing on the table, you need one of the following:
– SYSADM or DBADM authority
– CONTROL privileges on the tables being checked
– CONTROL privilege on each descendent foreign key table, descendent
immediate materialized query table, and descendent immediate staging table
that will implicitly be placed in the Set Integrity Pending state by the
statement
v To turn off constraint checking, immediate refreshing, or immediate propagation
for tables, you need one of the following:
– SYSADM or DBADM authority
– CONTROL privilege on the table, and on all descendent foreign key tables,
descendent immediate materialized query tables, and descendent immediate
staging tables that will have their integrity checking turned off by the
statement
– LOAD authority

About this task

The load operation causes a table to be put into Set Integrity Pending state
automatically if the table has constraints defined on it or if it has dependent
foreign key tables, dependent materialized query tables, or dependent staging

Chapter 4. Load utility 177

 tables. When the load operation is completed, you can verify the integrity of the
loaded data and you can turn on constraint checking for the table. If the table has
dependent foreign key tables, dependent materialized query tables, or dependent
staging tables, they will be automatically put into Set Integrity Pending state. You
will need to use the Set Integrity window to perform separate integrity processing
on each of these tables.

If you are altering a table by adding a foreign key, a check constraint or a

generated column, you need to turn off constraint checking before you alter the
table. After you add the constraint, you need to check the existing data for
violations to the newly added constraint and you need to turn constraint checking
back on. In addition, if you are loading data into the table, you cannot activate
constraint checking on the table until you complete loading data into it. If you are
importing data into the table, you should activate constraint checking on the table
before you import data into it.

Constraints checking refers to checking for constraints violations, foreign key

violations, and generated columns violations. Integrity processing refers to
populating identity and generated columns, refreshing materialized query tables,
and propagating to staging tables, in addition to performing constraints checking.

Normally, referential integrity and check constraints on a table are automatically

enforced, materialized query tables are automatically refreshed immediately, and
staging tables are automatically propagated. In some situations, you might need to
manually change this behavior.

To check for constraint violations using the Control Center:

1. Open the Set Integrity window: From the Control Center, expand the object tree
until you find the Tables folder. Click on the Tables folder. Any existing tables
are displayed in the pane on the right side of the window. Right-click the table
you want and select Set Integrity from the pop-up menu. The Set Integrity
window opens.
2. Review the Current Integrity Status of the table you are working with.
3. To turn on constraint checking for a table and not check the table data:
a. Select the Immediate and unchecked radio button.
b. Specify the type of integrity processing that you are turning on.
c. Select the Full Access radio button to immediately perform data movement
operations against the table (such as reorganize or redistribute). However,
note that subsequent refreshes of dependent materialized query tables will
take longer. If the table has an associated materialized query table, it is
recommended that you do not select this radio button in order to reduce the
time needed to refresh the materialized query table.
4. To turn on constraint checking for a table and check the existing table data:
a. Select the Immediate and checked radio button.
b. Select which type of integrity processing that you want to perform. If the
Current integrity status shows that the constraints checked value for the
materialized query table is incomplete, you cannot incrementally refresh the
materialized query table.
c. Optional: If you want identity or generated columns to be populated during
integrity processing, select the Force generated check box.
d. If the table is not a staging table, make sure that the Prune check box is
unchecked.

178 Data Movement Utilities Guide and Reference

 e. Select the Full Access radio button to immediately perform data movement
operations against the table.
f. Optional: Specify an exception table. Any row that is in violation of a
referential or check constraint will be deleted from your table and copied to
the exception table. If you do not specify an exception table, when a
constraint is violated, only the first violation detected is returned to you and
the table is left in the Set Integrity Pending state.
5. To turn off constraint checking, immediate refreshing, or immediate
propagation for a table:
a. Select the Off radio button. The table will be put in Set Integrity Pending
state.
b. Use the Cascade option to specify whether you want to cascade
immediately or defer cascading. If you are cascading immediately, use the
Materialized Query Tables, Foreign Key Tables, and Staging Tables check
boxes to indicate the tables to which you want to cascade.

Note: If you turn off constraint checking for a parent table and specify that
you want to cascade the changes to foreign key tables, the foreign key
constraints of all of its descendent foreign key tables are also turned off. If
you turn off constraint checking for a underlying table and specify that you
want to cascade the check pending state to materialized query tables, the
refresh immediate properties of all its dependent materialized query tables
are also turned off. If you turn off constraint checking for a underlying table
and specify that you want to cascade the Set Integrity Pending state to
staging tables the propagate immediate properties of all its dependent
staging tables are also turned off.

To check for constraint violations using the command line, use the SET
INTEGRITY statement.

Troubleshooting tip
Symptom
You receive the following error message when you try to turn on
constraints checking, immediate refresh, or immediate propagation for a
table:
DB2 Message
Cannot check a dependent table TABLE1 using the SET
INTEGRITY statement while the parent table or underlying table
TABLE2 is in the Set Integrity Pending state or if it will be put into
the Set Integrity Pending state by the SET INTEGRITY statement.
Where TABLE1 is the table for which you are trying to turn on
constraints checking, immediate refresh, or immediate propagation
and it is dependent on TABLE2.
Possible cause
Constraint checking, immediate refresh, or immediate propagation cannot
be turned on for a table that has a parent or underlying table in Set
Integrity Pending.
Action
Bring the parent or underlying table out of Set Integrity Pending by
turning on constraint checking for the table. Begin with the table identified
as the parent or underlying table in the DB2 message. If that table is

Chapter 4. Load utility 179

 dependent on another table, you need to turn on constraint checking in a
top-down approach from the table at the top of the dependency chain.

Attention: If the selected table has a cyclical referential constraint

relationship with one or more tables, you cannot use the Set Integrity
window to turn on constraint checking. In this case, you must use the
Command Editor to issue the SQL SET INTEGRITY command.

Table locking during load operations

In most cases, the load utility uses table level locking to restrict access to tables.
The level of locking depends on the stage of the load operation and whether it was
specified to allow read access.

A load operation in ALLOW NO ACCESS mode uses a super exclusive lock

(Z-lock) on the table for the duration of the load.

Before a load operation in ALLOW READ ACCESS mode begins, the load utility
waits for all applications that began before the load operation to release their locks
on the target table. At the beginning of the load operation, the load utility acquires
an update lock (U-lock) on the table. It holds this lock until the data is being
committed. When the load utility acquires the U-lock on the table, it waits for all
applications that hold locks on the table prior to the start of the load operation to
release them, even if they have compatible locks. This is achieved by temporarily
upgrading the U-lock to a Z-lock which does not conflict with new table lock
requests on the target table as long as the requested locks are compatible with the
load operation's U-lock. When data is being committed, the load utility upgrades
the lock to a Z-lock, so there can be some delay in commit time while the load
utility waits for applications with conflicting locks to finish.

Note: The load operation can time out while it waits for the applications to release
their locks on the table prior to loading. However, the load operation does not time
out while waiting for the Z-lock needed to commit the data.

Applications with conflicting locks

Use the LOCK WITH FORCE option of the LOAD command to force off
applications holding conflicting locks on a target table so that the load operation
can proceed. Before a load operation in ALLOW READ ACCESS mode can
proceed, applications holding the following locks are forced off:
v Table locks that conflict with a table update lock (for example, import or insert).
v All table locks that exist at the commit phase of the load operation.

Applications holding conflicting locks on the system catalog tables are not forced
off by the load utility. If an application is forced off the system by the load utility,
the application loses its database connection, and an error is returned (SQL1224N).

When you specify the COPY NO option for a load operation on a recoverable
database, all objects in the target table space are locked in share mode before the
table space is placed in the Backup Pending state. This occurs regardless of the
access mode. If you specify the LOCK WITH FORCE option, all applications
holding locks on objects in the table space that conflict with a share lock are forced
off.

180 Data Movement Utilities Guide and Reference

Read access load operations
The load utility provides two options that control the amount of access other
applications have to a table being loaded. The ALLOW NO ACCESS option locks
the table exclusively and allows no access to the table data while the table is being
loaded.

The ALLOW NO ACCESS option is the default behavior. The ALLOW READ
ACCESS option prevents all write access to the table by other applications, but
allows read access to preexisting data. This section deals with the ALLOW READ
ACCESS option.

Table data and index data that exist prior to the start of a load operation are visible
to queries while the load operation is in progress. Consider the following example:
1. Create a table with one integer column:
create table ED (ed int)
2. Load three rows:
load from File1 of del insert into ED
...
Number of rows read = 3
Number of rows skipped = 0
Number of rows loaded = 3
Number of rows rejected = 0
Number of rows deleted = 0
Number of rows committed = 3
3. Query the table:
select * from ED

ED
-----------
1
2
3

3 record(s) selected.
4. Perform a load operation with the ALLOW READ ACCESS option specified
and load two more rows of data:
load from File2 of del insert into ED allow read access
5. At the same time, on another connection query the table while the load
operation is in progress:
select * from ED

ED
-----------
1
2
3

3 record(s) selected.
6. Wait for the load operation to finish and then query the table:
select * from ED

ED
-----------
1
2
3

Chapter 4. Load utility 181

 4
5

5 record(s) selected.

The ALLOW READ ACCESS option is very useful when loading large amounts of
data because it gives users access to table data at all times, even when the load
operation is in progress or after a load operation has failed. The behavior of a load
operation in ALLOW READ ACCESS mode is independent of the isolation level of
the application. That is, readers with any isolation level can always read the
preexisting data, but they are not be able to read the newly loaded data until the
load operation has finished.

Read access is provided throughout the load operation except for two instances: at
the beginning and at the end of the operation.

Firstly, the load operation acquires a special Z-lock for a short duration of time
near the end of its setup phase. If an application holds an incompatible lock on the
table prior to the load operation requesting this special Z-lock, then the load
operation waits a finite amount of time for this incompatible lock to be released
before timing out and failing. The amount of time is determined by the locktimeout
database configuration parameter. If the LOCK WITH FORCE option is specified
then the load operation forces other applications off to avoid timing out. The load
operation acquires the special Z-lock, commits the phase, releases the lock, and
then continues onto the load phase. Any application that requests a lock on the
table for reading after the start of the load operation in ALLOW READ ACCESS
mode is granted the lock, and it does not conflict with this special Z-lock. New
applications attempting to read existing data from the target table are able to do
so.

Secondly, before data is committed at the end of the load operation, the load utility
acquires an exclusive lock (Z-lock) on the table. The load utility waits until all
applications that hold locks on the table release them. This can cause a delay
before the data is committed. The LOCK WITH FORCE option is used to force off
conflicting applications, and allow the load operation to proceed without having to
wait. Usually, a load operation in ALLOW READ ACCESS mode acquires an
exclusive lock for a short amount of time; however, if the USE <tablespace-name>
option is specified, the exclusive lock lasts for the entire period of the index copy
phase.

When the load utility is running against a table defined on multiple database
partitions, the load process model executes on each individual database partition,
meaning that locks are acquired and released independently of other db-partitions.
Thus, if a query or other operation is executed concurrently and is competing for
the same locks, there is a chance for deadlocks. For example, suppose that
operation A is granted a table lock on db-partition 0 and the load operation is
granted a table lock on db-partition 1. A deadlock can occur because operation A is
waiting to be granted a table lock on db-partition 1, while the load operation is
waiting for a table lock on db-partition 0. In this case, the deadlock detector will
arbitrarily roll back one of the operations.

Note:
1. If a load operation is interrupted or fails, it remains at the same access level
that was specified when the load operation was issued. That is, if a load
operation in ALLOW NO ACCESS mode fails, the table data is inaccessible

182 Data Movement Utilities Guide and Reference

 until a load terminate or a load restart is issued. If a load operation in ALLOW
READ ACCESS mode aborts, the preexisting table data is still accessible for
read access.
2. If the ALLOW READ ACCESS option was specified for an interrupted or failed
load operation, it can also be specified for the load restart or load terminate
operation. However, if the interrupted or failed load operation specified the
ALLOW NO ACCESS option, the ALLOW READ ACCESS option cannot be
specified for the load restart or load terminate operation.

The ALLOW READ ACCESS option is not supported if:

v The REPLACE option is specified. Since a load replace operation truncates the
existing table data before loading the new data, there is no preexisting data to
query until after the load operation is complete.
v The indexes have been marked invalid and are waiting to be rebuilt. Indexes can
be marked invalid in some rollforward scenarios or through the use of the
db2dart command.
v The INDEXING MODE DEFERRED option is specified. This mode marks the
indexes as requiring a rebuild.
v An ALLOW NO ACCESS load operation is being restarted or terminated. Until
it is brought fully online, a load operation in ALLOW READ ACCESS mode
cannot take place on the table.
v A load operation is taking place to a table that is in Set Integrity Pending No
Access state. This is also the case for multiple load operations on tables with
constraints. A table is not brought online until the SET INTEGRITY statement is
issued.

Generally, if table data is taken offline, read access is not available during a load
operation until the table data is back online.

Table space states during and after load operations

The load utility uses table space states to preserve database consistency during a
load operation. These states work by controlling access to data or eliciting user
actions.

The load utility does not quiesce (put persistent locks on) the table spaces involved
in the load operation and uses table space states only for load operations for which
you specify the COPY NO parameter.

You can check table space states by using the LIST TABLESPACES command. Table
spaces can be in multiple states simultaneously. The states returned by LIST
TABLESPACES are as follows:

Normal
The Normal state is the initial state of a table space after it is created, indicating
that no (abnormal) states currently affect it.

Load in Progress
The Load in Progress state indicates that there is a load in progress on the table
space. This state prevents the backup of dependent tables during the load. The
table space state is distinct from the Load in Progress table state (which is used in
all load operations) because the load utility places table spaces in the Load in
Progress state only when you specify the COPY NO parameter for a recoverable
database. The table spaces remain in this state for the duration of the load
operation.

Chapter 4. Load utility 183

 Backup Pending
If you perform a load operation for a recoverable database and specify the COPY
NO parameter, table spaces are placed in the Backup Pending table space state
after the first commit. You cannot update a table space in the Backup Pending
state. You can remove the table space from the Backup Pending state only by
backing up the table space. Even if you cancel the load operation, the table space
remains in the Backup Pending state because the table space state is changed at the
beginning of the load operation and cannot be rolled back.

Restore Pending
If you perform a successful load operation with the COPY NO option, restore the
database, and then rollforward through that operation, the associated table spaces
are placed in the Restore Pending state. To remove the table spaces from the
Restore Pending state, you must perform a restore operation.

Example of a table space state

If you load an input file (staffdata.del) into a table NEWSTAFF, as follows:

update db cfg for sample using logretain recovery;
backup db sample;
connect to sample;
create table newstaff like staff;
load from staffdata.del of del insert into newstaff copy no;
connect reset;

and you open another session and issue the following commands,
connect to sample;
list tablespaces;
connect reset;

USERSPACE1 (the default table space for the sample database) is in the Load in
Progress state and, after the first commit, the Backup Pending state as well. After
the load operation finishes, the LIST TABLESPACES command reveals that
USERSPACE1 is now in the Backup Pending state:
Tablespace ID = 2
Name = USERSPACE1
Type = Database managed space
Contents = All permanent data. Large table space.
State = 0x0020
Detailed explanation:
Backup pending

Table states during and after load operations

The load utility uses table states to preserve database consistency during a load
operation. These states work by controlling access to data or eliciting user actions.

To determine the state of a table, issue the LOAD QUERY command, which also
checks the status of a load operation. Tables can be in a number of states
simultaneously. The states returned by LOAD QUERY are as follows:

Normal State
The Normal state is the initial state of a table after it is created, indicating that no
(abnormal) states currently affect the table.

Read Access Only

If you specify the ALLOW READ ACCESS option, the table is in the Read Access
Only state. The data in the table that existed prior to the invocation of the load

184 Data Movement Utilities Guide and Reference

command is available in read-only mode during the load operation. If you specify
the ALLOW READ ACCESS option and the load operation fails, the data that
existed in the table prior to the load operation continues to be available in
read-only mode after the failure.

Load in Progress
The Load in Progress table state indicates that there is a load in progress on the
table. The load utility removes this transient state after the load is successfully
completed. However, if the load operation fails or is interrupted, the table state
will change to Load Pending.

Redistribute in Progress
The Redistribute in Progress table state indicates that there is a redistribute in
progress on the table. The redistribute utility removes this transient state after it
has successfully completed processing the table. However, if the redistribute
operation fails or is interrupted, the table state will change to Redistribute Pending.

Load Pending
The Load Pending table state indicates that a load operation failed or was
interrupted. You can take one of the following steps to remove the Load Pending
state:
v Address the cause of the failure. For example, if the load utility ran out of disk
space, add containers to the table space. Then, restart the load operation.
v Terminate the load operation.
v Run a load REPLACE operation against the same table on which the load
operation failed.
v Recover table spaces for the loading table by using the RESTORE DATABASE
command with the most recent table space or database backup, then carry out
further recovery actions.

Redistribute Pending
The Redistribute Pending table state indicates that a redistribute operation failed or
was interrupted. You can perform a REDISTRIBUTE CONTINUE or
REDISTRIBUTE ABORT operation to remove the Redistribute Pending state.

Not Load Restartable

In the Not Load Restartable state, a table is partially loaded and does not allow a
load restart operation. There are two situations in which a table is placed in the
Not Load Restartable state:
v If you perform a rollforward operation after a failed load operation that you
could not successfully restart or terminate
v If you perform a restore operation from an online backup that you took while
the table was in the Load in Progress or Load Pending state
The table is also in the Load Pending state. To remove the table from the Not Load
Restartable state, issue the LOAD TERMINATE or the LOAD REPLACE command.

Set Integrity Pending

The Set Integrity Pending state indicates that the loaded table has constraints
which have not yet been verified. The load utility places a table in this state when
it begins a load operation on a table with constraints. Use the SET INTEGRITY
statement to take the table out of Set Integrity Pending state.

Type-1 Indexes
The Type-1 Indexes state indicates that the table currently uses type-1 indexes,

Chapter 4. Load utility 185

 which have been deprecated. The indexes can be converted to type-2 using the
CONVERT option when using the REORG utility on the indexes.

Unavailable
Rolling forward through an unrecoverable load operation places a table in the
Unavailable state. In this state, the table is unavailable; you must drop it or restore
it from a backup.

Example of a table in multiple states

If you load an input file (staffdata.del) with a substantial amount of data into a
table NEWSTAFF, as follows: