Kbase P123869: 10.1B Database crashes with System error 822
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/02/2008 |
|
Status: Verified
FACT(s) (Environment):
OpenEdge 10.1B
All Supported Operating Systems
SYMPTOM(s):
Converted database crashes with error 822
rmdoins 1: pbk->free went negative dbkey <number>, area <number> (822)
Database starts abnormal shutdown
SYSTEM ERROR: The broker is exiting unexpectedly, beginning Abnormal Shutdown. (5292)
Client application was updating or deleting records
Table has rowids in 64-bit range
Stack trace from _progres reads:
dsmFatalMsgnCallBack
rmDoInsert
rlLogAndDo
rmUpdateRest
rmUpdateRec
Stack Trace from prowin32 reads:
dbut_p_stcopy
dbtool report from Option# 3 "Record Validation" shows warning messages about the first record fragment less than 10 bytes.
Warning - first record fragment of 38104 area 35 is only 9 bytes.
CAUSE:
Bug# OE00147475
CAUSE:
After 64-bit dbkey support was introduced in 10.1B, any record in a Type II area will have at least 10 bytes, otherwise there is the possiblity that the next fragment may point to a 64 bit rowid which will not fit in the space of the original fragment.
With OpenEdge 10.1B record version, non-schema records will always have size larger than 10 bytes. The new version of record has an array field header that assures the size of the record will always be larger than 10 bytes, therefore newly 10.1B created non-schema records will never have this issue, but not for example, schema-modifications by a pre-OE 10.1B client server connection to the OE 10.1B database modifying the schema.
Schema records that were created in a pre-10.1B version, do not have the array header so the size of the record (or fragment) can be smaller than 10 bytes. So any records that have a <10 byte header, if the next fragment points to a 64 bit recid, it will not fit in the space of the original fragment. This causes the database crash with error 822 during the time of the update/delete and subsequent bi redo during crash recovery.
FIX:
1.) If database fails to restart with the 822 error messages, first restore the last valid backup. This is a non-recoverable situation as the notes in the redo phase of the bi suffer the same inability to add the record pointer.
2.) Run OE10.1B Dbtool #6 "Record Fixup" at the area or table level. If any records are found to have < 10 byte header, the record will be deleted and recreated with the new header size. This utility can be run online or offline and will be replicated in after-image notes in hotspare and OpenEdge replication enabled environments.
Example:
a.) dbtool <dbname>
b.) Option# 9. Enable/Disable File Logging (will write to dbtool.out)
c.) Option# 6. Record fixup
d.) <connect>: (0=single-user 1=self-service >1=#threads)? 2
<rowid>: (rowid or all)? all
<table>: (Table number or all)? <tablenumber of this table if the table is known, otherwise 'all'>
<area>: (Area number or all)? <areanumber, do not select 'all'>
<display>: (verbose level 0-3)? 1