[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Replication Redo 0%

[George Potemkin]

Do I correctly interpret the values reported in the messages? > 13:11:09 BROKER 0: Physical Redo 100% at block 21616. 5232 blocks processed in 79 seconds. > 13:11:09 BROKER 0: Physical Redo Phase Completed at blk 21616 off 16205 upd 292420. (7161) I think the messages say that broker scanned 5232 BI blocks and updated 292420 DB blocks. Hence one BI block in average contains 56 (=292420 / 5232) recovery notes that describe the physical changes in DB blocks. Max offset in BI blocks mentioned in the messages is 16384 (=16K). Hence BI block size = 16K The average size of recovery notes that describe the physical changes in DB blocks is less than 293 bytes (=16K / 56). Not all recovery notes describe the physical changes. I would expect that real average size of BI notes is less than 200 bytes. In other words BI blocks contained enough number of notes like RL_TBGN, RL_TEND or RL_TMSAVE. Hence either the most of transactions were short or they consisted of the small subtransactions. Redo Phase updated 292420 DB blocks in 79 seconds => 3701.52 DB blocks/sec Obviously db block size is 8K. => DB Writes were 28.92 MB/sec. Fast! BI Writes were 66 blocks/sec or 1.16 MB/sec (= 5232 / 79 * 16K). It's less than a typical BI writes in multi-user environment - a hundred or so BI blocks/sec. It's much less than the speed of BI writes in the Fugal test (proutil -C bigrow -zextendSyncIO). Hence the bottleneck during Physical Redo Phase were DB reads/writes. > 13:13:11 BROKER 0: Begin Logical Undo Phase, 37 incomplete transactions are being backed out. (7162) > 13:13:11 BROKER 0: Logical Undo Phase begin at Block 21615 Offset 5802. (11231) > 13:13:13 BROKER 0: Logical Undo Phase completed at block 145533, offset 15860. (12095) Logical Undo Phase did NOT created 123,918 (=145533 – 21615) BI blocks, did it? It should not be larger than the number of BI blocks processed by Physical Redo Phase (5,232 BI blocks). Undo Phase completed at BI block with large number because the block numbers are not sequential in the ring of BI clusters. Right?

Continue reading...