SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

ERROR[8580] No partitions of table could be accessed
DUP versus FASTCOPY
Table 15 (page 210) lists the differences between the DUP and FASTCOPY commands.
Table 15 Difference Between DUP and FASTCOPY Commands
FASTCOPYDUP
Copies tables and indexes conveniently using a single command. Also, it might
copy tables and indexes using separate commands.
Copies tables and indexes in a
single command.
Requires the target table to exist in advance, and to be similar but not necessarily
identical to the source table based on the following aspects:
Creates the target table identical
to the source table.
• number of columns must be the same in source and target tables
• column data types must be compatible between columns with the same ordinal
position in the row
• either both tables have a system-defined SYSKEY column, or none of them have
a SYSKEY column
• if the target table has indexes, the following details must match in the source and
target tables:
◦ clustering key specifications
◦ index column specifications
Copies tables and indexes slower but in an efficient and flexible manner.Copies tables and indexes faster
but in an inflexible manner.
Using PURGEDATA to Delete Data From Tables
PURGEDATA is a syntax-based utility you can execute from MXCI to delete data from a table and
its related index or from the specified partitions of a table that has no index.
For more information, see the SQL/MX Reference Manual.
Guidelines for Using PURGEDATA
• The PURGEDATA requester must own the schema where the table resides, have SELECT and
DELETE privileges on the table being purged, or be the super ID user. An error is returned if
an access violation occurs.
• The table name you specify with PURGEDATA can exist in a catalog defined on a remote
node and be referenced by the current PURGEDATA operation if the remote node is visible
to the local node.
• If PURGEDATA fails because of a process, CPU, or system failure, use the RECOVER command
to resume the operation. RECOVER returns an error if it cannot resume the operation.
• PURGEDATA records operation progress steps in the DDL_LOCKS metadata table. Users can
query this table to determine the PURGEDATA operation’s progress. For more information,
see the SQL/MX Reference Manual and “Querying SQL/MX Metadata” (page 105).
• The PURGEDATA operation temporarily invalidates, by marking as corrupt, tables and indexes,
which prevents concurrent access by other users until the data is purged.
• After purging the data, the PURGEDATA operation validates the table and indexes by turning
off the corrupt flag so that they are again accessible to other users.
• The PURGEDATA operation does not automatically alter the table’s statistics. After purging
the data and after you (or any programs) have added data to the table, run an UPDATE
210 Reorganizing SQL/MX Tables and Maintaining Data