Home | Previous Page | Next Page   Fault Tolerance > Consistency Checking > Performing Periodic Consistency Checking >

Monitoring for Data Inconsistency

If the consistency-checking code detects an inconsistency during database server operation, an assertion failure is reported to the database server message log. (See the message-log chapter in the IBM Informix: Administrator's Reference.)

Assertion Failures in the Message Log and Dump Files

Figure 103 shows the form that assertion failures take in the message log.

Figure 103. Form of Assertion Failures in the Message Log
Assert Failed: Short description of what failed
   Who: Description of user/session/thread running at the time
   Result: State of the affected database server entity
   Action: What action the database server administrator should take
   See Also: file(s) containing additional diagnostics

The See Also: line contains one or more of the following filenames:

In all cases, xxx is a hexadecimal number common to all files associated with the assertion failures of a single thread. The files af.xxx, shmem.xxx, and gcore.xxx are in the directory that the ONCONFIG parameter DUMPDIR specifies.

The file af.xxx contains a copy of the assertion-failure message that was sent to the message log, as well as the contents of the current, relevant structures and data buffers.

The file shmem.xxx contains a complete copy of the database server shared memory at the time of the assertion failure, but only if the ONCONFIG parameter DUMPSHMEM is set to 1.

The file gcore.xxx contains a core dump of the database server virtual process on which the thread was running at the time, but only if the ONCONFIG parameter DUMPGCORE is set to 1 and your operating system supports the gcore utility. The core file contains a core dump of the database server virtual process on which the thread was running at the time, but only if the ONCONFIG parameter DUMPCORE is set to 1. The pathname for the core file is the directory from which the database server was last invoked.

Validating Table and Tablespace Data

To validate table and tablespace data, use the onutil CHECK DATA command on the database or table.

Most of the general assertion-failure messages are followed by additional information that usually includes the tblspace where the error was detected. If this check verifies the inconsistency, unload the data from the table, drop the table, re-create the table, and reload the data. Otherwise, no other action is needed.

In many cases, the database server stops immediately when an assertion fails. However, when failures appear to be specific to a table or smaller entity, the database server continues to run.

When an assertion fails because of inconsistencies on a data page that the database server accesses on behalf of a user, an error is also sent to the application process. The SQL error depends on the operation in progress. However, the ISAM error is almost always be either -105 or -172, as follows:

-105 ISAM error: bad isam file format 
-172 ISAM error: Unexpected internal error

For additional details about the objectives and contents of messages, see the chapter on message-log messages in the IBM Informix: Administrator's Reference.

Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]