Kbase 15900: rmflchg: RECID <n> rmgetf returns <n> expected <n> ( 3835 )
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/25/1999 |
|
rmflchg: RECID <n> rmgetf returns <n> expected <n> ( 3835 )
PROGRESS ERROR TEXT:
SYSTEM ERROR: rmflchg: RECID rmgetf returns expected (3835)
WHAT DOES IT MEAN?
This error occurs during database startup or truncate bi operations.
It indicates there is an invalid bi note. An undo note is written
during an update transaction to aloow the update to be backed out if
necessary. During startup, PROGRESS compares the bi note to the
database record. If the undo note does not match the database record,
that indicates that the record was updated by another user. The undo
note in the bi file belongs to the second update transaction. This
can occur if the first user died during the transaction and the
transaction backout was not completed.
HOW DOES THIS HAPPEN:
This message is written when the following conditions are present.
o A user died during an update transaction.
o The transaction backout was not completed.
o The record locks were not released.
o Another user connected to the database and inherited the first
user's usernum.
o The second user inherited the first user's record locks.
o The second user updated the same record that was being updated
by the first user when the first user died.
CORRECTIVE MEASURES:
There are two options for recovery that will guarantee data integrity.
1) Restore a backup copy of the database
2) Force access to the database (pro -F) and immediately dump
load its contents.
There are alternative solutions that do not guarantee data integrity,
but these options are sometimes the best alternative given the nature
of a particular business. These options can be stated to a customer
provided they are given all the information.
3) Use the force -F option to access the database.
a) Choose to run a mock index rebuild (select some, !) which
resets the damage flag and rebuilds the free chain. This can
be done immediately or at a time that is more convenient.
* You must keep in mind that resetting the damaged flag via a
mock idxbuild does NOT guarantee the integrity of the
database. It is recommended that you dump and reload the
contents of the database as soon as possible!
b) If this error occurred on startup after a normal shutdown
(the .lg file MUST have Begin normal shutdown and Multi-user
session end messages), then you can attempt to repair the
record(s) in question. (see how to repair section below)
c) If the error occurred on startup after an abnormal shutdown
section deal with how the error occurred and what to look for.
Event: A user died during an update transaction.
Symptom: <time> Disconnecting user <number>. (741)
Event: The transaction backout was not completed.
Symptom: There wil be a Begin transaction backout. (2252) message
for that user number without a corresponding Transaction
backout completed. (2253)
Event: Another user connected to the database and inherited the
first user's usernum.
Symptom: Compare the user number in message 741 with any
subsequent user login messages.
Event: The second user inherited the first user's record locks
and releases the locks.
Symptom: SYSTEM ERROR: lkrend: forgotten record lock, recid .
(431)
Event: The second user updated the same record that was being
updated by the first user when the first user died.
Symptom: SYSTEM ERROR: rmflchg: RECID <recid> rmgetf returns
<rec-size> expected <rec-size>. (3835)
Note: This final event is what causes the bug. If the second user
does not update the same record, the invalid bi note will not
be written and the database will not have been damaged.
HOW TO REPAIR THE RECORD(S):
Once the analysis is completed, the records can be repaired. Make a
list of all the RECIDs in each of the lkrend (431) errors AND the
RECID in the rmflchg (3835) error. Run a procedure that queries for
each of these records by RECID. Make a determination on the validity
of the data in each record and modify the data accordingly.
(See PROGRESS Technical Support Knowledgebase entry 11744 to determine
the table name for the RECID.)
NOTE: If the previous shutdown was abnormal, it is still possible that
any transactions that were not committed prior to the crash
could have cause other records to contain invalid data. It is
recommended that all users check their work for that session.
Developer's NOTE:
If a transaction backout fails, the transaction remains active. This
means that space in the bi file cannot be re-used. This will cause
the before image file to grow out of normal proportion.
If lkrend subsequently releases the locks for the transaction, then
other users can modify records which were updated by the transaction
which failed to backout.
During crash recovery we will again try to backout that transaction.
The crash recovery will fail because the record has been updated by
some other user, thus it no longer matches what the record undo
operation expects and we fatal out of crash recovery.
One final note is that all this can happen even though the database
had a normal shutdown.
If a transaction remains active, you can also see other errors such as
the following that occurs when the bi file reaches 2GB in length.
SYSTEM ERROR: rlbinext: -2147483648 past end of cluster (3829)
NOTE: This is a bug that was reported in 7.3A. This is a VERY
SERIOUS bug. When a customer runs into this, they MUST RECEIVE
A PATCH ASAP. THIS BUG CAN RECUR UNTIL IT IS PATCHED,
therefore, a dump/reload or restore of a backup will not
permanently resolve the issue. This bug has been in the product
since Version 6.
10-Oct-95 NOTE: This bug is NOT fixed in 7.3C OR 7.3C01 on Unix. It
NEEDS TO BE PATCHED in 7.3Cxx.
Progress Software Technical Support Note # 15900