[Progress Communities] [Progress OpenEdge ABL] Forum Post: How to survive after the errors like 819 or 10566?

[George Potemkin]

How to survive after the errors like 819 or 10566? (819) SYSTEM ERROR: Error in undo of record delete or (10566) SYSTEM ERROR: Undo failed to reproduce the record in area with rowid and return code . They mean that undo part of recovery note is corrupted. The note will be successfully replicated to a target database or rolled forward on warm standby copy but then these databases will fail to start: the crash recovery will be terminated due to the same error. In other words we will lose all databases. We can restore old backup and roll forward all AI files using endtime before the error. But it may not work as well because we need to find a time when a corrupted note was created rather than when Progress tried to undo the changes related to the note. Last one is a point of no return. As minimum we should known the time of transaction’s beginning. Unfortunately the error does not report even TRID. Does anybody see any other solutions rather than to use the –F option? Just for information - we already got error #819 for two customers. Both customers are running 11.7 build 1497 SP02. One on Linux 64-bit, second on on AIX 64-bit. Knowledgebase describes the defect PSC00293031 related to the error #819 but it was fixed in 11.3.3 and 11.4. In our cases the transactions did not use LOB objects. In both our cases the corrupted recovery note was RL_RMCR – the one that describes the creation of new record. Transaction undo did replace the records by placeholders (recid locks) and exactly at this moment we got the error #819. Progress could make a survival a bit easy and less painful for us if it would: 1. Report TRID with the errors above; 2. Use Transaction Ignore List at db startup that would sets the list of TRIDs whose recovery notes should be ignored during crash recovery. It’s better to be ill than dead. It’s better to leave uncommitted only a transaction that caused the above errors rather than to skip the crash recovery for all transactions that were active at the moment of db crush; 3. Enhance rollforward scan by the “loud” verbose option to report the changes described by each recovery note, in other words – the option to fully decode the contents of recovery notes. It would help us to find all changes done by the transactions on Transaction Ignore List and to fix them manually.

Continue reading...