Kbase P26274: Why does using procopy with proutil BUSY option corrupt the target database?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/27/2010 |
|
Status: Verified
SYMPTOM(s):
Is it possible use procopy with proutil BUSY option
procopy running as background session: nohup procopy <sourcedb> <targetdb> &
To verify if procopy command has finished using: proutil <sourcedb> -C BUSY
The <targetdb> is then corrupted
Inconsistency between timestamps on the db and bi result on <targetdb> error 9213
Extent <file-name> has a different last opened date <timestamp>, (9213)
Extent <dbname.bi> has a different last opened date <dbname.db>, (9213)
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CAUSE:
procopy doesn't lock the source or target databases (no .lk file) so that when you issue a proutil -C BUSY, you get a message back that it's not busy and can therefore access the database. It is not the proutil -BUSY operand (-C HOLDER would be another tool that could be used here) that causes the corruption, it is just that we assume incorrectly that the database can be accessed before the procopy operation has completed. In doing so, roll back recovery ensues and the bi file timestamps will be out of sync with the master block (.db)
FIX:
Rather than running the proutil -BUSY to monitor the completion of the procopy operation, consider:
Running a:
"ps -ef | grep procopy"
to find when the process ends
- or -
send the output to a file:
nohup procopy <source> <target> > pcopy.out &
and then monitor "pcopy.out" for "Copy complete (6722)" before accessing the database again.