Evaluating the Danger Level of a Database Problem

Evaluating the Danger Level of a Database Problem
Prev	I1–MUPIP INTEG Errors	Next

If you encounter an anomaly in your database or its operations, the following list may offer some help in determining your next course of action. The heading of each section indicates the level of urgency Fidelity Information Services attributes to those items listed below it.

Requires Immediate Attention

Block incorrectly marked free errors are very serious and lead to accelerating damage. They degenerate into block doubly-allocated errors, which are also very dangerous. A database with these errors should be closed immediately for repairs.
Any (structural) error in an index block is dangerous and should be repaired as soon as possible.

Repairs for such errors should also be performed on a database that has been closed to normal activity. The need for both of these actions occurring quickly arises from the likelihood of the bad index being used. Only if your knowledge of the application allows you to predict that a damaged area is used exclusively by restricted functions which are not active (e.g., monthly processing or purges) should you defer repairs.

Can Be Deferred

Any (structural) error in a data block (level 0) does not pose a threat of accelerating damage. However, level 0 errors may cause errors or unreliable behavior in the application.
Block "incorrectly marked busy" errors only result in database space becoming unavailable until the errors are corrected. An index block error generates incorrectly marked busy errors, because INTEG cannot process the descendants of the damaged index. Therefore, incorrectly marked busy errors should be corrected only after all other errors, except for bitmap errors, are corrected.
Any bitmap errors flag not only the incorrectly marked block, but also the associated bitmap, and sometimes the master map. Therefore, local and master map errors should be corrected only after all bitmap marked busy or free errors are corrected.
Transaction number errors usually impact only incremental and online backups.
File size errors can misdirect MUPIP but do not cause the GT.M run-time system to generate further errors. An exception is auto-extend, which may not work properly if there are file size errors.
Reference count errors and free block errors are informational only.

The following list of INTEG messages classifies error severity using the following codes, and refers you to a section identifying appropriate follow-up action.

A Access: prevents database access

B Benign: presents no risk of additional damage and has little or no effect on database performance

D Dangerous: presents a high risk that continuing updates may cause significant additional damage

I Index: if the block is an index block, continuing updates will be quite dangerous: treat as a D; if the block is a data block, continuing updates can only cause limited additional damage

T Transient: usually cleared by an update to the database

Repair Dangerous and Access errors immediately. You may assess the benefits of deferring correction of less severe errors until normally scheduled down-time.

MUPIP INTEG Error Messages

SEVERITY

ERROR MESSAGE

SECTION

Bad key name.

Bad numeric subscript.

Bad pointer value in directory.

Bitmap block number as pointer.

Block at incorrect level.

Block busy/free status unknown (local bitmap corrupted).

Block doubly allocated.

Block incorrectly marked busy.

Block incorrectly marked free.

Block larger than file block size.

Block pointer larger than file maximum.

Block pointer negative.

Block size equals zero.

Block size is greater than 64K.

Block size not a multiple of 512 bytes.

Block too small.

Block transaction number too large.

Blocks per local map is less than 512.

Blocks per local map is greater than 2K.

Blocks per local map is not a multiple of 512.

Cannot INTEG region across network.

Cannot determine access method;trying with BG.

Compression count not maximal.

Current tn and early tn are not equal.

Database for region rrr is already frozen, not INTEGing

Database requires flushing.

File size larger than block count would indicate.

File size smaller than block count would indicate.

File smaller than database header.

First record of block has nonzero compression count.

Free blocks counter in file header: nnn is incorrect, should be mmm.

Header indicates file creation did not complete.

Header indicates file is corrupt.

Header size not valid for database.

Block xxxx doubly allocated in index block.

Incorrect version of GT.M database.

Invalid mixing of global names.

Key greater than index key.

Key larger than database maximum.

Key larger than maximum allowed length.

Key too long.

Key too short.

Keys less than sibling's index key.

Keys out of order.

Last record of block has invalid size.

Last record of block has nonzero compression count.

Local bitmap incorrect.

Local map block level incorrect.

Map block too large.

Map block too small.

Map block transaction number too large.

Master bitmap incorrectly asserts this local map has free space.

Master bitmap incorrectly marks this local map full.

Master bitmap shows this map full, agreeing with disk local map.

Master bitmap shows this map full, agreeing with MUPIP INTEG.

Master bitmap shows this map full, in disagreement with both disk and mu_int result.

Master bitmap shows this map has space, agreeing with disk local map.

Master bitmap shows this map has space, agreeing with MUPIP INTEG.

Read error on bitmap.

Record has too large compression count.

Record too large.

Record too small.

Reference count should be zero, is nnn.

Root block number greater than last block number in file.

Root block number is a local bitmap number.

Root block number negative.

Root level higher than maximum.

Root level less than one.

Start VBN smaller than possible.

Total blocks equals zero.

Unable to verify that this is a database file.