G
George Potemkin
Guest
> Only the recoverable error 819? How about error 815? Sorry for misinformation: it's the error 815 that is recoverable and the 819 is fatal. A rule for myself to remember: the higher number the more dangerous is an error (so the 820 would probably mean the end of World ;-). The fix for the recoverable 815 will be available in 11.7.5 as well as in 12.1. Development team is still working on the fatal 819. > it may or may not be possible to implement. I believe the Progress database engine has "Write ahead" meaning APW will write changes to database that may be not yet committed. > cant do that. there may be changes from several transactions in the same database block. Data blocks are not corrupted. It's a recovery note that is corrupted in case of the 819. Namely the corruption is in undo part of recovery note. Every day we could have the thousands transactions that contain the notes with such corruption but we do not get the the fatal 819 because those transactions were not interrupted. But when we get the 819 we need the database in state before the note was generated. BTW, in the starting post I suggested an idea of Transaction Ignore List that would sets the list of TRIDs whose recovery notes should be ignored during crash recovery. In my humble opinion it can be useful not only after the fatal 819. Why developers think it's a bad idea? In case of the 819 all standard recovery plans will not work. The only solution from Progress is to use the -F option followed by dump and load of the whole database. For our largest customers where the typical size of databases is a few terrabytes) it would mean that the business is stopped for a week or longer. But Transaction Ignore List could reports the notes that were ignored (in the same format as with aimage scan verbose). We can easy dump all records from data blocks updated by those notes. We can rather easy empty these blocks. Unfortunately we can't use dbrpr/8. Reformat Block to a Free Block because this option is corrupted and in any case it should not be used for data blocks in SAT2. Then we can load the records back into a database and fix or rebuild the indexes in the corresponding tables. If everything is scripted then database downtime will be defined only by the size of the transactions on Transaction Ignore List and it can be reasonably short. Needless to say that the "ignoring" can be coded easy. This topic is exactly about the recovery plans for the unrecoverable errors like the 819.
Continue reading...
Continue reading...