|
|
|
In a very specific case, a record read failed with error 160 on a fixed-length huge (meaning a c-tree Huge Enabled file, which can grow beyond 4GB and has the extended header block) TRNLOG data file after automatic recovery or forward roll.
The number of keys in the index matched the number of data records, but some of the key values did not match the key values formed from the data record image. The key values all differed in the same way: only the key byte that was built over the byte at offset 8 differed from the expected value, and the data record had a value of 0x0 for that byte, while the key value had a non-0x0 value.
The specific situation where this was seen was as follows: A record was deleted and at least one other deleted record (call that record A) was already present on the delete stack. In another transaction, the deleted space was reused and the new record happened to have the same value in the byte at offset 8 of the record as the low-order byte of the already-deleted record (A). In addition, the next 7 bytes of the new and old images also matched. This caused the transaction log entries to not record the new value at byte 8 of the record. That situation caused automatic recovery or forward roll to leave that byte set to 0x0. However, the keys were added using their expected values from the transaction logs, leading to error 160 when reading the record by a key that used that byte of the record.
The logic has been modified to correct this problem.
