checksum mismatch while roll forwarding AI file.

Hi All,

In one of our database copy we follow After image concept.
ai files are generated at production and transfered to anathor location where they are roll forwarded.
We have found that there is a mismatch in checksum of file and DB.
In the automated process if there is a mismatch that ai file is retransferred and applied.
In DB log it shows that new file has been rollforwarded but the issue is that
this process has become too slow .It takes 50 min for DB to roll forward a single ai file of 100 MB. Secondly all AI files after this show a mismatch.
progress 9.1E (planning to upgrade to 10.2B).
OS Solaris SUN Sparc.
CPU utilisation is 92%.
Please assist.

Thanks.
 

TomBascom

Curmudgeon
This sounds like the "long redo" problem.

It can sometimes be fixed by truncating the bi file on the target -- but sometimes that may result in a target db that you can no longer roll forward against and then you get to copy over a new backup and start again.

The "long redo" issue is fixed in 10.2B.
 
Thanks Rudra and Tom.
Issue still exists. the rollforwarding of ai files is too slow.
what we found is that every new ai file shows a mismatch which results into delay.
Can you please explain me that if a file shows mismatch we retransfer it and it gets rollforward but all new coming files still show
mismatch resulting into delay.What may be the root cause for mismatch.
 

TomBascom

Curmudgeon
I have no idea.

It /might/ help if you provided actual error messages and numbers (especially the ones that first started this problem) but 9.1D is so ancient, obsolete and unsupported that it probably doesn't really matter.

The simplest way to address these sorts of issues is to get a new backup (preferably a cold backup with a truncate bi file), restore it on your target system and then restart the roll forward processes.

You should also modify the process which transfers the ai files to generate and verify a checksum in the transfer process. Or otherwise validate that the file that was on machine A is the same as the file that shows up on machine B.

Having said all of that -- the "long redo" may still plague you. It is not fixed until you get to 10.2.
 
Top