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

[listmail]

I really appreciate the response.  Since posting I've actually rsync'd a 
40gb mount point on our dev environment
which contains two E-business middle tier installations. I accomplished 
that in about 1.5 hours total. rsync worked
wonderfully once again.  We are up and running in dev on the new fs 
testing and things look good so far.

We have multiple servers mostly 20gb or less in the production 
configuration. Being able to have visibility
to two arrays at the same time allows me do the migration in stages (per 
server) and still keep the original
sources on standby.

 > 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.

Yes, and fortunately the dev environment is separate and a clone so I 
can do those tests with no impact to current
production.

 > Another thing to look at to reduce load on the busy live file systems
 > 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.

I made it a point in the original design to have the busy datafiles on 
completely seperate LUN's, all the other mounts
are low reads and text log writes and should be tolerant of the rsync.


velociraptor wrote:
> 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
> Solaris.
>
> 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.
> =Nadine=
> _______________________________________________
> SunHELP maillist  -  SunHELP at sunhelp.org
> http://www.sunhelp.org/mailman/listinfo/sunhelp