Skip to content

Chapter11.Maintaining Database Integrity

Chapter11.Maintaining Database Integrity

Table of Contents

Verifying Database Integrity
Regularly Scheduled Verification

Before or After Major Transfers

Immediately after Catastrophic Events

Immediately after Run-Time Database Errors

Immediately After Database Repairs

Approaches to Database Recovery
Recover from Journals

Restore from Backup

Repair with DSE

Preventive Maintenance

Repairing the Database with DSE
Using the Proper Database File

Locating Structures with DSE

Safety in Repairs

Discarding Data

Concurrent Repairs

Terminating Processes

Recovering data from damaged binary extracts

Finding and Fixing Database Errors
C1–Possible Cache Control Problems

H1–Process Hangs

H3–Database Access Problems

H4–Database Cache Problems

H5–Critical Section Problems

H6–UNIX Problems

H7–Disk Hardware Problems

H8–Application Problems

I1–MUPIP INTEG Errors

MUPIP INTEG Error Classification Table

I2–GT.M Version Mismatch

I3–File Header Errors

I4–File Size Errors

I5–More Database Access Problems

I6–Transient Errors

I7–Database Rundown Problem

I8–Repair-Induced Problems

K1–Bad Key

K2–Keys Misplaced

K3–Block Doubly Allocated

K4–Pointer Problems

K5–Star Key Problems

K6–Compression Count Error

K7–Key Warning

M1–Bitmap Errors

M2–Bitmap Header Problems

O1–Bad Block

O2–Record Errors

O3–Data Block Errors

O4–Salvage of Data Blocks with Lost Indices

O5–Salvage of a damaged spanning node

O6–Block Size Errors

P1–Process Damage

Q1–Restricting Database Access

R1–GT.M Run-Time Errors

R2–Structural Database Integrity Errors

Run-Time Database Restart Codes

R3–Run-time Database Cache Problems

R4–Stopped Processes

R5–No More Room in the File

R6–GTMASSERT and GTMCHECK Errors

R7–Interlocked Queue Hardware Problems

R8–Database Tree Maximum Level Exceeded

R9–Read-only Process Blocked

This chapter discusses GT.M methods for maintaining data availability and integrity.

A database that has GDS integrity may not be consistent from the application data point of view. That is, certain types of failures that do not damage the GDS database structures may cause logical transactions (consisting of multiple database updates within an application) to stop in an “illogical” state with some, but not all, of the updates in place. Transaction processing and database journaling are good methods for maintaining application data consistency. For more information on transaction processing, refer to the “General Language Features of M” and “Commands” chapters of the GT.M Programmer’s Guide. For more information on journaling, refer to the “GT.M Journaling” chapter of this manual.

Maintaining database integrity is integral to GT.M operation; you should seldom, if ever, need the material in this chapter, especially if you use journaling. However, databases can be corrupted by unusual events such as hardware failures, sudden loss of power, operating system failure, or improper operator action. All such events should be followed with database integrity checks.

The chapter describes the following:

  • Suggested times to use MUPIP INTEG for verifying database integrity
  • Recommended methods for handling database problems
  • General techniques and strategies for using DSE
  • Instructions for identifying and repairing errors with DSE