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 |
|
Contents
- Verifying Database Integrity
- Approaches to Database Recovery
- Repairing the Database with DSE
- 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