SQL/MX 3.x Installation and Management Guide (H06.22+, J06.11+)

Performing Recovery Operations
HP NonStop SQL/MX Installation and Management Guide—640325-001
12-34
Using FIXUP to Correct Problem Data and Objects
•
Audit bit
•
Broken bit
•
Corrupt bit
•
Redefinition timestamp
Changing the Audit Bit
SQL/MX tables are always created as audited. In some cases, you might need to use
FIXUP to turn off the audit bit to run a low-level DP2 utility operation, such as
TANDUMP. In other cases, after some utility operation has failed, the audit bit might be
left turned off, and you might need to turn the audit bit on before being able to access
the partition.
For example, when using DUP to duplicate a table, the target table is created as
nonaudited. If DUP fails after the data has been loaded but before the audit bit has
been turned on, you could turn on the audit bit and potentially use the new table. Of
course, you would have to verify that the data was loaded correctly. However, checking
the validity of the table can be less difficult than dropping and performing the DUP
operation a second time.
Changing the Broken Bit
Like the broken flag, the broken bit is set by DP2 when it detects that something is
wrong with the partition. After the problem with the partition is fixed, the broken bit
needs to be turned off to access the data. The ability to turn off the broken bit is
equivalent to using the ALTER TABLE … RESETBROKEN command in SQL/MP.
To fix a broken file, perform the steps listed in Recovering a Broken Partition on
page 12-33.
Changing the Corrupt Bit
The corrupt bit is set during some utility operations to prevent access to the object until
the operation has completed. If the operation fails before the corrupt bit is turned off,
the table is unusable. You might need to reset this bit if you determine that the table is
still usable.
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.