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

For example, PURGEDATA sets the corrupt bit before deleting rows. If PURGEDATA fails before
deleting all rows, the corrupt bit remains set. If you determine that even though PURGEDATA failed
it is acceptable to use the table, you can reset the corrupt bit.
Changing the Redefinition Timestamp
The redefinition timestamp changes whenever a DDL change made on the object results in a structure
change. All partitions of a single object, including tables, views, indexes, and SQL worktables
must have the same redefinition timestamp. However, dependent objects can have their own distinct
redefinition time.
For example, this command creates table A with three partitions:
Create table tableA
(col1 int not null primary key, col2 char (20))
Partition (add first key (1000) location $vol1,
add first key (2000) location $vol2);
Table A also has a dependent index that contains two partitions:
Create index tableA_index1 on tableA (col2)
Partition (add first key ("m" location $vol1));
The three partitions on tableA must have the same redefinition timestamp. The two partitions on
index tableA_index1 must have the same redefinition timestamp. However, tableA can have a
different redefinition timestamp than index tableA_index1.
If one of the partitions of an object has a different timestamp than the others, use the FIXUP operation
to make them all the same (for example, when you restore a single partition of a table). If the
restored partition has a different redefinition timestamp than the rest of the object, use FIXUP to set
the redefinition timestamp to the correct value.
Changing Catalog, Schema, and Object UIDs
Every time a partition for a table or index is created, its related catalog, schema, and object UID
is stored in the resource fork. If accidentally dropping a table makes it necessary to recover the
table from scratch, you use the saved DDL information to recreate the table and recover the privileges
in the metadata, and then execute the TMF RECOVER FILES command to recover the file label,
data, and resource fork.
The new metadata will now have a new object UID, and the data and resource fork will have the
old object UID. Use the VERIFY command to confirm that the object UID in the metadata tables
does not match the object UID in the resource fork.
Use the FIXUP command with the -ru option to make the UID values in the resource fork match the
UID values in the metadata. FIXUP replaces the catalog, schema, and object UIDs in the resource
fork with the UIDs found in the metadata. For example:
mxtool FIXUP TABLE mycat.mysch.FIXUPtable -ru -d
For more information, see the SQL/MX Reference Manual.
Examples of Using FIXUP
Suppose that table1 is located in the catalog cat and the schema sch and has three partitions. Two
of the partitions are located on the local node, \local. The third partition is located on a remote
node, \remote, and contains a trigger that requires a trigger temporary table, which is located on
the local node. Two indexes are also associated with the table: index1 and index2. Each index
has three partitions organized similarly to those of the table.
1. Create three partitions with these names:
• \LOCAL.$DATA02.ZSD1123U.SUEIFO00
• \LOCAL.$DATA01.ZSD1123U.SUEIGO00
• \REMOTE.$DATA01.ZSD1123U.SUEIHO00
Repairing Damaged SQL/MX Metadata and Objects 261