Analyzing a DBD

After you locate the DBD in the dump, the cause of the inconsistency can now be analyzed.

A DBD in virtual storage (memory) can have many DBD sections, resulting from DDL CREATE statements. Conceptually, however, a DBD is a contiguous block of information that contains object descriptors (OBDs) for various DM objects. Each OBD has an identifier that is called an OBID. The OBID is an index into the OBDDMAP. The offset to a particular OBD from the beginning of the DBD header is equal to the value in OBDDMAP (OBID). For instance, if the OBID is 4, the offset to that OBD is stored at OBDDMAP(4), the fourth word of the OBDDMAP. The OBDDMAP begins at offset X'48' from the start of the DBD header.

The following figure illustrates these relationships and can aid in analysis.

Figure 1. DBD and file OBD structure
Begin figure description. This figure is a graphic representation of the information in the "Database descriptor (DBD) formats" topic. End figure description.

The procedure that is provided explains how to go through all OBDs of all DBDs and how to analyze their structure. This process is extremely time consuming. When an error or inconsistency is found, you can choose to stop the analysis and assume that the problem is the only problem, or you can continue in an attempt to find other potential errors.

If you suspect that a certain OBID is involved in the problem, you can locate the corresponding OBD directly, and use parts of the procedure for analyzing a DBD (depending on what type of OBD is involved).

Begin with the first procedure, Checking the DBD header and chain of files, which explains how to start analyzing the structure of the DBD. This general procedure refers you to other more specific procedures that follow it.

The procedure for checking the structure of the DBD applies to DBDs for user-defined databases only. Assume that the structure of system-defined DBDs for Db2 areas such as the catalog are correct.

Locating an OBD (given the OBID of the OBD) involves using the OBID value as an index into OBDDMAP. When doing this task, mark the OBID to indicate that it is being used. When you search a chain, if an OBID is encountered that is already marked, the OBD is pointed to by more than one other OBD; that is, it is in two chains. If the OBD is not a relationship OBD between tables in the same database, this is an error (only relationship OBDs in the same database can appear in two chains).