トランスポータブル表領域とは

異なるデータベース間で高速にデータを転送する方法。
データ量が非常に多い場合、ダンプファイルにエクスポートインポートするよりもデータを高速に転送できる

概念

トランスポータブル表領域を一言で言うと、データベース間のデータ転送を「データファイルそのもの」のコピーで表現する仕組み。（？）

データが入ったままのデータファイルを転送するため、データ移行を比較的短時間で実行できる

ただ、メタデータも移行する必要あり。

トランスポータブル表領域の方法は2種類

①Data Pumpトランスポータブル表領域

転送対象の表領域を読み取り専用にする必要があるため、一時的にその表領域への変更処理が出来なくなる

②RMANトランスポータブル表領域

転送対象の表領域を読取り専用にする必要が無いので、可用性に優れる。
ただ、内部的に補助インスタンスが作成され、リカバリ処理（バックアップとアーカイブログファイルを用いる）が実行されるため処理負荷が発生する。また、作業用のディスク領域も必要。

①Data Pumpトランスポータブル表領域のコマンド例

ソースデータベース側のコマンド

#ts01表領域を読取り専用に変更
Alter tablespace ts01 READ ONLY;

#メタデータをエクスポート
!expdp system/password123 directionary=DATAPUMP_DIR DUMPFILE=ts01.dmp transport_tablespaces=ts01 reuse_dumpfilea=Y

#データファイルをコピー
!cp /u01/app/oracle/oradata/orcl/ts01.dbf /u01/app/oracle/oradata/c102/ts01.dbf

#表領域を読み書き可能に戻す
Alter tablespace ts01 READ WRITE;

#メタデータのダンプファイルをコピー
!cp /u01/app/oracle/admin/orcl/dpdump/ts01.dmp /u01/app/oracle/admin/c102/dpdump/ts01.dmp

ターゲットデータベース側のコマンド

#メタデータをインポート
!impdp system/oracle DIRECTORY=DATA_PUMP_DIR DUMPFILE=ts01.dmp transport_datafiles='/u01/app/oracle/oradata/c102/ts01.dbf'

#表領域がトランスポートされたことを確認

select tablespace_name,plugged_in,status from DBA_TABLESPACES where tablespace_name='TS01';

#トランスポートされた表領域を読み書き可能に

alter tablespace ts01 READ WRITE;

②Data Pumpトランスポータブル表領域のコマンド例

ソースデータベース側のコマンド

#TRASPORT TABLESPACEを実行してトランスポータブル表領域に必要なファイルを作成
#TABLESPACE DESTINATIONに指定したディレクトリにトランスポート用のデータファイルを作成
#AUXILIARY DESTINATIONに指定したディレクトリに補助インスタンス用のファイルを一時的に配置
#DATAPUMP DIRECTORYに指定したディレクトリオブジェクトの場所にメタデータのダンプファイルを出力

TRANSPORT TABLESPACE USERS
 TABLESPACE DESTINATION '/u01/app/oracle/admin/orcl/rman_transdest'
 AUXILIARY DESTINATION '/u01/app/oracle/admin/orcl/rman_auxdest'
 DATAPUMP DIRECTORY DATA_PUMP_DIR

以上のファイルを移行先に転送した後、ターゲットDBの動作は同様。

トランスポータブル表領域の制限事項

・ソースDBとターゲットDBは原則的に同じキャラクタセット

・転送対象外の表領域のオブジェクトを参照してはいけない

・SYSTEM表領域やSYSAUX表領域などの管理用表領域や暗号化された列がある表を含む表領域は転送できない

クロスプラットフォーム・トランスポータブル表領域

データファイルはそのプラットフォーム(CPUやOS)のエンディアンに合わせた形式になっているため、トランスポータブル表領域においてソースDBとターゲットDBでエンディアンが異なる場合、転送するデータファイルをRMANで変換する必要がある。

異なるプラットフォームでもエンディアンが同一であれば、データファイルの変換は必要なし！

＊エンディアン：コンピュータ内部で複数バイトのデータを扱う時に、データを配置する順番。

プラットフォームのエンディアン形式はv$transportable_platformで確認することが出来る

select platform_id,platform_name,endian_format
from v$transportable_platform
order by platform_id;

現在のDBのエンディアン形式を確認する場合は以下のようにビューを結合する

select t.endian_format,d.platform_id,d.platform_name
from v$database d,v$transportable_platform t
where t.platform_id=d.platform_id;

クロスプラットフォーム・トランスポータブル表領域の方法は２つ

①イメージコピーによるクロスプラットフォーム表領域

②バックアップセットによるクロスプラットフォーム表領域

以上の２つともにソースＤＢでエンディアン変換を行う場合とターゲットＤＢでエンディアン変換を行う場合の2パターンがある。
ターゲットDB側でエンディアン変換を実行するのが一般的。

①イメージコピーによるクロスプラットフォーム表領域について

ソースＤＢ側でエンディアン変換する場合

convert tablespace users
 TO PLATFORM = 'Linux IA (32-bit)'
 DB_FILE_NAME_CONVERT='/data1','/conv';
#変換前のファイル名に含まれる文字列'/data1'が'/conv'に変換され、変換後のファイル名になる

ターゲットDB側でエンディアン変換する場合

CONVERT DATAFILE '/tmp/data/*'
 FROM PLATFORM = 'Solaris[tm] OE (32-bit)'
 DB_FILE_NAME_CONVERT='/tmp/data','/oradata';

②バックアップセットによるクロスプラットフォーム表領域

特徴
・未使用領域の圧縮を行うことが出来るので、イメージコピー方式に比べて、データ転送時間を短くすることが出来る
・バックアップセットでのバックアップ実行時に、あわせてメタデータのエクスポートを実行できる。エクスポートしたダンプファイルはバックアップセット形式になる
・作成されるバックアップセットの情報はRMANリポジトリに記録されない

クロスプラットフォーム表領域の制限について

ソースDBとターゲットDBにおいて、COMPATIBLE初期化パラメータは10.0以上である必要がある

*基本的にCOMPATIBLE初期化パラメータはDBのバージョン番号に合わせるようです