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

  • From: "Finn Jorgensen" <finn.oracledba@xxxxxxxxx>
  • To: tonguc.yilmaz@xxxxxxxxx
  • Date: Thu, 10 Apr 2008 10:11:07 -0400


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

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


On 4/10/08, H.Tonguç YILMAZ <tonguc.yilmaz@xxxxxxxxx> wrote:
> Hi all,
> We have one 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

Other related posts: