異なるプラットフォーム間でのTransportable Tablespace
___________________________________________________
この例では、TESTという名前の表領域を転送します。 表領域は、他の表領域を参照するオブジェクトなしで自己完結型である必要があるため、以下のクエリを使用して表領域osが自己完結型であるか:
dbms_ttsを実行します。transport_set_check(‘TEST’,TRUE,TRUE);
select*FROM transport_set_violations;相互参照オブジェクトがある場合は、
。 これらのオブジェクトをTESTテーブルスペースから削除します（これはテスト環境で行われているため、相互参照オブジェクトを簡単に削除できます。 本番環境で上級のDBAに相談せずにオブジェクトを削除しないでください。 どのオブジェクトがどのような依存関係を持っているかはわかりません。 TEST表領域に別の表領域の表を指す索引があるとします。 以下のpl/sql手順を使用して、これらの索引を安全に移動できます:
begin
for c1in(select index_name a1from user_indexes)
loop
execute immediate’alter index’||c1.a1|/’オンライン表領域の再構築<表領域名>’;
end loop;
end;
/
今すぐ続行し、違反を再度確認してください。 次のようなエラーが発生した場合:
SELECT*FROM transport_set_violations;
違反
—————————
違反46:Oracleサポートへのお問い合わせ
違反46:Oracleサポートへのお問い合わせ
違反46 : この問合せを実行して、違反がスローされている理由を確認します。SELECT TRIM(OBJ1_OWNER)||’,’||TRIM(OBJ1_NAME)||’,’||TRIM(OBJ1_NAME)||’,’||TRIM(OBJ1_NAME)||’,’||TRIM(OBJ1_NAME)||’,’||TRIM(OBJ1_NAME)||’,’||) || ‘, ‘ ||
TRIM(OBJ1_SUBNAME)//’,’//TRIM(OBJ1_TYPE)//) || ‘, ‘ ||
TRIM(TS1_NAME)|/’,’||TRIM(OBJ2_OWNER)) || ‘, ‘ ||
TRIM(OBJ2_NAME)||’,’||TRIM(OBJ2_SUBNAME)) || ‘, ‘ ||
TRIM(OBJ2_TYPE)||’,’||TRIM(TS2_NAME)) || ‘, ‘ ||
TRIM(CONSTRAINT_NAME)||’,’||TRIM(REASON)
FROM PLUGGABLE_SET_CHECK
WHERE MESG_ID=46;これにより、トランスポート可能な表領域に対する違反が正確に何であるかが出力されます。 これらの違反を修正し、表領域を転送するための実際の手順を開始します。 私の例では、データベース上のいくつかの列に透過的なデータ暗号化（TDE）を使用していました。 クエリでは、暗号化された列がある場合はTT_TBSを使用できないことが報告されました。 そのため、次のようなクエリを使用して暗号化した列を復号化する必要がありました。
SELECT*FROM dba_encrypted_columns;
ALTER TABLE account MODIFY(cardholder DECRYPT));列を復号化した後。 さらに進みます
1. 以下のスクリプトを使用して、ソースとターゲットの両方のエンディアン:—
— 利用可能なトランスポート可能な表領域プラットフォームの可能性は何ですか?
—
SELECT
platform_name
,endian_format
FROM V$transportable_platform
order BY platform_name
;
—
— 私のデータベースとプラットフォームの現在のエンディアンは何ですか？
—
SELECT
D.name
,TP.endian_format
FROM
v$transportable_platform TP
,v database database D
WHERE TP.platform_name=D.platform_name
;エンディアンが”little”か”big”かを報告します。 ターゲットとソースの両方でエンディアンが同じ場合は、トランスポート可能な表領域を使用する必要はありません。 表領域をエクスポートしてターゲットにインポートするだけです。 以下のように進まない場合
2。 表領域を変更し、sourceで読み取り専用モードにします。 この例では、TESTという名前の表領域をターゲット-サーバーに転送します。
ALTER TABLESPACE test READ ONLY;
3. 次に、表領域メタデータをエクスポートします。#####
exp USERID=’system/oracle@Source AS SYSDBA’TRANSPORT_TABLESPACE=y TABLESPACES=testファイル=test_repository.dmpログ=test_repository。txt###Unix###
exp\’sys/oracle AS SYSDBA\’TRANSPORT_TABLESPACE=y TABLESPACES=test FILE=test_repository.dmpログ=test_repository。txttargetに移動し、dumpfileをその表領域のデータファイルとともに任意の場所にコピーします。
imp\’sys/oracle AS SYSDBA\’TABLESPACES=test TRANSPORT_TABLESPACE=y FILE=test_repository.dmp datafiles=’users_01.dbf’
4. 上記までは、同じエンディアン情報を持つマシンに表領域をエクスポートするときのためです。 別のエンディアンの場合は、以下のように進みます。 Solaris64ビットSPARC(BIG)からWindows32ビット(Little)
5に変換します。 RMANおよびdb_file_name_convertを使用したデータファイルの変換#ソース・マシン:元のファイル名
RMAN>表領域’TEST’
をプラットフォーム’Microsoft Windows IA(32-bit)’に変換
format=’/datafiles/rmanbkp/%N_%f’
並列処理= 4;## 次の方法を使用します。: 表領域’TEST’をプラットフォーム’Microsoft Windows IA(32-bit)’に変換する
3db_file_name_convert’/datafiles/oradata/SWX’,’/datafiles/rmanbkp’
4並列処理’/datafiles/oradata/SWX’,’/datafiles/rmanbkp’,’/datafiles/oradata/SWX’,’/datafiles/oradata/SWX’,’/datafiles/oradata/SWX’,’/datafiles/oradata/SWX’,’/datafiles/oradata/SWX’,’/datafiles/oradata/SWX’,’/datafiles/oradata/= 4;ファイルが変換された後、それは’/datafiles/rmanbkp’にあります。 これらの変換されたファイルをTT_TBSのメタデータダンプとともにコピーし、ソースサーバーに配置してimportを実行します:
imp USERID=’SYSTEM/password@target AS SYSDBA’
TRANSPORT_TABLESPACE=y
DATAFILES=’C:\datafiles\test01…..DBF’,’C:\datafiles\test02…..DBF’
TABLESPACES=test
FILE=test_repository.dmp上記の場合、ソースプラットフォーム上のファイルを変換しました。 ただし、ターゲットプラットフォームでもこれを行うことができます。 たとえば、ファイルtest01をコピーできます。dbfは、windows Server2003 32ビットのターゲットマシン上のメタデータダンプと一緒に変換し、そこに変換します:
RMAN>convert
2>データファイル’c:/users01…..dbf’##ソースサーバー
3>形式のデータファイルを配置するディレクトリ’c:/datafiles/rmanbkp/%N_%f’##変換されたファイルを取得するディレクトリ
4> ;この方法では、ディレクトリで指定された形式でファイルが作成されます。
しかし、なぜターゲットプラットフォーム上のデータファイルを正確に変換したいのですか？ その理由の1つは、ダウンタイムが短くなるため、ターゲット-ホストへのコピーが実行されている間のみ、表領域を読取り専用状態にする必要がある データファイルをトリプルミラー化し、表領域を読取り専用にし、3番目のミラーを解除して、すぐに表領域を読取り/書込みにすることができます。 この第三のミラーは、ターゲットシステムに取り付けられ、余暇に変換することができます。 この配置により、表領域が読取り専用のままである必要がある期間が最小限に抑えられます。
もう一つの理由はパフォーマンスかもしれません。 OLTPデータベースの負荷が一定である可能性があり、RMANの変換操作を使用すると、システムに必要以上の負荷がかかる場合があります。 代わりに、変換をデータウェアハウスサーバーにオフロードすることができ、通常はより多くのCpuを並列操作に使用できます。
