[SunHELP] REPOST: rsync for one time Oracle data migration to new array

velociraptor velociraptor at gmail.com
Thu Sep 21 08:22:22 CDT 2006

On 9/20/06, listmail <listmail at triad.rr.com> wrote:
>  >>rewritten for those that are particular about presentation and for
> potentially better yields of course... =)
>     I have cloned these installations many times both locally an across
> the wire using rsync and haven't had anything crop up which would lead
> me to believe my data was not 1 to 1.  I have proposed that I would
> perform an initial sync of the files during the day to get the majority
> of the work done before a migration weekend.  When the system could be
> brought down I would have rsync copy or delete what it needs on the
> target to get things 1:1 with the source.  Since the Oracle database
> files are every changing and large I've chosen to skip these files until
> we are down and executing the migration.
>      One of the questions I was asked by management was if rsync had any
> directory depth limitations.  My initial response is that I think rsync
> would complain if it ran into something like and I also believe that
> rsync would use up the system memory before it ran into a depth
> limitation.  I'm pretty certain that the file types (ie. regular files,
> links, etc) in an Oracle installation can be handled by rsync.  For any
> option I think most of the concern lies within mapping the luns
> correctly, copying the data to the right luns, making sure all relevant
> mount points for each server are considered, and using the original
> mount point names for the new luns.

I have not seen any issues with directory depth with rsync, though I
have seen problems with long filenames on Mac OS X.  The latter is a
corner case issue between OS X and Windows and should not impact

At several of my work locations, we have used rsync for just this kind
of duplication, though in our case it was across the WAN link for
DR/business continuance purposes.

One option you might want to consider for the Oracle databases is
leveraging your normal backup strategy to get the new system
completely built and tested before the final data migration/cut over.

Another thing to look at to reduce load on the busy live filesystems
is using Solaris' snapshot capability (fssnap).  The Solaris snapshot
system is somewhat akin to Veritas', but has the downside that the
snapshots don't survive across a reboot.

Good luck with your migration.

More information about the SunHELP mailing list