[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: What is the maximum possible value of -io for a probkup incremental?

Status
Not open for further replies.
S

slacroixak

Guest
This thread has lead to many questions. I am going to try to explain in one single post why I am interested in this pattern First, please note I know AI. I've used it in a previous life, when I was at a direct end user. It is great for what it was designed : DB recovery until the very last committed transaction in case of a crash, or synchronize a cold database on another machine over a LAN. I know AIW and so forth My needs are different now : I work for an editor with many different customers, most of them with a small or medium database 1) We do NOT wish to configure and administrate AI on all our customer sites. Guys in our IT teams know how to backup and restore backups also with incremental backups. They will be happy with the ability to restore a DB with an easily identified backup point. 2) On our development side, from time to time, we want to reproduce an issue of a given customer with fresh data. If we already have a full backup of theirs, then getting a fair set of incremental files (as described earlier) with be great for us. Next, in our App** the life cycle of our data is that people focus on a rather small amount of data every day, or every month. Older data remain unchanged most of the time. But one important aspect is that the same records are updated many times during the same day. Regarding this aspect, with AI you would end up with a much higher IO overhead for every single transaction. On the other hand, a daily incremental backup file (with -io 25 as I will do one per hour) will only hold the DB blocks that have changed for one day, and these blocks will appear only once in the backup file even if they have been updated multiple times during that day. Our test have shown that "probkup online incremental" is very fast and very smart, and it does not slow down operations in the DB while it is running*** ** like in many apps I suppose. ***but the resulting backup is a snapshot of the DB as it was when the probkup was launched, because the DB engine is smart enough to make probkup jump at a block to be updated so it can back it up before letting the update happen. 3) Hence this performance point : for our needs, I bet we will will leverage IO and cpu with this pattern compared to the constant overhead of AI 4) One dilemma I want to avoid about hardware : in order to do good AI, I would really prefer to do deal with an additional independent storage, but with same performance as the main one, for the sake of IO. But nowadays, our customers deal with too many different configs, some with SAN, some with SSD, many with VM in blades that are also used by other Apps.. If I do not use AI, then I just do not have to bother with the performance aspect. The only requirement is to hold the backup on a separate drive with little performance requirements. Costly, this is just much better At last, as some may have guessed... 5) this pattern allows synchronization of a DB over the internet. Indeed, the incremental file can be zipped then transferred daily, with an optimized amount of data (see point #3), so we might be able to offer some BI**** reporting on a hosted site somewhere. **** Business Inteligence, not Before Imaging ;)

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