Re: Oracle 10gR2 Multi-Terabyte Database Cross-Plathform Migration Method

Hi,

We have migrated 3 databases with 800 GB form Windows 2000 platform to HP-UX.
The steps that we have used are:

1. create a instance on HP-UX
2. mount 3 nfs from windows to hp-ux with 3 gigabit nic's
3. export metadata (with read only tablespaces)
4. use rman convert to convert the windows datafiles to hp-ux with 3 threads

[]'s
Renato Gomes

On 4/10/08, Finn Jorgensen <finn.oracledba_at_gmail.com> wrote:
>
> Hi.
>
> As can be seen in the below query HP Tru64 is Little Endian and AIX is Big
> Endian, which prevents you from doing DB X platform transports, but you can
> still do tablespace x platform transports as you suggest.
>
>
> 1* select * from V_$TRANSPORTABLE_PLATFORM order by platform_name
>
> PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
> ----------- ---------------------------------------- --------------
> 6 AIX-Based Systems (64-bit) Big
> 16 Apple Mac OS Big
> 19 HP IA Open VMS Little
> 15 HP Open VMS Little
> 5 HP Tru64 UNIX Little
> 3 HP-UX (64-bit) Big
> 4 HP-UX IA (64-bit) Big
> 18 IBM Power Based Linux Big
> 9 IBM zSeries Based Linux Big
> 13 Linux 64-bit for AMD Little
> 10 Linux IA (32-bit) Little
> 11 Linux IA (64-bit) Little
> 12 Microsoft Windows 64-bit for AMD Little
> 7 Microsoft Windows IA (32-bit) Little
> 8 Microsoft Windows IA (64-bit) Little
> 20 Solaris Operating System (AMD64) Little
> 17 Solaris Operating System (x86) Little
> 1 Solaris[tm] OE (32-bit) Big
> 2 Solaris[tm] OE (64-bit) Big
>
> 19 rows selected.
>
>
> Since you have to convert every tablespace in this scenario it will still
> take a long time. If you could have done DB X platform transportation you
> would only have had to convert the system tablespace and any other
> tablespace containing UNDO.
>
> I would be very leary of running any size database (much less multi
> terabyte) across NFS, but maybe that's just me. There was a recent
> discussion of this very topic on this list. There may be some tips for you
> there. Perhaps you could look into if it's possible to first mount the SAN
> disks to the Tru64 server in location Y, restore the tapes and bring up the
> standby as you suggest. When you're ready for the migration, you then
> dismount the filesystems and move the SAN storage to the AIX server and
> mount them there. I'm not sure if that's doable in your scenario. If you
> were all Veritas VM/FS I think it would be.
>
> Good luck. Let us know how it goes.
>
> Finn
>
>
>
> On 4/10/08, H.Tonguç YILMAZ <tonguc.yilmaz_at_gmail.com> wrote:
> >
> > Hi all,
> >
> > We have one 10.2.0.3 database on Tru64(source, server A, location X) and
> > another new AIX(target, server B, location Y). This is our CRM database,
> > with xx TB data and 7*24 availability needs. To reduce the downtime of this
> > multi-terabyte database cross-plathform migration, IBM advised an async
> > change data capture method(this is not Oracle's CDC, IBM prefers to work
> > with the company called Goldengate).
> >
> > But Goldengate has several important constraints related to some Oracle
> > native data types and table types. So we started to study a B plan, the
> > summary of this plan is as below;
> >
> > 1. take a tape backup of source database at Tru64(server A, location
> > X) and restore it to target AIX(server B, location Y).
> > 2. mount AIX's filesystems to another Tru64(server C, location Y)
> > over NFS.
> > 3. open restored database as a physical standby on Server C and apply
> > archives to catch up production.
> > 4. activate database on Server C as primary.
> > 5. create a new instance on Server B(AIX).
> > 6. take tablespaces to read-only mode on Server C and export
> > metadata(standart cross-platform transportable tablespace step 1).
> > 7. use RMAN convert command on Server B for the datafiles of Server
> > C(in fact these files are on Server B and server C sees them over NFS).
> > 8. finish convert and import metadata on Server B, and open the
> > database.
> >
> > During these steps since the datafiles will be transfered over local
> > area we plan to have at most 8 hours downtime.
> >
> > We will be testing these steps in details, but I wanted to have your
> > comments also.
> >
> > --
> > Best Regards,
> > H.Tonguç YILMAZ
> >
> > http://tonguc.yilmaz.googlepages.com/
>
>
>

--
http://www.freelists.org/webpage/oracle-l