[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Transactions and Undos. Novel

  • Thread starter George Potemkin
  • Start date
Status
Not open for further replies.
G

George Potemkin

Guest
I have investigated a bit father the large transaction above. As usually the answers raise new questions. Undo phase is now looking even more “mystical”. First of all, the program that updated the database was run inside a block with transaction property. So in fact it was a sub-transaction from the session’s point of view. It’s an important note! The transaction was very large. So I traced the history only for 3 blocks updated by transaction: A. the block updated at the beginning of the transaction. Really it’s a second block updated by transaction; B. the block updated in the middle of the transaction. Really it’s a block updated just before the session received the HANGUP signal. It does not turn out to matter; C. the block updated at the end of FWD phase; O. The changes of object block will be mentioned as a part of the changes of RM chain. During the FWD phase of transaction the blocks are updated in the following order: A -> B -> C. During the UNDO of phase of (sub-) transaction the expected order: C -> B -> A. The history of the block updates: 11:54:48 code = RL_TBGN ================================================================================= 11:54:49 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 1 to 64 (64 updates) 11:54:49 O code = RL_BKFRM area = 11 dbkey = 131072 update counter = 61007108 11:54:49 A code = RL_BKFRB area = 11 dbkey = 9986286912 update counter = 65 12:01:36 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 1 to 64 (64 updates) 12:01:36 O code = RL_BKFRM area = 11 dbkey = 131072 update counter = 61014341 12:01:36 B code = RL_BKFRB area = 11 dbkey = 9987806848 update counter = 65 13:26:46 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 1 to 21 (21 updates) 13:26:46 Sub-transaction was interrupted (by END-KEY?) ================================================== 13:26:46 C code = RL_RMDEL area = 11 dbkey = 9976954368 update counter = 22 to 62 by 2 (21 updates) 13:26:46 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 23 to 63 by 2 (21 updates) 14:11:11 B code = RL_RMDEL area = 11 dbkey = 9987806848 update counter = 66, 69 to 193 by 2 (64 updates) 14:11:11 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 67, 70 to 194 by 2 (64 updates) 14:11:11 B code = RL_BKBBOT area = 11 dbkey = 9987806848 update counter = 68 14:11:11 Z code = RL_BKBBOT area = 11 dbkey = 9987806784 update counter = 68 14:11:11 O code = RL_BKMBOT area = 11 dbkey = 131072 update counter = 61070135 14:11:11 B code = RL_BK2EB area = 11 dbkey = 9987806848 update counter = 195 14:22:05 A code = RL_RMDEL area = 11 dbkey = 9986286912 update counter = 66, 69 to 189 by 2 (62 updates) 14:22:05 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 67, 70 to 190 by 2 (62 updates) 14:22:05 A code = RL_BKBBOT area = 11 dbkey = 9986286912 update counter = 68 14:22:05 A code = RL_BK2EB area = 11 dbkey = 9986286912 update counter = 191 14:27:02 A code = RL_RMDEL area = 11 dbkey = 9986286912 update counter = 192 to 314 by 2 (62 updates) 14:27:02 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 193 to 315 by 2 (62 updates) 14:29:27 B code = RL_RMDEL area = 11 dbkey = 9987806848 update counter = 196 to 322 by 2 (64 updates) 14:29:27 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 197 to 323 by 2 (64 updates) 14:29:28 HANGUP signal received (562) =================================================================== 15:33:20 C code = RL_RMDEL area = 11 dbkey = 9976954368 update counter = 64 to 104 by 2 (21 updates) 15:33:20 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 65 to 105 by 2 (21 updates) 15:33:20 C code = RL_RMDEL area = 11 dbkey = 9976954368 update counter = 106 to 146 by 2 (21 updates) 15:33:20 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 107 to 147 by 2 (21 updates) 16:02:48 B code = RL_RMDEL area = 11 dbkey = 9987806848 update counter = 324 to 450 by 2 (64 updates) 16:02:48 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 325 to 451 by 2 (64 updates) 16:09:16 A code = RL_RMDEL area = 11 dbkey = 9986286912 update counter = 316 to 438 by 2 (62 updates) 16:09:16 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 317 to 439 by 2 (62 updates) 16:09:16 Begin transaction backout. (2252) ============================================================== 16:09:16 A code = RL_RMDEL area = 11 dbkey = 9986286912 update counter = 440 to 562 by 2 (62 updates) 16:09:16 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 441 to 563 by 2 (62 updates) 16:10:46 B code = RL_RMDEL area = 11 dbkey = 9987806848 update counter = 452 to 578 by 2 (64 updates) 16:10:46 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 453 to 579 by 2 (64 updates) 17:09:39 C code = RL_RMDEL area = 11 dbkey = 9976954368 update counter = 256 to 296 by 2 (21 updates) 17:09:39 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 257 to 297 by 2 (21 updates) 17:56:39 A code = RL_RMCHG area = 11 dbkey = 9986286912 update counter = 564 to 625 by 2 (62 updates) 17:59:41 B code = RL_RMCHG area = 11 dbkey = 9987806848 update counter = 580 to 643 (64 updates) 19:02:58 C code = RL_RMCHG area = 11 dbkey = 9976954368 update counter = 298 to 318 by 2 (21 updates) 19:02:58 C code = RL_RMDEL area = 11 dbkey = 9976954368 update counter = 319 to 359 by 2 (21 updates) 19:02:58 C code = RL_RMCR area = 11 dbkey = 9976954368 update counter = 320 to 360 by 2 (21 updates) 20:02:18 B code = RL_RMDEL area = 11 dbkey = 9987806848 update counter = 644 to 770 by 2 (64 updates) 20:02:18 B code = RL_RMCR area = 11 dbkey = 9987806848 update counter = 645 to 771 by 2 (64 updates) 20:11:06 A code = RL_RMDEL area = 11 dbkey = 9986286912 update counter = 626 to 748 by 2 (62 updates) 20:11:06 A code = RL_RMCR area = 11 dbkey = 9986286912 update counter = 627 to 749 by 2 (62 updates) 20:11:07 code = RL_TEND ================================================================================= Initial interruption of sub-transaction was initiated by ABL code. As expected the transaction’s state stayed unchanged: FWD. UNDO of sub-transaction was handled via the local before-image file: the session did not read BI file at this phase. It’s not expected because the session did not use the -nosavepoint parameter (transaction used the RL_TMSAVE notes). Since 34:25 after interruption promon shown: 02/22/19 Status: Active Transactions by user number for all tenants 14:01:11 Usr:Ten Name Domain Type Login time Tx start time Trans id BI RReads BI RWrites Trans State 950 XXXXXXXX 0 SELF/ABL 02/21/19 12:59 02/22/19 11:54 715548686 0 35583963 Active FWD What ABL events can initiate such type of UNDO? During UNDO of sub-transaction the blocks were updated in the following order: 1. C -> B -> A -> 2. A -> B -> C -> 3. C -> B -> A In other words it was: 1. UNDO of FWD phase 2. UNDO of UNDO # 1 3. UNDO of UNDO # 2 Why we got 3 phases of UNDO? Transaction has created 64 records in the block A. During UNDO phases of sub-transaction as well as during UNDO of the whole transaction only 62 slots were processed in this block: the records were deleted and replaced by placeholders and vice versa. Why two slots were missed? As expected the reaction on HANGUP signal was postponed until the end of sub-transaction UNDO. UNDO of the whole transaction did not ignore the changes done during UNDO phase but it seems to be the result of using LBI file during UNDO phase. Otherwise the transaction would be completed immediately after the end of sub-transaction UNDO. More over the order of changes are not mirroring the changes on the previous phases: UNDO of the whole transaction updated the blocks in the order: A -> B -> C Then unexpected we got the RL_RMCHG notes for each slot in the blocks in the order: A -> B -> C. Note that there were no RL_RMCHG notes on all preceding phases. What are they doing? And why the order of these changes is not reverse to the previous notes? And finally the records were deleted and replaced by the placeholder in the expected order: C -> B -> A

Continue reading...
 
Status
Not open for further replies.
Top