DBTOOL Options 3 & 5: High Level operation for Type II areas:
- They both execute checksum validation if the block is not already in the buffer pool. If already in the buffer pool, then check-sum was already validated as the block was read into the buffer pool. How to use DBRPR to scan for known blocks checksum error 14410 issues in a Type II Area ?
- Neither of these options perform any validation on index blocks (or check sum validation), since these blocks are not on the cluster chain of a table and are therefore never read.
Both of these options are useful when checking for database corruption and are coded to search for different types of corruption. These are very different validation operations, used for different purposes.
1. Option "3. Record Validation"
- Performs stored record validation operations.
- It first needs to gather all fragments of the record into a record buffer before that validation can commence
- Records are validated for the table number, number of physical fields, schema, field data type value and length amongst others.
- In OpenEdge 11.7.0 Option 3 has been updated to report common errors like invalid record size and invalid table number when all tables are selected and then stop further processing on the corrupt fields. When a specific table is selected, records that have invalid size or table number are skipped. For further information refer to Article DBTOOL Option 3 reports inconsistent for single table vs all table validation
- DBTOOL Option "4. Record Version Validation" will do the same as Option 3 but will do the validation before and after the record upgrade to the current schema version: DBTOOL Option 4 (Record Version Validation) reports discrepancies with the number of fields in a table
- It is important to note that the Record Template (schema) and the Record holding data (stored record) both have the same size limit where they cannot exceed MAXRECSZ (32KB). The following Article outlines a customer use-case where this situation arose after adding a LOB to the table's schema: DBANALYS crashes with error 15892 after a new LOB field was added
2. Option "5. Read or Validate Database Blocks"
- Is a physical record block validation operation.
- There is no need to produce the full record to examine the block
- Record blocks are validated for block header information, record offsets, fragment size and checking that the sum of all parts fit in the blocksize amongst others.
- Validation Level "2: Record overlap checking' is optional for performance reasons. These are described in Articles:
These options were added separately because they were targeted to identify different types of corruption for diagnosis. For example:
- Validating record information (Option 3) when there is only physical block corruption (Option 5) can slows things down and might not be necessary.
- For a full physical block and stored record validation diagnosis, both Options are needed preferably once isolated to specific area / table / record block (range).
