oracle运维之--RMAN 异构平台迁移（修改中）

 如题:
最近公司有个项目中涉及了数据迁移的问题:
源库的环境是:redhat as 4  oracle 10.2.0.1(64位)单实例 (裸设备) ,硬件平台(IBM X3650)
目标库是:aix 5.3 . oracle 10.2.0.4(64位) RAC (裸设备)  ,硬件平台 (IBM P595)
数据量有700个G左右

想用rman 来做迁移,把源库的数据迁移到目标库上去.
请高手支招,有什么好的方法:

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

你的环境没办法用跨平台rman迁移，因为源和目标的ENDIAN format不同，只能使用表空间传送方式。

SQL> select PLATFORM_NAME, ENDIAN_FORMAT from V$TRANSPORTABLE_PLATFORM;

PLATFORM_NAME                            ENDIAN_FORMAT
---------------------------------------- --------------
Solaris[tm] OE (32-bit)                  Big
Solaris[tm] OE (64-bit)                  Big
Microsoft Windows IA (32-bit)            Little
Linux IA (32-bit)                        Little
AIX-Based Systems (64-bit)              Big
HP-UX (64-bit)                          Big
HP Tru64 UNIX                            Little
HP-UX IA (64-bit)                        Big
Linux IA (64-bit)                        Little
HP Open VMS                              Little
Microsoft Windows IA (64-bit)            Little
IBM zSeries Based Linux                  Big
Linux 64-bit for AMD                    Little
Apple Mac OS                            Big
Microsoft Windows 64-bit for AMD        Little
Solaris Operating System (x86)          Little
IBM Power Based Linux                    Big

至于数据库文件都在裸设备上，这个倒是可以把数据库文件先rman到dbf文件，然后通过重建控制文件方式使用dbf文件，迁移到AIX后，将dbf文件rman到AIX裸设备上即可，再次重建控制文件使用裸设备。

||||||||||||||||||||||||||||

本来考虑做EXP/imp 或者datapump进行数据迁移,
但是数据量比较大了,原来应用部分又不是我们自己的系统,生产库最多停10个小时.没办法达到要求.

我查了下,跨版本的rman迁移好象是10G以后才支持,可以用表空间传输的方法来做.
但是跨平台的数据库rman迁移真没做过.且源库目标库数据文件都存储在裸设备上,不好搞啊!

 

|||||||||||||||||

Metalink DOC 243304.1

10g : Transportable Tablespaces Across Different Platforms

可以参考下

||||||||||||||||||||

贴在这里.我再看下
If the two platforms are not on the same endian format, you will need to use TRANSPORTABLE TABLESPACE instead of CONVERT DATABASE
see Note 243304.1 10g : Transportable Tablespaces Across Different Platforms


PURPOSE
-------

This bulletin explains how tablespaces can now be transported from any platform
to any platform in 10g, provided the platforms belong to the list below:

  SQL>  select * from v$transportable_platform;

  PLATFORM_ID PLATFORM_NAME                    ENDIAN_FORMAT
  ----------- ------------------------------  --------------
            1 Solaris[tm] OE (32-bit)          Big
            2 Solaris[tm] OE (64-bit)          Big
            7 Microsoft Windows NT            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

The output of the query can change. So please use the query above to find the
current support platforms.
In previous releases, the transportable tablespace feature allowed the transfer
between platforms of the same architecture only.


SCOPE & APPLICATION
-------------------
- Publish structured data and distribute for integration on other platforms
- Distribute data from a DW environment to data marts (typically different platforms)
- Share read only tablespaces across heterogeneous clusters
- Migrate a database from one platform to another by only rebuilding the catalog
  and transporting the datafiles


Steps
-----
1. Check for restrictions
  ----------------------
  Review the "Limitations on Transportable Tablespace Use" section in Note 371556.1.
  Among other things, objects that reside in the SYSTEM tablespace and objects owned
  by SYS will not be transported.  This includes but is not limited to users, privileges,
  PL/SQL stored procedures, and views.
 
  If you use spatial indexes, apply the solution in Note 579136.1 "IMPDP TRANSPORTABLE
  TABLESPACE  FAILS for SPATIAL INDEX)" before continuing.


2.  Prepare the database
    --------------------
    Check that the tablespace will be self-contained
    ------------------------------------------------
        SQL>execute sys.dbms_tts.transport_set_check('TBS1,TBS2', true);
        SQL> select * from sys.transport_set_violations;
            ==>These violations must be resolved before the tablespaces
                can be transported

  Set the tablespace to READ ONLY
  -------------------------------
      SQL> alter tablespace REPOSIT read only;
      Tablespace altered.


3. Export metadata
  ---------------
      <HP-UX> exp userid=/'/ as sysdba/' transport_tablespace=y
                                        tablespaces=reposit
                                        file=tts.dmp log=exp_tts.log
                                        statistics=none

      Export: Release 10.1.0.1.0 - Beta on Mon Nov 24 11:49:49 2003
      ...
 
      Note: table data (rows) will not be exported
      About to export transportable tablespace metadata...
      For tablespace REPOSIT ...
      . exporting cluster definitions
      . exporting table definitions
      . . exporting table                MTG_COL_DEP_CHG
      . . exporting table                  MTG_DATABASES 
      ....
      . . exporting table              SYBASE11_SYSUSERS
      . exporting referential integrity constraints
      . exporting triggers
      . end transportable tablespace metadata export
      Export terminated successfully without warnings.

    Review the export log for warnings and errors and resolve issues
    before continuing.  Failure to do so can result in data loss.


4. Check the endianness of the target database and convert, if necessary
  ---------------------------------------------------------------------
  Case 1
  ------
      The source platform is Sun SPARC Solaris: endianness Big
      The target platform is HP-UX (64-bit):    endianness Big

          SQL> select PLATFORM_ID , PLATFORM_NAME from v$database;

          PLATFORM_ID PLATFORM_NAME
          ----------- ------------------------------
                    3 HP-UX (64-bit)

 
      No conversion is needed for files that (1) do NOT contain UNDO/Rollback
      segments and (2) have a source and target OS with the same endianness. 
      Refer to Note 415884.1  "Cross Platform Database Conversion
      with same Endian" to determine which files contain UNDO/Rollback segments.


  Case 2
  ------
      The source platform is Microsoft WIndows NT:  endianness Little
      The target platform is HP-UX (64-bit):        endianness Big

      If we move the files and import the tablespace:

          . importing SYS's objects into SYS
          IMP-00017: following statement failed with ORACLE error 1565:
          "BEGIN  sys.dbms_plugts.beginImpTablespace('TBS_TTS',37,'SYS',1,0,8192,2,57"
          "54175,1,2147483645,8,128,8,0,1,0,8,462754339,1,1,5754124,NULL,0,0,NULL,NULL"
          "); END;"
          IMP-00003: ORACLE error 1565 encountered
          ORA-01565: error in identifying file '/database/db101b2/V101B2/datafile/reposit01.dbf'
          ORA-27047: unable to read the header block of file
          HP-UX Error: 2: No such file or directory
          Additional information: 2
          ORA-06512: at "SYS.DBMS_PLUGTS", line 1540
          ORA-06512: at line 1
          IMP-00000: Import terminated unsuccessfully

    You have to convert the files :
    --> locally before the import step so that the files are endian compatible:

    <Solaris> rman target=/

    Recovery Manager: Release 10.1.0.1.0 - 64bit Beta
    connected to target database: V101B2 (DBID=3287908659)

    RMAN> convert tablespace 'REPOSIT'
    2>  to platform="Linux IA (32-bit)"
    3>  db_file_name_convert='/database/db101b2/V101B2/datafile/reposit01.dbf',
    4>                      '/tmp/reposit01.dbf';

    Starting backup at 24-NOV-03
    using target database controlfile instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=8 devtype=DISK
    channel ORA_DISK_1: starting datafile conversion
    input datafile fno=00006 name=/database/db101b2/V101B2/datafile/reposit01.dbf
    converted datafile=/tmp/reposit01.dbf
    channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:01
    Finished backup at 24-NOV-03

    The converted datafile is staged in /tmp directory until it is copied to the
    target server.

    --> remotely on the target server after having copied them on the server.


5. Move datafiles and export dump file
  -----------------------------------
      $ftp tts.dmp 
          + 
            /database/db101b2/V101B2/datafile/reposit01.dbf (no conversion)
          or
            /tmp/reposit01.dbf (converted file if conversion had been required)


6. Import metadata
  ---------------
      $ imp userid=/'/ as sysdba/' TRANSPORT_TABLESPACE=Y
                                  datafiles=/database/db101b2/V101B2/datafile/reposit01.dbf
                                            (or /tmp/reposit01.dbf )
                                  file=tts.dmp log=imp_tts.log
 
      Import: Release 10.1.0.1.0 - Beta on Mon Nov 24 03:37:20 2003

      Export file created by EXPORT:V10.01.00 via conventional path
      About to import transportable tablespace(s) metadata...
      ...
      . importing SYS's objects into SYS
      . importing OMWB's objects into OMWB
      . . importing table              "MTG_COL_DEP_CHG"
      ...
      . . importing table            "SYBASE11_SYSUSERS"
      Import terminated successfully without warnings.

      Review the import log for warnings and errors and resolve issues
      before continuing.  Failure to do so can result in data loss.


7. Set the imported tablespace to READ WRITE
  ---------------------------------------
      SQL> alter tablespace reposit read write;
      Tablespace altered.