D
Dapeng Wu
Guest
George, The "jump note" may or may not used in this case. Jump note technology is only used when a transaction's current note is in a different BI block with its previous note. When this happens, the current note will record the location of the previous one in itself, somewhere that is not visible from this note scan. So I can't tell if any of these 8 notes have jump information or not. But given this transaction only started 8 notes, it's more likely they were all written in one BI block, which means no jump. The reason that during roll back, CXINS of dbkey 342214129 becomes CXREM of 342214285 is due to the split, as you have mentioned. What happened is the transaction manager reads CXINS, it will back out the action logically, which means it will not go to the physical location of the index entry (dbkey 342214129) and remove the entry over there. But instead, it will search the entry in the B tree and remove the entry logically (the entry had been moved to dbkey 342214285). So I'll give the credit of this fast roll back to the index manager instead of jump note. Jump note tech can be very helpful during roll back when there are a lot of concurrent transactions. For example, a transaction wrote a note in BI block 1, when it's about to write another note, it found out that BI block 1 or even 2.. are already filled out, it the had to use BI block 3. Without the jump note technology, rolling back of this transaction will have to scan all three blocks instead of just jumping back to block 1. BTW, you have a very nice post here. I'll forward the link to our team members and I believe they will learn a lot too.
Continue reading...
Continue reading...