This discussion is archived
5 Replies Latest reply: Dec 9, 2012 2:48 PM by Srini Chavali-Oracle RSS

4 TB database cross platform upgrade

vlethakula Expert
Currently Being Moderated
I would like to know the best practices, here is the scenario:


database size: 4TB
storage : File system
OS: Solaris
Endian Format : Big
DB version :

OS: Linux x86_64
Endian: Little
DB version:

Edited by: vlethakula on Nov 21, 2012 1:34 PM
  • 1. Re: 4 TB database cross platform upgrade
    808420 Explorer
    Currently Being Moderated
    The endian difference means you can't restore backup pieces with RMAN... you need to use other method like expdp/impdp or CTAS

    Approach 1: expdp to filesystem -> scp -> impdp from filesystem (very slow)

    Approach 2: expdp schema, create schema in the new database, create a db_link, and finally perform insert from select @olddb (slow and risky because REDO logs)

    Approach 3: Mount a NFS filesystem and use named pipes as expdp output an impdp input ... in this way you can move the database "on the fly"

    Approach 4: Migrate the 10g database to 11g, and then build a logical standby in the new system (see Standby Database on a Source and target of different endian formats

    In any way, you need to test very well the solution
  • 2. Re: 4 TB database cross platform upgrade
    onedbguru Pro
    Currently Being Moderated
    First of all, doing a file-by-file conversion of a 4TB db is going to be very painful. I would try to stay with Solaris if I could - the systems are much more robust in terms of sheer CPU and I/O performance. But, companies don't always make the right choices.

    I would test this a couple of times before I would call it good. That being said, start here:

    While the version is 10.2 in these docs, they still apply in 11gR2.
  • 3. Re: 4 TB database cross platform upgrade
    Victor Armbrust Oracle ACE
    Currently Being Moderated
    I just done the same migration few months later (difference it was to exadata)

    I would suggest you to use TTS (transportable tablespace) it is the most effective way.

    You should use the MOS note below

    How to Move Tablespaces Across Platforms Using Transportable Tablespaces With RMAN [ID 371556.1]    

    - Check platform


    ----------- -------------------------------- --------------
              1 Solaris[tm] OE (32-bit)          Big
              2 Solaris[tm] OE (64-bit)          Big
              7 Microsoft Windows IA (32-bit)    Little
             10 Linux IA (32-bit)                Little
              6 AIX-Based Systems (64-bit)       Big
              3 HP-UX (64-bit)                   Big
              5 HP Tru64 UNIX                    Little
              4 HP-UX IA (64-bit)                Big
             11 Linux IA (64-bit)                Little
             15 HP Open VMS                      Little
              8 Microsoft Windows IA (64-bit)    Little
              9 IBM zSeries Based Linux          Big
             13 Linux 64-bit for AMD             Little
             16 Apple Mac OS                     Big
             12 Microsoft Windows 64-bit for AMD Little
             17 Solaris Operating System (x86)   Little

    To convert datafiles you should use RMAN CONVERT

          TO PLATFORM="Linux x86 64-bit"
          FROM PLATFORM="HP-UX IA (64-bit)"
          FORMAT '+DATA/db/datafile/%u_%p_%c'

    It is not a complicated procedure but you shoulday attention in every step in order to convert the database from Solaris to Linux.

    I wrote a full step by step to do this migration however it is in portuguese.

  • 4. Re: 4 TB database cross platform upgrade
    mrmessin Oracle ACE
    Currently Being Moderated
    Have you considered the use of Golden Gate, that might be an option for the migration of such a large database to minimize the downtime.
  • 5. Re: 4 TB database cross platform upgrade
    Srini Chavali-Oracle Oracle ACE Director
    Currently Being Moderated
    There are various options discussed in this presentation that show you how to limit downtime.

    Almost all of them, like the use of Goldengate, will require additional licenses/costs, which may or may not be affordable.