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
09/08/2005
21:43:34
ORA-00334: archived log:
'/oracle/logsync/files/incoming/yyc-db02-raw/GWLPROD_5879.arc'
---
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
completed.
Thanks for any pointers,
Kevin.
Details:
--------
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"
remote-site:/oracle/logsync/file
s/outgoing/ /oracle/logsync/files/incoming/remote-site/
On Fri, Sep 09, 2005 at 12:06:50PM -0600, Kevin Stussman wrote:> - Is there way to ensure that rsync checks the integrity of the > transferred file when it is complete?Rsync validates that all the data it writes out matches the checksum of the data on the sending side. The only known way to create a corrupted destination file is to specify --inplace and --sparse together (because it can make rsync think that it wrote some zeros when it didn't really). Since that doesn't seem to be your problem, the most likely cause is that the source file was in a corrupted state when it was copied (i.e. the data was currently being written on the sending side, and the update was not complete). ..wayne..
On Fri, Sep 09, 2005 at 12:06:50PM -0600, Kevin Stussman wrote:> 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:...> Comparing the md5sum on the two files (original and sent copy) > produces different hashes, but the byte sizes are the same....> My questions are: > - Has anyone had any similar problems with rsync and transferring oracle > redo logs?I've seen problems with our SuSE Linux installation- and updateserver. After moving to a bigger disk I had trouble with SuSE complaining about corrupted rpm-files. To moved the data by copying everything to an other machine and back, but I do not remember the details how this happened. So I wasn't able to track the problem down to it's cause yet. :-( The corruption doesn't concerned the filesize in this case. This happened on SuSE Linux 9.2 i686, maybe x86_64 too. I used the default rsync that came with SuSE 9.2: rsync version 2.6.3pre1 protocol version 28 Copyright (C) 1996-2004 by Andrew Tridgell and others <http://rsync.samba.org/> Capabilities: 64-bit files, socketpairs, hard links, acls, symlinks, batchfiles, inplace, IPv6, 64-bit system inums, 64-bit internal inums, SLP I'm going to have a look at that now :-/ cu, Stefan -- Stefan Nehlsen | ParlaNet Administration | sn@parlanet.de | +49 431 988-1260 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20050912/ea3236f3/attachment.bin