Chapter 11. Maintaining Database Integrity

Revision History
Revision V7.1-004 27 June 2024
Revision V7.1-002 19 September 2023
Revision V7.0-001 24 November 2021
Revision V7.0-000 12 February 2021
Revision V6.3-013 30 June 2020
Revision V6.3-010 31 October 2019
Revision V6.3-006 26 October 2018
Revision V6.3-005 03 July 2018
Revision V6.3-004 23 March 2018
Revision V6.3-001 20 March 2017

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: