I noticed that if I do not delete the backup file before the online backup is running much slower (2-3 times)It's easy to add a del db.bak in the script but I am interesting about the possible cause.Does anybody knows it?
We have the same over here. When there is an old backup file, the OpenEdge database backup take much more time than when there is no backup file. My quess is that Progress is reordering the file (with BI blocks?)
BTW We have this on Windows.
I thought I would quickly test this on Linux (OE11.6). No significant difference
Correct, it's an issue on Windows only. And it's not Progress issue, me think.
Not a progress issue?
probkup have to delete the file itself or throw a warning or something else.
Nobody would expect that an existing file is the problem for a long running backup.
PSC: I like to get the source code please to know what's the secret for this behavior.
Probkup was created to write initially to a tape rather than to a file.
For Windows too? A virtual device is not very common in windows backup software, isn't it?
The measured times:
20 Minutes to an non existing file
~40 Minutes redo the same backup but the previous file is still there
I don't think that it is a Windows issue. When we do SQL server backup, than it is fast. So my guess is that OpenEdge is doing something with the backup file. I think that the BI blocks are at begin of the file and then the data blocks is written. So when there is more or less BI blocks, than OpenEdge is trying to reorder something in the backup file. But that is an assumption of my!!
> I think that the BI blocks are at begin of the file and then the data blocks is written. So when there is more or less BI blocks, than OpenEdge is trying to reorder something in the backup file
I'm sure that the size of BI file in Stefan's database is much smaller than the size of data areas. Then we can ignore the existence of BI blocks. And since V11.2 online probkup dumps only active BI clusters. BTW, probkup reports the number of blocks it dumped. Stefan, can you post the numbers?
> 20 Minutes to an non existing file
>~40 Minutes redo the same backup but the previous file is still there
Check db log:
BACKUP 5: (1362) Full backup started. BACKUP 5: (16866) Dumped 256 active BI blocks.
BACKUP 5: (5461) Begin backup of Data file(s). BACKUP 5: (5462) End backup of Data file(s).
Does backup slow while dumping BI blocks? Or Data files? Or both?
Does the issue exist for offline backup as well? Or for two sequential online backup with no database activity in-between? In other words when backups are totally identical. Then what Progress would reorder in backup file?
> And since V11.2 online probkup dumps only active BI clusters.
That feature was introduced in 11.3 and was fixed to be usable in 11.5.
Message 16866 (Dumped <n> active BI blocks) was added in 11.2. Yes, I know it's wrong to reply on promsgs file. ;-)
So we know the message was there in 11.2. Was the feature there?
> On Jun 10, 2016, at 6:43 AM, George Potemkin wrote:
> Probkup was created to write initially to a tape rather than to a file.
true, but this makes almost no difference for what it does, which is to write sequentially to the output file or device. it certainly does not explain this behaviour, which does not occur on other operating systems.
Testing on 11.6 34 bit:
500MB backup file
Backup online to new file:
[2016/06/10@15:37:09.732+0100] P-7036 T-308 I BACKUP 6: (1362) Full backup started.
[2016/06/10@15:37:15.484+0100] P-7036 T-308 I BACKUP 6: (1364) Full backup successfully completed.
Backup online with existing file, no database activity between: 7 seconds.
[2016/06/10@15:37:25.936+0100] P-5964 T-428 I BACKUP 6: (1362) Full backup started.
[2016/06/10@15:37:32.610+0100] P-5964 T-428 I BACKUP 6: (1364) Full backup successfully completed.
Backup online with existing file and database activity between: 7 seconds.
[2016/06/10@15:38:32.596+0100] P-6716 T-1632 I BACKUP 7: (1362) Full backup started.
[2016/06/10@15:38:39.426+0100] P-6716 T-1632 I BACKUP 7: (1364) Full backup successfully completed.
One might note that the safe thing to do is never to write over and over again to the same backup file name. Even if you think you have a process which then copies that file somewhere else, if you are ever wrong that it got copied and your backup fails, then you have just destroyed your last backup. Write to a backup file name with a date-time stamp name and this issue will never arise.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
indeed. good advice thomas.
the last time i had to restore a customer's database, the last nightly backup was no good because the had done just that and then the backup failed. and had failed several times. fortunately they were using after-image journalling and had a week old backup.