Revision History | ||
---|---|---|
Revision V5.5-000/10 | 28 September 2012 | Added two new sections–“O5–Salvage of a damaged spanning node” and “Recovering data from damaged binary extracts”. |
Revision V5.5-000/2 | 19 March 2012 | In “O4–Salvage of Data Blocks with Lost Indices”, fixed syntax errors in the example. |
Revision V5.4-002B | 24 October 2011 | Conversion to documentation revision history reflecting GT.M releases with revision history for each chapter. |
Table of Contents
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