SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

is striped (partitioned) across 16 partitions. To maximize parallel execution, each partition is
associated with a different CPU.
The next example uses the import command each week to add the most recent week of data to
the appropriate 16 partitions. It starts an import process for each target partition (in each
associated CPU). You can enter the next import command from another OSS shell that is running
on another CPU.
The example divides the input data into 16 files. Each file’s data is appended to the corresponding
target partition. The input files reside on volumes $VOL1 through $VOL4. The target partitions
reside on volumes $VOL33 through $VOL48. The record layout corresponds exactly to the target
table layout.
The -l option ensures that the import operation proceeds even if an input record contains data
that cannot be parsed for loading into the target table.
/user/bin> import cat1.schema1.t1 -I /G/VOL33/TARGET/HIST01 -L 1000
/user/bin> import cat1.schema1.t1 -I /G/VOL33/TARGET/HIST02 -L 1000 T 1000
/user/bin> import cat1.schema1.t1 -I /G/VOL33/TARGET/HIST03 -L 1000 T 1000
.
.
.
/user/bin> import cat1.schema1.t1 -I /G/VOL33/TARGET/HIST16 -L 1000 T 1000
This example issues 16 similar import commands, one for each target partition. The append
operation executes in parallel against the 16 partitions.
Using DUP to Copy Tables Into Tables
DUP is a syntax-based utility you can execute from MXCI to copy a source table—and optionally
its index and constraints—into an existing target table.
For more information, see the SQL/MX Reference Manual.
Guidelines for Using DUP
• You must have select privileges for the source table and must own the structure where the
target table will reside. An error is returned if an access violation occurs.
• Referential integrity constraints and triggers are ignored.
• The catalog that defines the source table or tables can exist on a remote node and be
referenced by the current DUP operation if the remote node is visible to the local node. The
target table can also exist in a catalog and structure that reside on a visible remote node.
Finally, the Guardian files associated with the source and target tables can exist on remote
nodes if those nodes are visible from the local node. For more information, see “Managing
an SQL/MX Distributed Database” (page 263).
• DUP does not check disk space before running the request. You must confirm that enough disk
space is available before running the DUP request. Check the EOF field of FILE INFO or FUP
INFO to identify the size of each partition and determine whether there is sufficient disk space
for the partitions.
• DUP displays errors if the source table or target table and its dependent indexes cannot be
accessed or if the load fails in response to a resource or file system problem.
If the DUP operation fails because the DUP process does fails unexpectedly, use the RECOVER
command to complete or roll back the operation. If the DUP operation fails after all the data
has been successfully copied to the target objects, specify RECOVER with the RESUME option
to complete the DUP operation. If the DUP operation fails before the data is successfully copied,
specify RECOVER with the CANCEL option to roll back the DUP operation. You can access
this status information by reading the DDL_LOCK metadata table. If you specify the wrong
RECOVER operation, RECOVER reports this so that you can use the correct operation, possibly
with RECOVER...CANCEL. the RECOVER command, see the SQL/MX Reference Manual.
204 Reorganizing SQL/MX Tables and Maintaining Data