翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
フェーズ 2 — ロールフォワードフェーズ (ソースデータベースはオンラインのまま)
ロールフォワードフェーズを必要な回数繰り返して、宛先データファイルをソースデータベースに追いつかせることができます。
ロールフォワードフェーズは、次のステップで構成されます。
-
ソースデータベースから増分バックアップを作成します。
-
バックアップを宛先システムに転送します。
-
バックアップを宛先システムのエンディアン形式に変換します。
-
変換された宛先データファイルのコピーにバックアップを適用して、ロールフォワードします。
増分バックアップを繰り返すたびに、バックアップにかかる時間は短くなり、宛先データファイルのコピーはソースデータベースと同じ状態になります。
ステップ 1: 増分バックアップを並列に実行する
ソースシステムで転送される表領域グループの増分バックアップを並列に実行します。
この手順では、xtt.properties ファイルにリストされているすべての表領域に対して増分バックアップを作成します。
ソースシステムでBLOCK CHANGE TRACKING機能を有効化できれば、増分バックアップの時間を大幅に短縮できます。
次のコマンドは、フルバックアップ後の次の SCN を自動的に認識します。
cd /u01/oracle/expimp/xtt<nn> export TMPDIR=/u01/oracle/expimp/out/out<nn> $ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3
ステップ 2: 増分バックアップと res.txt ファイルを宛先システムに転送する
十分な帯域幅がある場合は、 Direct Connectを使用して転送時間を短縮できます。
src_scratch_location および dest_scratch_location 間で増分バックアップを転送する res.txt ファイルを、$TMPDIR のソースシステムと $TMPDIR の宛先システム間で転送する。
複数の増分バックアップを行う場合は、最後の増分バックアップの後に res.txt ファイルをコピーしなければ、宛先システムで適用することはできません。
[source]$ scp $TMPDIR/res.txt oracle@[dest]:/u01/oracle/expimp/out/out<nn> [source]$ scp <src_scratch_location>/* oracle@[dest]:<dest_scratch_location>
ステップ 3: 増分バックアップを変換して適用する
増分バックアップを宛先システムのエンディアン形式に変換し、宛先システムの宛先データファイルのコピーに適用します。
このガイドでは、4 つの表領域グループがあることを前提としています。各 xttdriver.pl コマンドを、表領域グループごとに --restore オプションを指定して実行します。
このステップでは、Oracle XTTS ユーティリティがターゲットデータベースを再起動します。コマンドを並行して実行するには、Perl スクリプト xttdriver.pl で次のカスタマイズを使用する必要があります。
-
以下の行をコメントアウトします。
-
4867 行目 :
my $outputstart = `sqlplus -L -s \"/ as sysdba\" \@xttstartupnomount.sql`; -
4868 行目 :
checkError ("Error in executing xttstartupnomount.sql", $outputstart); -
4992 行目 :
my $outputstart = `sqlplus -L -s \"/ as sysdba\" \@xttdbopen.sql`;\
-
-
NOMOUNTステータスのターゲット DB を作成します。sqlplus / as sysdba @xttstartupnomount.sql -
増分バックアップのロールフォワードを並行して実行します。
cd /u01/oracle/expimp/xtt<nn> export TMPDIR=/u01/oracle/expimp/out/out<nn> $ORACLE_HOME/perl/bin/perl xttdriver.pl --restore --debug 3 -
すべての増分バックアップをロールフォワードしたら、
OPENステータスのターゲットDBを設定します。sqlplus / as sysdba @xttdbopen.sql
この時点で、ソースデータベースと宛先データベースの SCN が十分に近くなるまで、フェーズ 2 を繰り返すことができます。特定のターゲットのダウンタイムに応じて、フェーズ 3 に進むか、フェーズ 2 を繰り返すかを決定する必要があります。
フェーズ 3 (転送フェーズ) のダウンタイムを削減するために、USER、PACKAGE、PROCEDURE、および FUNCTIONといった非セグメントベースのオブジェクトのメタデータをエクスポートおよびインポートすることができます。ソースデータベースを READ ONLY に設定する前に行ってください。
ソースデータベース内のデータベースオブジェクトの数が非常に多い場合 (数十万)、メタデータのエクスポートとインポートには数時間かかります。この場合は、メタデータをエクスポートすることを検討します。
非セグメントベースのオブジェクトのエクスポートは、ソースシステム上で読み取り/書き込みで実行されます。次に、ソースシステムが READ ONLY に設定される前に、オブジェクトを宛先システムにインポートする必要があります。このとき、PACKAGE、PROCEDURE、および FUNCTION といったデータベースのソースオブジェクトを変更しないようにします。
これは、USER、PACKAGE_SPEC、PACKAGE_BODY、PROCEDURE、および FUNCTION など、非セグメントベースのオブジェクトのメタデータをエクスポートするために使用されるダンプパラメータファイルの例です。
directory=dmpdir dumpfile=xttsmsc%U.dmp full=y filesize=1048576000 logfile=expmsc.log metrics=y exclude=TABLE,INDEX,CONSTRAINT,COMMENT, MATERIALIZED_VIEW,MATERIALIZED_VIEW_LOG,SCHEMA_CALLOUT
メタデータをエクスポートするには、以下のコマンドを使用します。
SQL> create directory dmpdir as <location>; expdp system/<system password> parfile=<parameter file>
これは、非セグメントのオブジェクトのメタデータをインポートするための ダンプパラメータファイルの例です。
directory=dmpdir dumpfile=xttsmsc%U.dmp full=y logfile=impmsc1.log EXCLUDE=TABLESPACE, PROCOBJ, RLS_CONTEXT, RLS_GROUP, RLS_POLICY, TABLESPACE_QUOTA metrics=y remap_tablespace= APPS_TS_ARCHIVE:SYSTEM, APPS_TS_INTERFACE:SYSTEM, APPS_TS_SEED:SYSTEM, APPS_TS_SUMMARY:SYSTEM, …..
このとき、宛先システムには、SYSTEM、SYSAUX、UNDO および TEMP 以外の表領域は存在しません。したがって、インポートするすべてのオブジェクトを SYSTEM 表領域に再マップする必要があります。
メタデータをインポートするには、以下のコマンドを使用します。
SQL> create directory dmpdir as <location>; impdp system/<system password> parfile=<parameter file>
これで、作成されたオブジェクトが宛先データベースに表示されます。
SQL> select object_type, count(*) from dba_objects group by object_type order by count(*) desc; OBJECT_TYPE COUNT(*) ------------------------------- ---------- SYNONYM 89327 PACKAGE 55670 PACKAGE BODY 54447 VIEW 41378 JAVA CLASS 31978 SEQUENCE 12766 …..
SYSTEM、SYSAUX、UNDO、および TEMP 以外の表領域はありません。USER オブジェクトは、USERSをデフォルトの表領域として作成されます。フェーズ 3 では、転送可能な表領域が作成され、USER オブジェクトが元のデフォルト表領域で変更されます。