Before Image file growing very large!

[mattk]

Hi there,

We have an application using Progress 9.1d on a Windows Server 2003 platform. The databases are replicated accross to a seperate machine every 15 minutes using after image files and php replication scripts.
I have noticed that recently the before image file is growing very large on the target server. In fact it has got to 5 gig now! Is there any reason why this would grow so large so quickly?

Any help would be much appreciated.

Thanks and regards.

 

[TomBascom]

This is yet another symptom of the bad behavior we were discussing a week or so ago.

Fixes:

1) Upgrade. If you insist on running v9 at least get to 9.1E service pack 4. It's 5 years old and there will be no more service packs but it does contain lots of bug fixes and performance improvements. 9.1D is really, really old and has lots of bugs. Going from 9.1d to 9.1e is a no-brainer. My grandmother could do it successfully.

Upgrading to OE10 would, of course, be lots better. The engine crew is aware of this family of problems and has been specifically addressing them in the last few releases. But they were unaware of them in the v9 timeframe and there will be no back ports of fixes.

2) Truncate the bi file.

3) You might try changing your roll forward schedule from 15 minutes to 30 (or 60). But that, of course, has the downside of greater business risk should a problem occur.

That's all I can think of right now... but I haven't finished my coffee yet either

 

[mattk]

Hi there,

Following this advice we truncated our bi file last night which worked fine. Upon restarting our replication scripts our roll forward failed with the error that the dates were mismatched. We have tried manual roll forwards on what should be the correct ai files but this has again failed.

The only option for us now is to rebuild the databases on our target server from scratch and restart our replication scripts that way.

Could anyone advise why this may have occured?

Thanks and regards.

 

[TomBascom]

Because you took the least useful option of the 3 that I suggested?

It seemed obvious but I guess I should have mentioned that truncating the bi file on a roll-forward target usually means that you must also re-seed the roll-forward target. I've not extensively tested it but on at least some releases and under some conditions it does not affect RF but you're running old clunky stuff so I guess you aren't so lucky.

 

[mattk]

Hi Tom,

Thanks for the feedback. Unfortunately the other two options were not viable options for the business leaving the bi truncation as the only available option. I did test this routine before releasing into live and it worked fine. What is involved in reseeding the database?

Thanks and regards.

 

[TomBascom]

I fail to see how upgrading to 9.1e is not feasible.

"Reseeding" = restore from a backup of production and restart the ai roll forward process.

 

[ron]

Hi Matt,

Sorry for being "late" - I only just saw this thread.

I have extensive experience with exactly this problem - in exactly the same circumstances - using Progress 9.1D. However our sending and receiving platforms were Sun servers.

Tom's advice to go up to 9.1E - or better to 10+ is perfectly correct. However, I'll explain your problem so that maybe you can live with it a while until you can upgrade.

The BI file holds all details about DB activity during transactions. At the moment when you command Progress to switch to the next AI file there may be no transactions currently active - or there could be one, two - or any number. When the AI file is copied to your other server and rolled-forward, the DB is brought up to exactly the point when the AI file switch-over happened. Therefore, however number of transactions were active on your production system at the moment of the switch - then the same number (of course) will now also be active on your stand-by server.

If you look at the DB log (.lg) on the stand-by server, as each AI file gets rolled-forward Progress will put a message in the log saying that "x" transactions are "in flight" (which might be zero - but also might not be).

If (IF AND ONLY IF) Progress reports that zero transactions are in-flight may you truncate the BI file on the stand-by server! In that situation the BI file does get truncated, of course, but the DB itself does not get modified in any way - and (importantly) the date/time stamp on th DB remains unchanged.

HOWEVER, if one or more transactions are "in flight" then you must not truncate, because doing so will cause Progress to roll-back all in-flight transactions. That makes your stand-by DB different from your production DB - and the date/time stamp will change. That makes your stand-by DB useless because you can no longer apply further AI files (as you found out).

If your production system is busy then the odds of there being zero in-flight transactions at the time of any particular AI file switch are extremely small. But if the system is fairly idle then you have a good chance that there will be no transactions in-flight.

We put logic into our scripts such that if the time was (about) 2am it would check and if the roll-forward that just finished had zero in-flight transactions then it would do an automatic truncate - otherwise skip it until the next night.

I hope that helps.
Ron.