G
gus bjorklund
Guest
answers to your questions 0) the way logical undo works during normal processing in multi-user mode (crash recovery is a bit different. so is single user mode) is as follows: we start from the location of the last bi note written by the transaction. this information is in the connection table entry. the location of the first note (the transaction begin) is in the transaction table. from the lat note, we read backwards, undoing each logical operation and skipping over notes produced by other transactions and physical operations like index block splits. as we do this, we may find jump notes. these notes are produced during normal processing when the last note written is in an earlier block than the next note generated. so the jump notes link together /bi blocks/ produced by the transaction. the individual notes are not linked together. as we go backward undoing, when we eventually come upon the transaction begin note, we are done. 1) the ratio of bi record reads and bi record writes during undo can vary quite a bit and is complicated, depending on the operation being undone and what happened when it was originally performed. consider creating a record. when that happens, we allocate space from the rm chain. this could produce quite a few notes if many blocks are removed from the chain or moved to the back. each of those operations requires a bi note. once we find an appropriate block with space, we might delete obsolete rowid placeholders before we put the new record there. while all this is going on, other transactions may be doing stuff so the individual notes for our transaction may be far apart. to undo this create operation, we delete the created record, which requires one note (unless it is fragmented) but we do not undo all the space allocation operations. however, we might now put the block on the rm chain which produces at least two more notes. similarly, when we insert a new index entry, we might need to do a block split, some space allocation operations, move some existing entries, insert a new entry in the parent block and so on. to undo, we delete the new index entry and sometimes insert a "unique entry lock" to reserve the spot until transaction commit. but we do not undo the block split if one happened. 2) it is probable that the bi record read counter includes the bi notes generated by other transactions even though these are skipped. after all, we have to look at them to see if the transaction id matches. 3) i suppose you could make a rough estimate of projected transaction undo time based on the number of notes the transaction generated during forward processing if you had enough sample history for the specific system and application but it would be muchly affected by what the other transactions were doing during the rollback. 4) i do not think there is any way to use the transaction id to read the transaction table faster. the transaction table is a pretty simple one-dimensional array of entries and has no index. the low-order bits of the transaction id give the entry number. 5) yes, the "magic trick" used to find the RL_CXSP2 note is indeed the jump note. these were put in at the same time as the before-image clustering mechanism (i.e. version 4.2A). but undoing the insert requires a search of the index much as is done during normal processing index lookups. this is because the index entry may not be in the same block into which it was inserted. furthermore, the block split may have been performed by another transaction which has been committed. 6) you bring up a good point about the transaction being started in databases that are not updated when a c transaction is started in one of several connected databases. this is an unintentional design flaw that was introduced in version 6.2. none of us noticed it until much later. i first noticed it during version 9 development. the worst part about it is that it can cause unnecessary two-phase commit processing. it is probably not simple to fix either. -gus
Continue reading...
Continue reading...