Filter
Top Products
Data Consistency, Recovery, and Migration 4-13
Recovering from Corruption
OnLine alerts the user and administrator to possible corruption through the
following means:
■ Error messages reported to the application state that pages, tables, or
databases cannot be found. The following message:
-105 ISAM error: bad isam file format
is always returned to the application if an operation has failed
because of an inconsistency in the underlying data or control
information.
■ Consistency-checking messages are written to the OnLine message
log. The following message:
Fail Consistency Check
includes diagnostic information that can help you determine the
source of the problem.
■ The tbcheck utility returns errors.
Corrective actions for tbcheck errors are described, by tbcheck
option, beginning on page 4-6.
At the first indication of corruption, run tbcheck -cI to determine if
corruption exists in the index. If you run tbcheck -cI in online mode, tbcheck
detects the corruption but does not prompt you for repairs. If corruption
exists, you can drop and re-create the indexes using SQL statements while
you are in online mode. If you run tbcheck -cI in quiescent mode and
corruption is detected, tbcheck prompts you to confirm whether the utility
should attempt to repair the corruption.
If tbcheck reports bad key information in an index, drop the index and re-
create it.
If tbcheck is unable to find or access the table or database, verify the UNIX
permissions on the device (chunk) where the table resides. If permissions are
not the source of the problem, the chunk might be down. (Refer to page 1-48
for more details about the proper device permissions.)
If an I/O error occurs during OnLine operation, the status of the chunk on
which the error occurred changes to down. If a chunk is down, the tbstat -d
display shows the chunk status as PD- for a primary chunk and MD- for a
mirror chunk. A message written to the OnLine message log contains the
UNIX error number that identifies the cause of the I/O error.