[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Database Backup to Cloud services claiming they "DE-DEPE" the files.

  • Thread starter Thread starter mfurgal
  • Start date Start date
Status
Not open for further replies.
M

mfurgal

Guest
The issue with these backup technologies is that write order is not guaranteed. OpenEdge, along with other databases, depend on a Write Ahead Logging protocol for crash recovery to work. This means that data must be written to the Before Image file before it is written to the data storage portion of the database. The Data portion is broken into blocks. Each block has a version number in it. The Before Image notes describe changes to these blocks. For example, a note could say I know how to change block 1234 from version 10 to version 11 by doing X. The same note knows how to undo that change, being able to reverse the change of version 10 to 11. The undo of this, would cause the block version to go from 11 to 12. This makes crash recovery recoverable. Crash recovery has 3 phases. BI Cluster fix-up, Redo, Undo. There are more, but at a high level these will do. Cluster fix-up makes sure the BI Cluster ring is intact. The Redo phase makes sure all the Data blocks are up to date. During redo these notes are replayed. A note says it can change the block 1234 from version 10 to 11, we read block 1234, it’s at version 10, we apply the change and make it version 11. Or we read the block 1234 and it’s at version 14, but our note says we can change it from version 10 to 11, so no work needs to be redone here. The undo phase is where problems can occur if the Write Ahead Logging protocol is not enforced. After redo is complete, all open transactions are undone. To do this the Before Image file is read backwards for any open transactions. When it finds a note for say block 1234 and it is the change from version 10 to version 11, if it reads the data block and it’s at version 14, then undo will fail as the note does not know what to do. This means that the data block 1234 was written to disk, or replicated, before the BI note describing the change was written to disk or replicated. A big NO-NO. The only tested and support SAN based replication is EMC SRDF. There are many products from EMC that are layered on-top of the EMC SRDF technology as well. Outside of this supported configuration, any SAN based replication or any technology that claims they can do this MUST preserve write order for crash recovery to work. I talk to customers and vendors on this subject weekly to try to educate them of why it may and may not work. I think knowing why it will not work is useful when having these conversations. Mike -- Mike Furgal Director – Database and Pro2 Services PROGRESS Bravepoint 617-803-2870 mfurgal@progress.com

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