[SunHELP] RE the EMC array migration question

[David Strom]

Original post at the bottom.  We have the same 2 EMC arrays, an FC4700 & 
a CX500, and we plan to migrate data (not Oracle, though) from the 
FC4700 to the CX500.  My EMC tech says that the FLARE code version 
shouldn't be a problem.  HTH.

His reply:
"I will address the SanCopy part of this...San Copy only needs to be
installed on 1 array, in this case the CX500.  It uses LUN World Wide
Names to address the LUN it is pushing data to or pulling data from, in
this case a data pull.   SanCopy is used for data migration from other
vendor's storage arrays as well, who would not have the Clariion
operating system (Flare) installed.  Therefore I do not believe there
will be any issues with a SanCopy data pull in your environment.  I will
however forward your concerns on to other internal EMC resources for
verification."

--
David Strom

 From the SunHelp Digest:

Message: 7
Date: Wed, 20 Sep 2006 14:05:17 -0400
From: listmail <listmail at triad.rr.com>
Subject: [SunHELP] REPOST: rsync for one time Oracle data migration to
	new	array
To: sunhelp at sunhelp.org
Message-ID: <451182DD.6060909 at triad.rr.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

  >>rewritten for those that are particular about presentation and for
potentially better yields of course... =)

      I would like feedback on a proposal that I have made to management
which involves migrating an Oracle E-business suite installation from an
older EMC FC4700 to a CX500 storage array.  One option proposed by EMC
was to use LVM mirroring and detach the mirror later while the system
was down.  This option does sound good because it allows us to bring the
system up while resyncing.  We don't use Vertitas Volume manager for
unlisted reasons and while I do use SDS for the root OS mirrors and have
good success with it, I do not like altering my source data or access
methods in any manner that could jeopardize its integrity.

     EMC Sancopy was also investigated, but an SSA at EMC has recently
advised us that differences in flare code between the FC and CX arrays
have lead to incompatibilities.

     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.

Do you guys have any feedback on this?  Its fuel to fire or perhaps
things I should consider.

Thanks.

2 servers Solaris 9, 2 Solaris 8
all running rsync 2.6.8