File Corruption

Kevin Stussman kevins at
Fri Sep 9 18:06:50 GMT 2005

We are using rsync to transfer Oracle redo logs from one system to
another over a WAN/VPN. The problem we are having is that 1 out of about
500 or so files sent is corrupted. The receiving Oracle server produces
a message like this:

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00283: recovery session canceled due to errors
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 116744 change 12227272 time
ORA-00334: archived log:

Comparing the md5sum on the two files (original and sent copy)
produces different hashes, but the byte sizes are the same. When the
good file is manually re-sent again via rsync, it works fine and oracle
picks it right up. This leaves two possibilities that I can think of:

1. Somewhere in transport, the file got corrupted, (i.e. network,
compression/decompression, etc)
2. The file that the Oracle producer created was not completely finished
when rsync picked it up. Although the file sizes on each machine were
the same..(I'm looking deeper into this).

My questions are:
- Has anyone had any similar problems with rsync and transferring oracle
redo logs?
-  Is there way to ensure that rsync checks the integrity of the
transferred file when it is complete? (i.e. do a checksum on the new
receiver file and the old sender file before completing...does this
already happen behind the scenes?) This file would *not* have already
existed on the receiver side and is deleted from the sender side when

Thanks for any pointers,


rsync  version 2.6.6  protocol version 29
Oracle 9i
RHES 3 (latest patches and kernel)

Rsync command used
/usr/local/bin/rsync  --remove-sent-files --include '*/'  --include
'*.arc' --exclude '*' -acvze "ssh -x -c arcfour"
s/outgoing/ /oracle/logsync/files/incoming/remote-site/

More information about the rsync mailing list