G
George Potemkin
Guest
> what do we do if the corrupt block is detected while updating a fragmented record and the operation cannot be undone? Progress can undo the changes in all blocks except the ones marked as inaccessible. A record will be inaccessible if one of the blocks that need to be read is inaccessible including an index block. Let me keep dreaming… DBA can have utility to remove the inaccessibility flags. For example, session got the wrong dbkey error, marked the block as inaccessible, removed it from buffer pool, raised the error and /continue/ to run. When DBA will be notified about the error 1124 in db log, he/she can empty the system cache and if it fixed the error then remove the block’s inaccessibility flag. Everything can be done with no database downtime. The next step is the different states of the inaccessibility: fully inaccessible or read-only access. In the case in the starting post the database was running 6 days after the error 815. All this time the block contained the changes from the uncommitted transaction. So in some cases we can allow reading a block but are forced to prohibit its updates. This can’t be done easy in the current Progress versions but the future Progress versions could support the read-only buffer pools in shared memory. Not only to deal with the corrupted blocks but to support any operations that should temporary restrict the updates in some storage areas. As an intermediate solution: read-only sessions (including the ones running on target database) can read the corrupted blocks if DBA granted the read-only access to these blocks. It can be a part of “Five 9s” strategy.
Continue reading...
Continue reading...