Incremental backup same size as full backup

dhunter

New Member
We are running OpenEdge 10.2B on a Windows 2008 R2 server which also houses our MIS/ERP software, and when we have Windows Task Scheduler kick off an Incremental backup of the gams1 database (19.7GB), it ends up being the exact same size as our full backup. Is there a better way of fixing this issue, besides doing a Dump/Load of the database (was told 1hr per gig dump and 2hr per gig load)? Also, would like to know if anyone would know why this would happen?

If you need any further info, just let me know. Thank you in advance!
 

Cringer

ProgressTalk.com Moderator
Staff member
If you're contemplating a dump and load then make sure you're on the very last service pack of 10.2B. You will then have a number of bells and whistles at your fingertips to improve the speed. Particularly the index build. I did a 9GB Database in less than an hour the other week.

In terms of your actual problem, what is the command line for your backup please? And why are you doing incrementals?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Is there a better way of fixing this issue, besides doing a Dump/Load of the database (was told 1hr per gig dump and 2hr per gig load)?
Agreed with andre42 and Cringer, I would consider this rate to be extremely slow. I would think that on decent hardware, with 10.2B SP08, you should be able to binary dump, load, and rebuild indexes in a couple of hours or so.

I've never used incremental backups, nor wanted to. I think daily full backups plus regular archiving of AI files is a better and more flexible approach for recovery and results in much less read I/O on the production database.
 

TomBascom

Curmudgeon
oe12 is the current release. oe10 is ancient, obsolete and there aren't going to be any bug fixes for it.

You should be able to dump & load 19GB in a couple of hours without even trying very hard. Those numbers you quote sound like numbers from circa 1990 hardware.
 

dhunter

New Member
In response to andre42: yes that is exactly what is happening and was told a Dump/Load is the only way to fix…would take the whole weekend to do so, if there is no overtime (in a production environment).

In response to Cringer: I don’t think that we can go up in service pack, we are currently on SP6 which is provided to us by our MIS/ERP software. The following is our scripts that runs for the full and incremental backups...
Full:
D:
cd /d D:\hagenoa\hsi\data


if exist e:\hagenbak\backup\%1\gams1bu (
del e:\hagenbak\backup\%1\gams1bu
)
probkup online gams1 e:\hagenbak\backup\%1\gams1bu -com


Incremental:
D:
cd /d D:\hagenoa\hsi\data

echo. > e:\hagenbak\backup\%1\IncrementalBackup%1.log

date /T >> e:\hagenbak\backup\%1\IncrementalBackup%1.log
time /T >> e:\hagenbak\backup\%1\IncrementalBackup%1.log

echo. >> e:\hagenbak\backup\%1\IncrementalBackup%1.log
echo. >> e:\hagenbak\backup\%1\IncrementalBackup%1.log

echo check for existing INCgams1bu >> e:\hagenbak\backup\%1\IncrementalBackup%1.log
dir e:\hagenbak\backup\%1 | find /I "INCgams1bu" >> e:\hagenbak\backup\%1\IncrementalBackup%1.log

if exist e:\hagenbak\backup\%1\INCgams1bu del e:\hagenbak\backup\%1\INCgams1bu >> e:\hagenbak\backup\%1\IncrementalBackup%1.log

echo progress backup command line is: >> e:\hagenbak\backup\%1\IncrementalBackup%1.log
echo probkup online gams1 incremental e:\hagenbak\backup\%1\INCgams1bu -com >> e:\hagenbak\backup\%1\IncrementalBackup%1.log
probkup online gams1 incremental e:\hagenbak\backup\%1\INCgams1bu -com >> e:\hagenbak\backup\%1\IncrementalBackup%1.log

echo. >> e:\hagenbak\backup\%1\IncrementalBackup%1.log



In response to Rob Fitzpatrick: we are doing Incremental backups due to the amount of changes during productions hours.

In response to TomBascom: We cannot upgrade, as this is what's provided for us from our MIS/ERP software and they only approve it with our current 10.2B SP6 version.

Thank you all for all the good information, was really hoping that our only fix was NOT to Dump/Load. The time it will take to do that is just too long and not very feasible…doable if that is the only way, just not very feasible.
 

andre42

Member
In response to Rob Fitzpatrick: we are doing Incremental backups due to the amount of changes during productions hours.

Thank you all for all the good information, was really hoping that our only fix was NOT to Dump/Load. The time it will take to do that is just too long and not very feasible…doable if that is the only way, just not very feasible.

Look again at what Rob wrote.
I've never used incremental backups, nor wanted to. I think daily full backups plus regular archiving of AI files is a better and more flexible approach for recovery and results in much less read I/O on the production database.
This is exactly what AI files are for. My company does the same thing for our clients, a full backup at night and rotating AI files maybe every 15 minutes and archiving them. You would be able to restore a backup and roll forward as many AI files as you like.
Of course you have to know how to configure and use this stuff, but it is not exactly rocket science either.

Regarding the time: Did you try to measure how long the dump takes? You could just start an online dump at a time the database is not used that much. You can still abort it if it has any negative impact.
 

Cringer

ProgressTalk.com Moderator
Staff member
I would happily charge you a weekend to do the dump and load, even on 10.2BSP6 ;)
 

dhunter

New Member
Thanks all, don't know much about the ins and outs of OpenEdge, so all this info is greatly appreciated. I am reaching out to our MIS/ERP provider's support to see if they can provide a fix that is less intrusive for our production.
 

TomBascom

Curmudgeon
While I do not doubt that someone told you that you cannot upgrade it is almost certainly a fairy tale.

Many times that is indeed the knee jerk reply that a vendor's first line support will feed you. That does not make it true. Unless the product is orphaned AND you do not have the source code the chances are very good that you can actually upgrade. Often with little or no effort.

Often it is simply a matter of pushing back and escalating to someone with enough knowledge.

If a vendor is keeping you on 10.2 they are not supporting you. They are exploiting you and exposing you to risk.
 
Last edited:

Rob Fitzpatrick

ProgressTalk.com Sponsor
Is there a better way of fixing this issue, besides doing a Dump/Load of the database
Yes: stop doing incremental backups. Yes, that's a serious answer. With after imaging enabled and AI log shipping/archiving in place as andre42 described, incrementals are unnecessary and inefficient. Which makes me think you don't have after imaging enabled.

In response to Rob Fitzpatrick: we are doing Incremental backups due to the amount of changes during productions hours.
Do you have after imaging enabled on the production database? You must. If you're not sure of the answer, you can post the output of a proutil describe command run in a proenv session. E.g.: proutil D:\hagenoa\hsi\data\gams1 -C describe. Please enclose the output in [ CODE ] tags (without the spaces inside the brackets).

If you don't have after imaging enabled in production, then the size of your incremental backups is not your most pressing concern. In this case, you must absolutely prioritize enabling AI and configuring it appropriately. If you're unsure of how to do so, or why this is so important, you should pressure your vendor to help you get this done.

if exist e:\hagenbak\backup\%1\gams1bu (
del e:\hagenbak\backup\%1\gams1bu
)
probkup online gams1 e:\hagenbak\backup\%1\gams1bu -com
Your script deletes the current backup before knowing whether the one it is about to execute is going to succeed. Food for thought...

Optimization note: you could benefit from adding "-Bp 10" to the end of your probkup online command line. This causes the backup client to use a small area (10 buffers) in the database buffer pool for its block reads, rather than using the entire buffer pool. This prevents it from "fouling" the buffer pool with contents of old blocks that are not useful to database clients, which would temporarily reduce the database's caching efficiency (i.e. increase physical disk I/O).

In response to TomBascom: We cannot upgrade, as this is what's provided for us from our MIS/ERP software and they only approve it with our current 10.2B SP6 version.
I understand that you are constrained by what your vendor will support. But there is a distinction to be made between a version upgrade (e.g. to v11.7 or 12.0) and the installation of a later service pack into an existing version. The latter carries much less effort and risk and keeps you on the same OE version. 10.2B08 contains a lot of bug fixes for issues in 10.2B06, and as a bonus it contains functionality that would make a dump/load/index rebuild on Windows more efficient. At a minimum, your vendor should be willing to entertain a discussion with you on the subject of installing the latest bug fixes available for your release.
 

dhunter

New Member
Rob Fitzpatrick, thank sooo very much for all the info....I will delve into this more and let you all know what I came up with. Very good and useful information here, you all are AWESOME! Cheers!
 
Top