Checking database structures is used to find errors that are caused by hardware defects. A database structure check checks the consistency of the individual database structures (such as the consistency of the B* trees, see Data Storage in B* Trees), but not the semantics of the data model. You cannot, therefore, find any logical errors with a database structure check.
We recommend that you check the database structure once a week. To avoid disrupting operation, you can perform the database structure check on a system copy.
You should perform an unscheduled database structure check if you receive one of the following error messages: -9053: Data page corrupted, -9023: Illegal entrypos, -9003: Illegal entrylength, -9006: Illegal keylength, -9041: Index not accessible
To start the database structure check, use the Database Manager database tool or CCMS in SAP systems.
· Database Manager GUI, Check Database Structures
·
Database Administration in CCMS: MySQL
MaxDB, Scheduling Database
Structure Checks
·
Database Administration in CCMS: SAP
liveCache, Checking Database
Structures
·
Check an individual
table: Database Administration in CCMS, Tables/Views
Choose one of the following functions:
Functions for checking database structures
Function |
Description |
Check all the data in the ONLINE operational state |
In the ONLINE operational state, all tables, indices, LONG columns and so on are checked for their structural consistency. The following checks are made: · There is an I/O check when the data is exported from the hard disk. This means that a check sum is calculated that has to agree with the check sum saved on the page. If it does not, the page number and the page type are checked. · Each B* tree is processed completely again. It is checked whether all leaves in the B* tree can be reached and whether the administration structures on the pages are intact. · All separators are checked on the pages of each B* tree. The length and increasing sequence of the keys can also be checked. |
Check all the data and clean up the converter in the ADMIN operational state |
In the ADMIN operational state, the same checks are performed initially as in the ONLINE operational state. The converter is then cleaned up using the results of the checks: all pages that the database system has not read during the checks, which therefore no longer exist in the data, are deleted. |
Check a selected table in the ONLINE operational state |
In the ONLINE operational state, you can also examine an individual table. The same checks are performed as when you check all data. You can also check all LONG values and the database catalog for individual tables. |
The commands used for checking the database structure are listed in the DBM.UTL and DBM.PRT log files. These files also log the error and return codes.
Return code 0 means that no errors were found during the database structure check. If a different return code was returned during the database structure check, then proceed as follows:
...
1. Display log file KNLDIAG. You can use the Database Manager GUI to do this (see Reading Database Files).
2. In KNLDIAG, the start of the database structure check is marked with the keyword CHECK, followed by the results of the database structure check and any errors.
A typical error message is
0xC18 ERR 53021 B*TREE BAD FILE: 104329 (ROOT)
3. For each error, identify the number of the root page (ROOT) of the relevant B* tree.
4. Use the ROOTS system table to deduce the relevant base table or the relevant index from the number of the root page (see Reference Manual, Analyzing System Tables).
5. If the error concerns an index, then restore the index using the Database Manager:
Database Manager GUI: Restoring Indices after Database Restore
Database manager CLI, Restoring a Damaged Index
6. If the error affects a base table, then you have the following options:
¡ Delete the base table. You can try to reconstruct the base table from other tables.
¡ Restore the database instance using the Database Manager. Use the backup that was created before the last successful database structure check.
If you have not yet checked the database structure for the database instance, then perform another database structure check after you import the backup for the table that was damaged. If errors are found again, then import an older backup.
Database Manager GUI: Restoring from a Previous Backup
Database manager CLI, Restoring the Database Instance