Kbase 17491: Direction For Sequent Port To 8.2 Solaris V.4
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Unverified
FACT(s) (Environment):
Progress 7.x
Progress 8.x
Sun Solaris Intel
SYMPTOM(s):
After converting a database with proutil -C conv78
SYSTEM ERROR: bklok: inconsistent pointers, ptbl <val> oldbktbl <val> (1041)
SYSTEM ERROR: bkrlsbuf: cannot release buffer lock, use count <count> is invalid. (1051)
SYSTEM ERROR: wrong dbkey (1067)
SYSTEM ERROR: Invalid pointer encountered in block with DBKEY <num> (2260)
CAUSE:
Some History:
The generic UNIX486 bits have been certified on SEQUENT in 8.2A, hence there is no specific SEQUENT port.
Prior to 8.2A, the SEQUENT specific port was done on a SEQUENT machine and the database blocksize was always 2K. We are able to use the UNIX486 port in 8.2A due to the Variable Blocksize feature, because 2K is a valid blocksize in 8.2A.
Architecture:
Every Data (RM) block in a Progress database has a header on it. This header contains information like DBKEY, Block Type, what chains it's on, etc. In addition to the standard header, RM blocks then have a header that contains the following:
# of directory entries,
# of free entries,
list of directory entries,
list of free entries.
Finally, after all this header information is the actual data and free space.
Information about HOLD notes:
Whenever a record is deleted, we mark the directory entry for that block as being held so it doesn't get re-used right away. The reason for this is for transaction undo.
Take the example where user 1 deletes customer 10 recid 3257 and then leaves the transaction open and goes to lunch. Now user 2 comes along and adds customer 55 and wants to use recid 3257 for this record. If we allowed this, user 1 could come back from lunch and undo his/her transaction, then they couldn't replace customer 10 in recid 3257 because this was already taken by customer 55.
Every time a record is a candidate for reuse, we check to see if the HOLD note is referring to a valid transaction in the current transaction table, if it is, then we skip that record, if not then we use that record.
The Problem:
In order to support 8K database blocksizes, we needed to move the placement of the HOLD note from bit 13 to bit 16. We determined at startup whether to use the new format or old format.
The determination is done by seeing if the compiled in blocksize matches the database blocksize. If they matched, then we use the old format which is fine because the new format is only for database blocksizes == 8K. However, if the compiled in blocksize didn't match the database blocksize, then we use the new format. This is safe because the only way to change your blocksize is by dumping and loading the database.
The problem only seems to occur when a database has been converted using 'proutil <dbname> -C conv78' or proutil <dbname> -C conv68' where HOLD notes exist.
This does not indicate data corruption.
FIX:
Move to the latest Version 7 release and patch level.
After that, run dbrpr in Version 7, Select option 1 off the main menu, then choose the option to report bad records and the option to report bad blocks.
You are then prompted to remove the deleted record hold bit from the directory entry. Once this is completed the conversion program will be able to run on this database.