1. Zero Downtime Migrationを使用したOracle Cloudへの移行
  2. 論理データベース移行の準備

5 論理データベース移行の準備

次の各トピックでは、論理データベース移行ジョブを実行する前にZero Downtime Migrationの前提条件を完了する方法について説明します。

5.1 論理データベース移行のベスト・プラクティス

論理データベース移行には、次のベスト・プラクティスをお薦めします。

ソース・データベースのワークロードおよびアクティビティ

  • 移行ジョブの間は、高速なデータベース・レプリケーションに最適な環境を提供するために、データベースでデータ定義言語(DDL)操作を実行しないようにすることをお薦めします。DDLがレプリケートされると、Oracle GoldenGate Replicatによってデータがシリアライズされて、同じオブジェクト上のDMLとDDLの間にロックの問題がないことが確認されます。詳細は、「データ・レプリケーション」を参照してください。
  • パッチ適用操作とアップグレード操作は、大量のDDL操作が発生する可能性があるため、移行時にはお薦めしません。
  • 移行期間中、高速データベース・レプリケーションに最適な環境を提供するには、大規模なバッチDML操作を回避します。数百万行に影響する単一トランザクションのような大規模なバッチ操作を実行すると、レプリケーション速度が低下する可能性があります。
  • ZDMパラメータGOLDENGATESETTINGS_EXTRACT_WARNLONGTRANS_DURATIONおよびGOLDENGATESETTINGS_EXTRACT_WARNLONGTRANS_CHECKINTERVALを指定して、長時間実行トランザクションに対するGoldenGate Extract警告を生成できます。
  • ZDMにより、GoldenGate ReplicatのパラメータSPLIT_TRANS_RECSが設定されます。

ソース・データベース構成

ソース表の一意性

  • Oracle GoldenGateでは、レプリケートされた更新および削除に対して正しいターゲット行を見つけるために、ソース表とターゲット表に一意の行識別子が必要です。

    これは通常、主キー索引または一意キー索引で考慮されます。このようなキーを持たない表が識別された場合、GoldenGateでは、表内の使用可能なすべての列(仮想列、UDT、ファンクションベースの列、拡張(32K) VARCHAR2/NVARCHAR2列およびOracle GoldenGateユーザーによってOracle GoldenGate構成から明示的に除外された列を除く)が含まれる疑似キーを作成する必要があります。

    ただし、すべての列からキーを作成すると、Oracle GoldenGateのパフォーマンスが大幅に低下します。

    ソース・データベースのバージョンがOracle Database 12g (12.2)以降の場合、データ・ディクショナリ・ビューDBA_GOLDENGATE_NOT_UNIQUEを使用して、主キーまたはNULL以外の一意の列がない表をすべての識別します。

  • 詳細は、「ソース表とターゲット表での行の一意性の保証」を参照してください。

MAX_STRING_SIZE

  • ソース・データベースがMAX_STRING_SIZE=STANDARDで構成されている場合は、ターゲット・データベースに対してMAX_STRING_SIZE=STANDARDを設定します。
  • 詳細は、「MAX_STRING_SIZE」を参照してください。

ソース・データベース・サーバーのCPUおよびメモリー要件

ソース・システムに十分な空きCPUリソースがある場合は、ZDM構成パラメータを設定します

GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE = HIGH。それ以外の場合は、ZDM構成パラメータGOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE = LOW-RESを設定します

GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE = HIGH

ソース・システムのリソース使用率:
  • OCPU: 最大3 (6 vCPU)
  • RAM: 3 GB (SGAストリーム・プール)

GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE = LOW

ソース・システムのリソース使用率:

  • OCPU: 最大2 (4 vCPU)
  • RAM: 16.8MB (SGAストリーム・プール)

ターゲット・データベース・サーバーのCPUおよびメモリー要件

ZDMパラメータGOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILEを使用して、Oracle GoldenGate Replicatをチューニングします。パフォーマンス・プロファイルを設定すると、目的のスループットおよびレイテンシが実現するように関連パラメータが自動的に構成されます。ZDMは、HIGHにデフォルト設定されます。

GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE = HIGH

Replicatアプライヤ = 2 * ターゲット・データベースのCPU_COUNT

GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE = LOW

Replicatアプライヤ = ターゲット・データベースのCPU_COUNT / 2

Oracle GoldenGateサーバーのCPU要件

GoldenGateサーバーのOCPU = ceil(((#replicat_appliers1 / 2) + #vCPU_extract2 + #vCPU_OS3) / 2)

1#replicat_appliers: ZDMパラメータGOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILEを使用して構成されたGoldenGate Replicatアプライヤの数

2#vCPU_extract: ZDMパラメータに基づきます

GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE

3#vCPU_OS: オペレーティング・システムのリソース管理に使用されます(2 vCPUに設定)

次に例を示します:

次の場合:

  • GOLDENGATESETTINGS_EXTRACT_PERFORMANCEPROFILE= HIGH
  • GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILE = HIGH
  • ターゲットDB CPU_COUNT = 5

#vCPU_extract = 6

#replicat_appliers = 10

#vCPU_OS = 2

次のようになります。

GGサーバーのOCPU = ceil(6.5) = 7

詳細は、『Oracle Zero Downtime Migration – 論理的移行パフォーマンスのガイドライン』を参照してください。

Oracle GoldenGateサーバーの証跡ファイル格納領域要件

必要な領域は、証跡の選択したサイズ、レプリケーションのために取得されるデータの量および利用した証跡がディスクに保持される期間に応じて異なります。証跡に割り当てられる推奨の最小ディスクは、次のように計算します:

((トランザクション・ログのサイズ * 0.33) * 1日当たりのログ・スイッチの数) * 証跡を保持する日数

たとえば、トランザクション・ログのサイズが1GBであり、1日当たり平均10個のログ・スイッチがある場合、Oracle GoldenGateは、1日当たり3.3GBのデータを取得することがわかります。証跡を7日間保持できるようにする場合、証跡を保持するために必要なディスク領域の最小容量は23GBになります。詳細は、「ディスク領域のその他の考慮事項」を参照してください。

ADB以外のソース・データベースおよびターゲット・データベースのGGADMINユーザー

ソース・データベースにGoldenGate管理ユーザーggadminを作成し、例に示されている権限をすべて付与します。ソース・データベースがマルチテナント(CDB)の場合は、この例に示すように、ソースPDBにユーザーを作成します。 

SQL> create user ggadmin identified by password
defaulttablespace users temporary tablespace temp;
SQL> grant connect, resource to ggadmin;
SQL> alter user ggadmin quota 100M ON USERS;
SQL> grant unlimited tablespace to ggadmin;
SQL> grant select any dictionary to ggadmin;
SQL> grant select any table to ggadmin;
SQL> grant create view to ggadmin;
SQL> grant execute on dbms_lock to ggadmin;
SQL> exec dbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('ggadmin');

ソース・データベースがマルチテナント(CDB)の場合は、この例に示すように、CDB$ROOTにユーザーc##ggadminも作成します: 

SQL> create user c##ggadmin identified by password defaulttablespace userstemporary tablespace temp;
SQL> alter user c##ggadmin quota 100M ON USERS;
SQL> grant unlimited tablespace to c##ggadmin;
SQL> grant connect, resource to c##ggadmin container=all;
SQL> grant select any dictionary to c##ggadmin container=all;
SQL> grant select any table to ggadmin;
SQL> grant create view to c##ggadmin container=all;SQL> grant set container to c##ggadmin container=all;
SQL> grant execute on dbms_lock to c##ggadmin container=all;
SQL> execdbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('c##ggadmin',container=>'all');
SQL> create user c##ggadmin identified by password

ターゲット・データベースがAutonomous Databaseでない場合は、ターゲット・データベースにGoldenGate管理ユーザーggadminを作成し、例に示されている権限をすべて付与します。ターゲット・データベースがマルチテナント(CDB)の場合は、この例に示すように、ターゲットPDBにユーザーを作成します。 

SQL> create user ggadmin identified by password default tablespace users
temporary tablespace temp;
SQL> grant connect, resource to ggadmin;
SQL> alter user ggadmin quota 100M ON USERS;
SQL> grant unlimited tablespace to ggadmin;
SQL> grant select any dictionary to ggadmin;
SQL> grant create view to ggadmin;
SQL> grant select any table to ggadmin;
SQL> grant insert any table to ggadmin;
SQL> grant update any table to ggadmin;
SQL> grant delete any table to ggadmin;
SQL> grant comment any table to ggadmin;
SQL> grant execute on dbms_lock to ggadmin;
SQL> exec dbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('ggadmin');

ネットワーク接続要件

アプリケーション・スイッチオーバー

論理移行でのアプリケーション・スイッチオーバーの処理

5.2 論理移行のソース・データベースの前提条件

移行ジョブの間は、高速なデータベース・レプリケーションに最適な環境を提供するために、データベースでデータ定義言語(DDL)操作を実行しないようにすることをお薦めします。DDLがレプリケートされると、Oracle GoldenGate Replicatによってデータがシリアライズされて、同じオブジェクト上のDMLとDDLの間にロックの問題がないことが確認されます。

論理移行の準備をするには、ソース・データベースで次の前提条件を完了します。

オフラインおよびオンライン移行には次が必要です。

  • ソース・データベースの文字セットは、ターゲット・データベースと同じである必要があります。

  • 初期化パラメータSTREAMS_POOL_SIZEを使用してストリーム・プールを構成します。

    オフライン論理移行の場合、データ・ポンプのパフォーマンスを最適化するには、初期プールを割り当てるためにSTREAMS_POOL_SIZEを256MB-350MB以上に設定することをお薦めします。そうしないと、起動時にかなりの遅延が発生する可能性があります。

    オンライン論理移行の場合は、STREAMS_POOL_SIZEを2 GB以上に設定します。統合Extractと追加の25パーセントごとに1 GBのSTREAMS_POOL_SIZEの推奨事項については、https://support.oracle.com/epmos/faces/DocumentDisplay?id=2078459.1を参照してください。

  • Zero Downtime Migrationサービス・ホストおよびソース・データベース・サーバーのシステム時間は、Oracle Cloud Infrastructureターゲットと同期している必要があります。

    これらのいずれかのシステムの時間がOCIの時間から6分を超えて異なる場合は、調整する必要があります。NTPが構成されている場合は、ntp time checkを使用して時刻を同期できます。NTPが構成されていない場合は、構成することをお薦めします。NTPを構成するオプションがない場合は、時間を手動で修正して、OCI時間と同期するようにする必要があります。

  • データベース・リンクを使用しており、ターゲット・データベースがAutonomous Database共有インフラストラクチャ上にある場合は、ソースでTCPSを構成する必要があります。Autonomous Database共有インフラストラクチャでは、TCPSで構成されていないソースへのデータベース・リンクは許可されません。

  • Amazon Web Services RDS環境から移行する場合、ソース環境の準備の詳細は、Amazon Web Services RDSからOracle Autonomous Databaseへの移行を参照してください。

  • エクスポートされるPDBで、C##ユーザーのスキーマにローカル・オブジェクトが作成されて、それらをインポートする場合は、同じ名前の共通ユーザーがすでにターゲットCDBインスタンスに存在することを確認するか(Autonomous Database以外のターゲットの場合)、次のZero Downtime Migrationパラメータを使用して、インポート時にスキーマの名前を変更します。

    DATAPUMPSETTINGS_METADATAREMAPS-1=type:REMAP_SCHEMA,oldValue:c##common_user,newValue:new_ name

  • 既存のExadata Cloud@Customerシステムを含め、任意のオンプレミスのOracle DatabaseからOracle Autonomous Database on Exadata Cloud@Customerに移行する場合、追加の前提条件設定タスクについて、Oracle Autonomous Database on Exadata Cloud@Customerへの移行を参照してください。

  • Zero Downtime Migrationサービス・ホストでは、インストール・スクリプトを実行するためにPerlが必要です。

    Oracle Database 11.2.0.4ソースから移行する場合は、最新のPerlパッチ5.28.2以降も必要です。または、Zero Downtime MigrationでCPATをリモートで起動するには、ソース・データベース・ホストのPerlにパッチを適用しないように、RUNCPATREMOTELYパラメータをTRUEに設定します。

オンライン移行には次が必要です。

  • ソースがOracle Database 11.2の場合、必須の11.2.0.4 RDBMSパッチをソース・データベースに適用します。

    My Oracle SupportノートOracle GoldenGate -- Oracle RDBMS Server Recommended Patches (ドキュメントID 1557031.1)を参照してください

    • データベースPSU 11.2.0.4.210720には、Oracle GoldenGateパフォーマンス・バグ28849751 - IE PERFORMANCE DEGRADES WHEN NETWORK LATENCY BETWEEN EXTRACT AND CAPTURE IS MORE THAN 8MSの修正が含まれています

    • OGG RDBMSパッチ32248879 MERGE REQUEST ON TOP OF DATABASE PSU 11.2.0.4.201020 FOR BUGS 32048478 20448066 - このパッチには、Oracle GoldenGate Microservicesの不具合20448066 DBMS_XSTREAM_GG APIS SHOULD FOR SCA PROCESSESに対する必須の修正が含まれています

  • ソースがOracle Database 12.1.0.2以降のリリースの場合は、ソース・データベースに必須RDBMSパッチを適用します。
  • ソースがOracle Database 18cまたはOracle Database 19cで使用可能なOracle Database Standard Edition 2で、DBRU 19.11より前の場合は、バグ29374604 - Integrated Extract not starting against Oracle RDBMS Standard Editionに対するRDBMSパッチを適用します。

    Oracle Database 12c以降の最新のDBBP/RUに必要な追加RDBMSパッチがリストされている、My Oracle Supportノートの最新のGoldenGate/Database (OGG/RDBMS)パッチ推奨(ドキュメントID 2193391.1)を参照してください。

  • データベースのARCHIVELOGモードを有効にします。データベースのアーカイブ・モードの変更を参照してください。

  • FORCE LOGGINGを有効にして、Oracle GoldenGate ExtractプロセスによってREDOですべての変更が検出されるようにします。FORCE LOGGINGモードの指定を参照してください

  • データベースの最小サプリメンタル・ロギングを有効にします。最小サプリメンタル・ロギングを参照してください。 

    SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

  • 初期化パラメータENABLE_GOLDENGATE_REPLICATIONを有効にします。

  • 統合Extractのパフォーマンス分析のためにUTL_SPADVまたはUTL_RPADVパッケージをインストールします。

    ソース・データベース・バージョン19c以降(UTL_SPADVを参照)

    操作上のノート: このパッケージを使用するには、Oracle Replication管理者(たとえば、ggadmin)としてOracleデータベースに接続し、ORACLE_HOME内のrdbms/adminディレクトリでutlrpadv.sqlスクリプトを実行する必要があります。

    以前のデータベース・バージョン(UTL_SPADVの操作上のノートを参照)

    操作上のノート: このパッケージを使用するには、Oracle Replication管理者(たとえば、ggadmin)としてOracleデータベースに接続し、ORACLE_HOME内のrdbms/adminディレクトリでutlspadv.sqlスクリプトを実行する必要があります。

  • 移行期間中、高速データベース・レプリケーションに最適な環境を提供するには、大規模なバッチDML操作を回避します。数百万行に影響する単一トランザクションのような大規模なバッチ操作を実行すると、レプリケーション速度が低下する可能性があります。DDLの作成、変更および削除操作はレプリケートされません。

  • WALLET_SOURCEADMINを設定して、ソース・データベース管理者パスワードを提示する自動ログイン・ウォレット・ファイルcwallet.ssoが格納されているディレクトリへのパスを指定します。「WALLET_SOURCEADMIN」を参照してください。

    ノート:

    MIGRATION_METHOD= ONLINE_LOGICALの場合は、DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREEパラメータを使用してエクスポートの並列性を1に構成します。

オフライン移行には次が必要です。

  • DATAPUMP_EXP_FULL_DATABASEおよびDATAPUMP_IMP_FULL_DATABASEロールが必要です。これらのロールは、移行ジョブを構成するプロセスに特権アプリケーション・ロールを割り当てる必要があるかどうかを決定するために、データ・ポンプに必要です。

    DATAPUMP_EXP_FULL_DATABASEは、指定されたデータベース・ユーザーのソース・データベースでのエクスポート操作に必要です。DATAPUMP_IMP_FULL_DATABASEロールは、指定されたターゲット・データベース・ユーザーの指定されたターゲット・データベースでのインポート操作に必要です。

    詳細は、Oracle Data Pumpのドキュメントを参照してください。

ソース・データベースがIBM AIXの場合の前提条件:
  1. OSSがデータ転送メディアとして使用されている場合、CURLが使用可能であることを確認してください。
  2. idコマンドが使用可能であることを確認します。詳細は、idコマンドを参照してください。

5.3 論理移行のターゲット・データベースの前提条件

論理移行の準備をするには、ソース・データベースで次の前提条件を完了します。

データ・ポンプのみの論理移行には、次が必要です。

  • DATAPUMP_IMP_FULL_DATABASEロールは、指定されたターゲット・データベース・ユーザーの指定されたターゲット・データベースでのインポート操作に必要です。

すべての論理移行には、次が必要です。

  • ソース・データベースの文字セットは、ターゲット・データベースと同じである必要があります。

  • Zero Downtime Migrationサービス・ホストおよびソース・データベース・サーバーのシステム時間は、Oracle Cloud Infrastructureターゲットと同期している必要があります。

  • すべてのソース・データベース要件が満たされています。一部のタスクは、ソースとターゲットの両方で実行されます。論理移行のソース・データベースの前提条件を参照してください

ノート:

論理移行の場合、ターゲットがOracle Database Applianceで、データ転送メディアがObject Storage Service (OSS)である場合は、OSS接続が機能することを確認します。OCIのCA証明書をフェッチし、Oracle Database Applianceの証明書ストアを更新します。詳細は、「Oracle Identity Cloud ServiceからのルートCA証明書の取得」を参照してください。

オンライン論理移行には、次が必要です:

  • インスタンス化の直後にターゲット・データベースで自動パージ・ジョブを無効にします(Data Pump Import)。そうしないと、パージ・ジョブによってターゲット・データベースでデータの不整合状態が発生し、GoldenGate Replicatが失敗します。これらのジョブの一部はデータをパージします。
    • ZDM_POST_DATAPUMP_TGTフェーズでは、ZDMによってターゲット・データベースのパージ・ジョブが無効になります。
    • ZDM_POST_SWITCHOVER_TGTフェーズでは、ZDMによってターゲット・データベースのパージ・ジョブが有効になります。

5.4 追加の論理移行の前提条件

論理移行の準備をするには、次の追加の前提条件を完了します。

OCI APIキー・ペアを作成します

詳細は、必要なキーとOCIDを参照してください。

AWS S3セキュリティ資格証明の構成

Amazon Web Services RDS環境から移行する場合、ソース環境の準備の詳細は、Amazon Web Services RDSからOracle Autonomous Databaseへの移行を参照してください。

データ転送メディアの設定

  • Object Storageデータ転送メディアを使用するには:

    Object Storageをデータ転送メディアとして使用している場合は、Oracle Cloud Infrastructureでオブジェクト・ストア・バケットを作成します。これは、Oracle Exadata Database Service on Cloud@CustomerまたはオンプレミスExadata Database Machineターゲットには不要です。

  • NFS共有ストレージを使用するには:

    NFSがソース・データベース・サーバーとターゲット・データベース・サーバーとで共有されており、データベース・ディレクトリ・オブジェクトにマップされていることを確認します。

    ダンプ・ストレージ用にNFSをマウントする方法については、NASデバイス上でNFSと使用する場合のRACデータベースおよびクラスタウェアのOracleファイルのマウント・オプション(ドキュメントID 359515.1)を参照してください。

  • データベース・リンク(DBLINK)を使用するには:

    ソース・データベースのglobal_nameによって、ターゲット・データベースとオンプレミス・ソース・データベースの間の既存のデータベース・リンクを使用している場合は、そのデータベース・リンクが壊れていないことを確認します。Zero Downtime Migrationでは、データ転送メディアが構成されている場合、既存のデータベース・リンクを移行に再利用できます。

    Zero Downtime Migrationでは、すべてのAutonomous Databaseターゲットに対するデータベース・リンクの使用がサポートされています。ただし、Autonomous Database専用インフラストラクチャに対するデータベース・リンクを設定する場合は、Easy Connect構文を使用するか、USING '接続文字列'句で完全な記述子を指定する必要があります。tnsnames.oraファイルは参照に使用できないため、ネットワーク・サービス名を使用できません。TCPS接続にはウォレットが必要であるため、データベース・リンクはTCP接続にのみ使用できます。

    Autonomous Databaseでの制限付きSQLコマンドおよびAutonomous DatabaseからOracle Databasesへのデータベース・リンクの作成を参照してください

  • データ転送にデータベース・リンクを使用しない場合は、データ・ポンプ・エクスポート・ディレクトリに使用するファイル・システムに、データ・ポンプ・ダンプ・ファイルを格納するのに十分な領域があることを確認してください。

  • Amazon S3バケットを使用するには:

    S3バケット・データ転送メディアの設定を参照してください

ソースが自己署名データベース・サーバー証明書を使用する場合:

ソース・データベース・リスナーが自己署名付きデータベース・サーバー証明書を使用してTLS (TCPS)で構成されている場合、自己署名付き証明書がZero Downtime Migrationホーム証明書ストアに次のように追加されていることを確認します。

keytool -import -keystore ZDM_HOME/jdk/jre/lib/security/cacerts -trustcacerts
-alias "src ca cert" -file source_db_server-certificate

オンライン移行の追加の前提条件

オンライン移行の場合、次の追加の前提条件タスクを実行します。

  • Oracle GoldenGate Microservicesハブを設定します。

    Oracle Database Cloud Servicesターゲットの場合は、Oracle Cloud Marketplaceから「Oracle GoldenGate for Oracle - Database Migrations」イメージをデプロイします。

    Oracle GoldenGate Marketplaceイメージの「データベース移行」バージョンには、OCI Database Migration Serviceで使用する限定の無料ライセンスが用意されています。詳細は、ライセンス契約を参照してください。

    その他のGoldenGateを使用するには、Oracle GoldenGate製品のライセンスを購入する必要があります。詳細は、Oracle GoldenGateのドキュメントを参照してください。

    1. Oracle Cloud Marketplaceにログインします。
    2. 「Oracle GoldenGate for Oracle - Database Migrations」マーケットプレイス・リストを検索します。
    3. マーケットプレイスの検索結果から、「Oracle GoldenGate for Oracle - Database Migrationations」リストを選択します。
    4. マーケットプレイス・リストをデプロイする手順は、Oracle Cloud Marketplace上でのOracle GoldenGate Microservicesのデプロイを参照してください。

    Zero Downtime MigrationのGoldenGate設定の構成、および正しいGoldenGateハブ・シェイプの選択に関するガイダンスは、Oracle MAAの技術概要Oracle Zero Downtime Migration - 論理移行パフォーマンスのガイドラインを参照してください。

    Exadata Cloud@CustomerまたはオンプレミスのOracle Exadata Database Machineに移行する場合、オンプレミスのOracle GoldenGate Microservicesインスタンスを使用して、ソースとターゲットのデプロイメントを作成する必要があります。マーケットプレイスで提供されているOracle GoldenGate for Oracle – Database Migrationsに、Exadata Cloud at Customer用のダウンロード可能なdockerイメージが含まれるようになりました。最新のマーケットプレイスVMはhttps://cloudmarketplace.oracle.com/marketplace/en_US/listing/96175416で確認できます。この機能のドキュメントは、Oracle Zero Downtime Migrationの使用によるExadata Cloud@Customerへの移行 にあります。

    デフォルトでは、Oracle GoldenGateデプロイメントのエンドポイントは自己署名HTTPS証明書を使用して構成されます。次のいずれかのオプションが使用可能です:
    • ZDMが自己署名HTTPS証明書を信頼できることを示すように、レスポンス・ファイルでGOLDENGATEHUB_ALLOWSELFSIGNEDCERTIFICATEパラメータをTRUEに指定します。
    • 信頼できる認証局によって発行された証明書を使用するように、Oracle GoldenGateデプロイメントの構成を更新します。

  • GoldenGate管理ユーザーを作成します:

    次に示す例は基本的な移行用です。Oracle GoldenGateの包括的な権限の詳細は、『Oracle DatabaseでのOracle GoldenGateの使用』の適切なユーザー権限の付与に関する項を参照してください。

    • ソース・データベースの場合:

      • 例にリストされているすべての権限を付与して、GoldenGate管理ユーザーggadminを作成します。ソース・データベースがマルチテナント(CDB)の場合は、この例に示すように、ソースPDBにユーザーを作成します。 

        SQL> create user ggadmin identified by password
 default tablespace users temporary tablespace temp;
SQL> grant connect, resource to ggadmin;
SQL> alter user ggadmin quota 100M ON USERS;
SQL> grant unlimited tablespace to ggadmin;
SQL> grant select any dictionary to ggadmin;
SQL> grant create view to ggadmin;
SQL> grant execute on dbms_lock to ggadmin;
SQL> exec dbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('ggadmin');

      • ソース・データベースがマルチテナント(CDB)の場合は、この例に示すように、CDB$ROOTにユーザーc##ggadminも作成します。 

        SQL> create user c##ggadmin identified by password default tablespace users
temporary tablespace temp;
SQL> alter user c##ggadmin quota 100M ON USERS;
SQL> grant unlimited tablespace to c##ggadmin;
SQL> grant connect, resource to c##ggadmin container=all;
SQL> grant select any dictionary to c##ggadmin container=all;
SQL> grant create view to c##ggadmin container=all;
SQL> grant set container to c##ggadmin container=all;
SQL> grant execute on dbms_lock to c##ggadmin container=all;
SQL> exec
dbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('c##ggadmin',container=>'all');

    • ターゲット・データベースの場合:

      • ターゲットがAutonomous Databaseの場合は、事前作成されたggadminユーザーのロックを解除します。

      • ターゲットがAutonomous Databaseでない場合は、前述の例に示すように、ターゲットPDBにggadminユーザーを作成します。このユーザーは、ソース・データベースのggadminユーザーに似ています。次の権限を追加で付与します: 

        
SQL> grant select any table to ggadmin;
SQL> grant insert any table to ggadmin;
SQL> grant update any table to ggadmin;
SQL> grant delete any table to ggadmin;

        Replicatのすべてのモード・ユーザーに必要な権限の詳細は、Oracle GoldenGate資格証明の確立 を参照してください。

  • ソース・データベースがSSL/TLSを使用するように構成されている場合:

    ソース・データベースがSSL/TLSを使用するように構成されている場合は、TLS認証用の証明書を含むウォレットがGoldenGateインスタンスのディレクトリ/u02/deployments/deployment_name/etcにあることを確認します。

  • ソース・データベースまたはターゲット・データベースでOracle Database Vaultが有効になっている場合:

    ソース・データベースまたはターゲット・データベースのOracle Database Vault環境でOracle GoldenGateを使用する場合は、Oracle GoldenGateアカウントに対して適切な権限が付与されている必要があります。

    詳細は、『Oracle Database VaultでOracle GoldenGateを使用するための権限』を参照してください。

  • ターゲット・データベースがSSL/TLSを使用するように構成されている場合:

    TLS認証用の証明書を含むウォレットが、次のようにGoldenGateインスタンスの正しい場所に配置されていることを確認します。

    • Autonomous Databaseの場合、ウォレット・ファイルはディレクトリ/u02/deployments/deployment_name/etc/adbにある必要があります

    • 共同管理データベースの場合、ウォレット・ファイルはディレクトリ/u02/deployments/deployment_name/etcにある必要があります

    Autonomous Databaseは常にTLSを使用するように構成されます。

5.4.1 Oracle GoldenGate Hubの追加接続の前提条件

Oracle GoldenGateを使用してオンライン論理移行を実行するには、Zero Downtime Migrationサービス・ホストとソースおよびターゲット・データベース・サーバー間の接続に加えて、Oracle GoldenGateハブとソースおよびターゲット・データベース・サーバー間の接続も確保する必要があります。

OCIネットワーク・セキュリティ・ルールで次の接続が許可されていることを確認します

表5-1 オンライン論理移行の前提条件接続

イニシエータ ターゲット プロトコル ポート 用途
GoldenGateハブ ソース・データベース TCP

TCPS

 1521

ユーザー定義

 SQL*Net
GoldenGateハブ ターゲット・データベース TCP

TCPS

 1521

ADB (サーバーレス)の場合は1522、ADB (専用)の場合はポート2484、ADB以外の場合はユーザー定義

 SQL*Net
ZDMサーバー GoldenGateハブ HTTPS 443 Oracle GoldenGate Microservice REST APIのコール

Zero Downtime Migrationサーバーは、OCI RESTエンドポイントへのポート443を介したHTTPSコールを実行できる必要があります。

5.4.2 Oracle GoldenGate Marketplaceインスタンスとの間の接続の検証

  1. Zero Downtime MigrationサーバーからOracle GoldenGateサーバーへ。

    Zero Downtime Migrationサーバーで、次を実行します。

    curl -v --insecure -u oggadmin_username https://ogg_instance_fqdn_or_ip/services/v2/deployments

    Oracle GoldenGateサーバーの資格証明は、GoldenGateサーバー上の/home/opc/ogg-credentials.jsonにあります。

  2. Oracle GoldenGateサーバーからソース・データベース・サーバーへ。

    ソース・データベース・リスナーがTLS/SSLに対応していない場合は、Oracle GoldenGateサーバーで、次を実行します。

    export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'source_listener_hostname_or_ip:source_listener_port/source_db_service_name'

  3. Oracle GoldenGateサーバーからターゲット・データベース・サーバーへ

    ターゲット・データベースがAutonomous Databaseの場合は、「追加の論理移行の前提条件」で「オンライン移行の追加の前提条件」を参照し、TLS認証の証明書を含むAutonomous DatabaseウォレットがOracle GoldenGateインスタンス上の正しい場所に存在することを確認します。

    Oracle GoldenGateサーバーで、次を実行します。

    export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'tcps://abd_listener_hostname_or_ip:adb_listener_port/adb_service_name?wallet_location=dir_path&ssl_server_cert_dn=cert_dn'

    SQL*Plusの使用によるAutonomous Databaseへの接続の詳細は、TLS認証によるSQL*Plusの接続を参照してください。

    ターゲット・データベースがAutonomous Databaseではなく、TLS/SSLに対応していない場合は、Oracle GoldenGateサーバーで、次を実行します。

    export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'target_listener_hostname_or_ip:target_listener_port/target_db_service_name'

5.5 論理移行パラメータの設定

必要な論理移行レスポンス・ファイル・パラメータを設定します。データベース移行プロシージャのZero Downtime Migrationレスポンス・ファイルの作成に使用するレスポンス・ファイル・テンプレート$ZDM_HOME/rhp/zdm/template/zdm_logical_template.rspを取得し、ここで説明するようにファイルを編集します。

論理移行レスポンス・ファイルの設定の詳細は、Zero Downtime Migration論理移行レスポンス・ファイル・パラメータ・リファレンスを参照してください。

オフラインまたはオンラインの論理移行には、次のパラメータが必要です。

  • MIGRATION_METHOD: GoldenGateを使用したオンライン移行の場合はONLINE_LOGICAL、オフライン・データ・ポンプ転送の場合はOFFLINE_LOGICALに設定します。

  • DATA_TRANSFER_MEDIUM: 設定先

    Object Storageバケットの場合はOSS

    共有ネットワーク・ファイル・システムの場合はNFS

    データベース・リンクを使用した直接転送の場合はDBLINK

    セキュア・コピーを使用するにはCOPY

    Amazon S3バケットを使用する場合はAMAZONS3 (AWS RDS Oracleソースからの移行にのみ適用されます。Amazon Web Services RDS OracleからOracle Cloudへの移行を参照してください)

    データ・ポンプ・ダンプの処理にデフォルトのデータ転送サーバーを使用している場合を除き、ソースおよびターゲット・データベース環境のデータ転送ノード設定も構成する必要があります。

    詳細は、転送メディアの構成および転送ノードの指定を参照してください。

  • Oracle Database 11gソースから11gターゲットへの論理移行の場合、DATAPUMPSETTINGS_SECUREFILELOB=FALSEを設定すると、エラーが発生することがあります。

  • 次のターゲット・データベース・パラメータを設定します。

    • TARGETDATABASE_OCIDは、Oracle Cloudリソース識別子を指定します。

      たとえば: ocid1.instance.oc1.phx.abuw4ljrlsfiqw6vzzxb43vyypt4pkodawglp3wqxjqofakrwvou52gb6s5a

      https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/identifiers.htmも参照してください

    • TARGETDATABASE_ADMINUSERNAMEでは、データベース管理者のユーザー名を指定します。たとえば、共同管理データベースの移行ユーザー名がsystemで、Autonomous Databaseの移行ユーザー名がadminの場合です。

    • TARGETDATABASE_CONNECTIONDETAILS_SERVICENAMEは、完全修飾サービス名を指定します。

      このパラメータは、Autonomous Databaseターゲットの場合はオプションですが、接続にHTTPプロキシが必要な場合は指定します。

      また、小数OCPUサービスが使用されているOracle Autonomous Database on Dedicated Exadata InfrastructureおよびOracle Autonomous Database on Exadata Cloud@Customerの場合は、パラメータにTLSサービスの適切な別名を指定する必要があります。

      使用可能な事前定義済の小数サービス別名を指定できます。ただし、Autonomous Transaction Processingのワークロードの場合、TP*サービスはLOW*サービスよりも優先されます。これは、LOW*が優先度の低いバッチ・ジョブ用であるためです。

      • TP_TLS、LOW_TLS (Autonomous Transaction Processingのワークロードの場合)
      • LOW_TLS (Autonomous Data Warehouseのワークロードの場合)
  • 次のソース・データベース・パラメータを設定します。

    • SOURCEDATABASE_ADMINUSERNAMEでは、データベース管理者のユーザー名を指定します。たとえば、ユーザー名はsystemです。

    • SOURCEDATABASE_CONNECTIONDETAILS_HOSTは、リスナーのホスト名またはIPアドレスを指定します。Oracle RACの場合、SCAN名を指定できます。(Autonomous Databaseでは不要)

    • SOURCEDATABASE_CONNECTIONDETAILS_PORTは、リスナーのポート番号を指定します。(Autonomous Databaseでは不要)

    • SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAMEは、完全修飾サービス名を指定します。(Autonomous Databaseでは不要)

      たとえば: service_name.DB_domain

      https://docs.cloud.oracle.com/en-us/iaas/Content/Database/Tasks/connectingDB.htmも参照してください

    • AWS RDSソースからの移行については、追加のパラメータ設定について、Amazon Web Services RDSからOracle Autonomous Databaseへの移行を参照してください。

  • 次のOCIAUTHENTICATIONDETAILSパラメータを設定します。

    必要な設定の詳細は、https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/apisigningkey.htm#RequiredKeysandOCIDsを参照してください

    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTIDは、OCIテナンシのOCIDを指定します。この値は、コンソールの「Governance and Administration」→「Administration」→「Tenancy Details」にあります。テナンシOCIDが「Tenancy Information」の下に表示されます。

      たとえば: ocid1.tenancy.oc1..aaaaaaaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdsq

      https://docs.cloud.oracle.com/en-us/iaas/Content/Identity/Tasks/managingtenancy.htmも参照してください

    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERIDは、IAMユーザーのOCIDを指定します。この値は、コンソールの「Profile」→「User Settings」にあります。

      https://docs.oracle.com/en-us/iaas/Content/Identity/Tasks/managingusers.htmも参照してください

    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINTは、API公開キーのフィンガープリントを指定します。

    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_PRIVATEKEYFILEは、API秘密キー・ファイルの絶対パスを指定します。

    • OCIAUTHENTICATIONDETAILS_REGIONIDは、OCIリージョン識別子を指定します。

      https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/regions.htmにある表の「Region Identifier」列を参照してください

Oracle GoldenGateの設定

移行ジョブの間は、高速なデータベース・レプリケーションに最適な環境を提供するために、データベースでデータ定義言語(DDL)操作を実行しないようにすることをお薦めします。DDLがレプリケートされると、Oracle GoldenGate Replicatによってデータがシリアライズされて、同じオブジェクト上のDMLとDDLの間にロックの問題がないことが確認されます。

オンライン論理移行の場合は、前述のパラメータに加えて、GoldenGateパラメータTARGETDATABASE_GGADMINUSERNAME、SOURCEDATABASE_GGADMINUSERNAME、SOURCECONTAINERDATABASE_GGADMINUSERNAME、および接頭辞GOLDENGATEHUBとGOLDENGATESETTINGSが付いたパラメータも設定する必要があります。

デフォルトでは、Zero Downtime Migrationで、すべてのDDLがGoldenGateレプリケーションから除外されます。ただし、パラメータGOLDENGATESETTINGS_REPLICATEDDL=trueを設定することで、この動作をオーバーライドできます。

デフォルトでは、ZDMにより、Oracle GoldenGate ExtractおよびReplicatでは予期しない障害に対するレジリエンシについて自動開始が有効になっています。

これらのパラメータの詳細は、Zero Downtime Migration論理移行レスポンス・ファイル・パラメータのリファレンスを参照してください。

Oracle GoldenGate Replicatの構成を簡略化するには、GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILEを設定します。このパラメータは、次に示す4つの別個のGOLDENGATESETTINGS_REPLICAT_*パラメータを構成する必要性に取ってかわるものです。

Oracle Zero Downtime Migration 21c (21.4)リリース以降、次のパラメータは非推奨であり、今後のリリースでサポートされなくなります:
  • GOLDENGATESETTINGS_REPLICAT_MAPPARALLELISM
  • GOLDENGATESETTINGS_REPLICAT_APPLYPARALLELISM
  • GOLDENGATESETTINGS_REPLICAT_MAXAPPLYPARALLELISM
  • GOLDENGATESETTINGS_REPLICAT_MINAPPLYPARALLELISM
GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILEパラメータを構成する場合、非推奨のパラメータを構成する必要はありません。ただし、これらの非推奨のパラメータを構成すると、GOLDENGATESETTINGS_REPLICAT_PERFORMANCEPROFILEパラメータは無効になります。

Oracle Data Pump設定

Zero Downtime Migrationでは、パフォーマンスを向上させ、データ・セキュリティを確保するために、データ・ポンプ・パラメータの最適なデフォルトが自動的に設定されます。パフォーマンスをさらにチューニングする必要がある場合は、レスポンス・ファイルで構成できるいくつかのデータ・ポンプ設定があります。

DATAPUMPSETTINGS_EXPORTVERSIONパラメータを設定すると、Data Pumpジョブ・エクスポート・バージョンを指定できます。ZDMにより、ソースおよびターゲット・バージョンに基づいてバージョン・パラメータはすでに設定されています。このバージョン・パラメータを12に設定する必要があるのは、11.2.0.4にアップグレードされ、ワーク・スペース・マネージャが有効になっているレガシー・データベースの場合のみです。次の値を選択できます:
  • COMPATIBLE
  • 12
  • LATEST

Autonomous Databaseへの移行には、デフォルトのDATAPUMPSETTINGS_JOBMODE=SCHEMAをお薦めします。

デフォルトのデータ・ポンプ・プロパティ設定、含めるまたは除外するスキーマまたはオブジェクトの選択方法、およびデータ・ポンプのエラー処理の詳細は、Zero Downtime Migrationのデフォルトのデータ・ポンプ・パラメータ設定を参照してください。

Zero Downtime Migrationで設定できるすべてのData Pumpパラメータについては、「Zero Downtime Migration論理移行レスポンス・ファイル・パラメータのリファレンス」を参照してください。

AWS RDSから移行するためのデータ・ポンプ・パラメータの設定の詳細は、Amazon Web Services RDSからOracle Autonomous Databaseへの移行を参照してください。

5.6 転送メディアの構成および転送ノードの指定

Zero Downtime Migrationには、ターゲット・データベース・サーバーでOracle Data Pumpダンプを使用できるようにするための様々な転送オプションが用意されています。

DATA_TRANSFER_MEDIUMレスポンス・ファイル・パラメータを使用して、次のデータ転送方法を構成できます。

  • OSS: Oracle Cloud Object Storage

    すべての移行タイプおよびターゲットでサポートされます。

  • NFS: ネットワーク・ファイル・システム

    共同管理ターゲットおよびユーザー管理ターゲットの場合はサポートされています。

  • DBLINK: データベース・リンクを介したソースからターゲットへの直接データ転送

    すべての移行タイプおよびターゲットでサポートされます。

  • COPY: セキュア・コピーを使用してダンプをターゲット転送ノードに転送します。

    共同管理ターゲットおよびユーザー管理ターゲットの場合はサポートされています。

  • AMAZON3: Amazon S3バケット
  • AWS RDS Oracleソースからの移行にのみ適用されます。詳細は、Amazon Web Services RDS OracleからOracle Cloudへの移行を参照してください。

ノート:

並列性を利用して最適なデータ転送パフォーマンスを実現するために、Oracleでは、サイズが50 GBを超えるデータベースにOSSまたはNFSを使用してデータを転送することをお薦めします。DBLINK転送メディアは、小規模なデータベースには便利ですが、転送中のネットワーク帯域幅に依存するため、パフォーマンスが不確実になる可能性があります。

ソースでのダンプのエクスポートが完了すると、ダンプはパラメータDUMPTRANSFERDETAILS_PARALLELCOUNTで定義されているとおりにパラレルにアップロードまたは転送され(デフォルトは3)、転送の失敗はパラメータDUMPTRANSFERDETAILS_RETRYCOUNTで指定されているとおりにデフォルトで再試行されます(デフォルトは3)。

特定のノードからダンプにアクセスできる場合は、ソース・データ・センターの任意のノードからダンプを転送できます。実行するデータ転送アプローチを決定するには、ネットワーク接続およびソース・データベース・サーバーへの転送ワークロードの影響を確認することが重要です。

ソースからターゲットへの直接転送

このオプションは、共通管理クラウド・ターゲット・データベースにのみ適用されます。

Zero Downtime Migrationでは、ソースからターゲットへのデータ・ポンプ・ダンプの安全な直接転送を使用した論理移行が可能です。データは、セキュア・コピーまたはRSYNCを使用して、ソース・データベースのディレクトリ・オブジェクト・パスからターゲット・データベース・サーバーのディレクトリ・オブジェクト・パスまたはターゲット転送ノードにコピーされます。これにより、WAN経由でデータが転送されたり、ソース環境とターゲット環境の間で追加の共有記憶域が必要になることを回避できます。この機能により、データ・センター内の論理移行が大幅に簡略化されます。

転送ノードについて

転送ノードと呼ばれるノードを、ソース・データ・センターとターゲット・テナンシの両方に構成します。

接頭辞がDUMPTRANSFERDETAILS_SOURCE_TRANSFERNODEのレスポンス・ファイル・パラメータは、ソース・データ・センターでエクスポート・ダンプを処理するノードを指定します。このソース転送ノードのデフォルトは、ソース・データベースです。

同様に、接頭辞がDUMPTRANSFERDETAILS_TARGET_TRANSFERNODEのレスポンス・ファイル・パラメータは、ターゲットでダンプのインポートを処理するノードを指定します。このターゲット転送ノードのデフォルトは、共同管理ターゲットのターゲット・データベースです。

転送ノードの要件

ソース転送ノードは次のいずれかになります。

  • ソース・データベース・サーバー(デフォルト)
  • NAS搭載サーバー
  • Zero Downtime Migrationサービス・ノード

ターゲット転送ノードは次のいずれかになります。

  • ターゲット・データベース・サーバー(デフォルト)
  • NAS搭載サーバー
  • Zero Downtime Migrationサービス・ノード

サーバーを転送ノードとして指定するには、次の重要な考慮事項が必要です。

  • アップロードまたは転送ワークロードを処理するためのCPUおよびメモリーの可用性

  • 指定されたアップロードまたは転送ターゲットへの接続

    • 選択したデータ転送メディアがOSSの場合はObject Storageサービスへのポート443接続

    • 選択した転送メディアがCOPYの場合はターゲット・ストレージ・サーバーへのポート22接続

  • Oracle Cloud Infrastructure CLIの可用性。ダンプのより高速で回復可能なアップロードのために、これはOSS転送メディアに推奨される転送ユーティリティです。

  • OCI CLIは、https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htmの説明に従ってインストールおよび構成する必要があります。

    各ソース・データベース・サーバーでのOCI CLIのインストールおよび構成は、実行できない場合があります。このような場合、データ・センター内のいずれかのノードをOCI CLIが構成された転送ノードとして指定でき、このノードはデータ・ポンプ・ダンプを作成するためにデータベース・サーバーとネットワーク記憶域パスを共有できます。これにより、本番データベース・サーバーで追加のCPUおよびメモリーを消費するアップロード・ワークロードも回避されます。

指定された転送ノードは、データ転送トラフィックを許可する外部データ転送のデータ・センターでゲートウェイ・サーバーとして機能できるため、ソース・データベース・サーバーから、またはターゲット・データベース・サーバーへのデータ転送を許可する必要がありません。

Zero Downtime Migrationサービスがオンプレミス・データ・センターに配置され、前述の転送ノード要件を満たすことができる場合は、必要に応じて、Zero Downtime Migrationサーバーを転送ノードとして利用することで、追加の転送ノード要件を回避できます。

転送ノードおよびデータベース・サーバーがストレージを共有してダンプをステージングする場合は、転送ノードのユーザーおよびデータベース・ユーザーが、両方のノードで読み取られるダンプ・ファイルの共通のプライマリ・グループを共有するようにします。

ノート:

dbuserプラグインは共通グループを共有します。

Oracle Cloud Object Storage転送メディアの使用

Object Storageデータ転送メディアは、すべての移行タイプおよびターゲットでサポートされています。

DATA_TRANSFER_MEDIUM=OSSを設定してObject Storageをデータ転送メディアとして使用する場合は、より高速かつ安全で回復可能なアップロードのために、OCI CLIを使用してダンプをアップロードすることをお薦めします。アップロード・ノードでOCI CLIを構成し、パラメータDUMPTRANSFERDETAILS_SOURCE_USEOCICLIをTRUEに設定する必要があります。OCI CLIのパラメータは次のとおりです

DUMPTRANSFERDETAILS_SOURCE_USEOCICLI

DUMPTRANSFERDETAILS_SOURCE_OCIHOME

Oracle Cloud Object Storageベースの移行の場合は、Data Pump Dumpステージング用に指定されたオブジェクト・ストレージ・バケットの事前認証済URLを作成する権限がクラウド・アクセス・ユーザーに付与されていることを確認します。詳細は、「事前認証済リクエストの使用」を参照してください。

データベース・リンク転送メディアの使用

すべての移行ターゲットへのオンラインおよびオフライン移行でサポートされています

DATA_TRANSFER_MEDIUM=DBLINKを設定すると、指定したソース・データベースのglobal_nameを使用して、OCIの共同管理データベースまたはAutonomous Databaseターゲットからソース・データベースへのデータベース・リンクが作成されます。

Zero Downtime Migrationでは、データベース・リンクが存在しない場合は作成され、データ・ポンプ・インポート・フェーズが完了するとリンクがクリーン・アップされます。

NFS転送メディアの使用

NFS転送モードは、ダンプの転送を回避する共通管理ターゲット・データベースに対してDATA_TRANSFER_MEDIUM=NFSを設定することで使用できます。指定したパスがソースとターゲットのデータベース・サーバー・パス間でアクセス可能であることを確認する必要があります。

Zero Downtime Migrationでは、ソースおよびターゲットのデータベース・ユーザーのみがダンプへのアクセスを許可されるように、ダンプに対する制限された権限を保持することで、共有記憶域内のダンプのセキュリティが確保されます。

NASデバイス上でNFSと使用する場合のRACデータベースおよびクラスタウェアのOracleファイルのマウント・オプション(ドキュメントID 359515.1)を参照してください。

コピー転送メディアの使用

共同管理ターゲット・データベースへのオフライン移行でのみサポートされます。

DATA_TRANSFER_MEDIUM=COPYを設定することで、ダンプをソースからターゲットに安全に転送できます。関連するパラメータは次のとおりです。

DUMPTRANSFERDETAILS_TRANSFERTARGET_USER

DUMPTRANSFERDETAILS_TRANSFERTARGET_USERKEY

DUMPTRANSFERDETAILS_TRANSFERTARGET_HOST

DUMPTRANSFERDETAILS_TRANSFERTARGET_SUDOPATH

DUMPTRANSFERDETAILS_TRANSFERTARGET_DUMPDIRPATH

SCPのかわりにRSYNCユーティリティを利用できます。DUMPTRANSFERDETAILS_RSYNCAVAILABLEをTRUEに設定し、ソースとターゲットの両方の転送ノードでRSYNCが使用可能であることを確認します。

5.7 移行するオブジェクトの選択

Zero Downtime Migrationでは、レスポンス・ファイル内のパラメータを使用して、論理移行ジョブに含めるオブジェクトまたは含めないオブジェクトを指定できます。

EXLCUDEOBJECTS-n、RELOADOBJECTS-nおよびINCLUDEOBJECTS-nレスポンス・ファイル・パラメータを使用して、移行ジョブに含めるオブジェクト、除外するオブジェクトまたはリロードするオブジェクトのルールを指定します。移行にオブジェクトを含めるか含めないかのどちらかが可能であり、両方はできません。

ルールが定義されていない場合は、初期ロード時の移行内容で示されている内容を除き、ソース・データベースのすべてのスキーマおよびオブジェクトが移行されます。

包含ルールを指定した場合、移行では、指定したオブジェクトとその依存オブジェクトのみが移動され、他のすべてのオブジェクトは自動的に除外されます。デフォルトでは、含まれているスキーマに関連付けられたUSERおよびTABLESPACE_QUOTAオブジェクト・タイプが含まれます。

除外ルールを指定した場合、指定されたオブジェクトとその依存オブジェクトはOracle Data Pumpを使用して移行されず、Oracle GoldenGateを使用してレプリケートされません。

リロード・ルールを指定した場合、指定したオブジェクトはOracle GoldenGateを使用してレプリケートされません。かわりに、ソース・データベースにアクティブなワークロードがない場合、フェーズZDM_RELOAD_PARALLEL_EXPORT_IMPORTでOracle Data Pumpを使用して、指定されたオブジェクトがターゲット・データベースに移行されます。

次の例に示すように、パラメータ名に追加する整数を大きくすることで、複数の包含ルール、除外ルールまたはリロード・ルールを定義できます。

単一の包含ルールの例:

INCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1

2つの除外ルールの例:

EXCLUDEOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1

EXCLUDEOBJECTS-2=owner:ownerValue2, objectName:objectNameValue2, objectType:objectTypeValue2

2つのリロード・ルールの例:

RELOADOBJECTS-1=owner:ownerValue1, objectName:objectNameValue1, objectType:objectTypeValue1

RELOADOBJECTS-2=owner:ownerValue2, objectName:objectNameValue2, objectType:objectTypeValue2

必須パラメータ・フィールド

INCLUDEOBJECTS-n、EXLCUDEOBJECTS-nおよびRELOADOBJECTS-nレスポンス・ファイル・パラメータを指定するには、次の各フィールドの値を入力します:

  • ownerには、選択したデータベース・オブジェクトの所有者を指定します。包含ルールを使用する場合、すべてのルールでownerが同じである必要があり、ワイルド文字は使用できません。

  • objectNameには、選択したデータベース・オブジェクトの名前を指定します

  • objectTypeには、選択したデータベース・オブジェクトのタイプを指定します。ALLを選択すると、すべてのタイプのオブジェクトを選択できます(デフォルト)。

JavaクラスPattern内の任意の有効なパターンを使用して、ownerフィールドとobjectNameフィールドをフィルタできます。たとえば、objectNameフィールドに.*と入力すると、すべての名前のオブジェクトを選択できます。

制限事項

次の制限事項に注意する必要があります:

  • 指定したスキーマ内のオブジェクトを除外したときに、それと同じ名前のオブジェクトが、その移行に含まれている別のスキーマにも存在する場合、そのオブジェクトは除外されません(つまり、そのルールは無視されます)。この除外は、そのスキーマを別の移行に含めるようにすれば実現できます。

  • FULLジョブ・モードで包含ルールを作成する場合は、スキーマレベルのルール(objectNameが.*で、objectTypeがALL)のみを使用できます。

  • 包含ルールでobjectNameが.*である場合、それと同じobjectTypeで他のルールを作成することはできません。そのルールでobjectTypeがALLである場合は、どのタイプでも他のルールを作成できません。

  • objectTypeをALLにすることは、スキーマレベルのルール(objectNameが.*)でのみ可能です。

  • ownerが指定されているスキーマレベルのルール(objectNameが.*で、ownerが.*以外のパターン)では、objectTypeをTABLEにすることはできません。

  • オブジェクトレベルのルール(objectNameは.*以外の任意のパターン)は、オブジェクト・タイプがDIRECTORY、FUNCTION、JOB、MATERIALIZED_VIEW、PACKAGE、PROCEDURE、TRIGGER、SEQUENCE、TABLE、ROLE、PROFILE (ジョブ・モードFULLに制限)、PROCOBJに対してのみ使用できます。

    他のすべてのオブジェクト・タイプは、objectNameで.*というパターンを使用して含めるか除外する必要があり、除外する場合はさらにownerが.*である必要があります。

  • ワイルドカード式の使用はRELOADOBJECTSパラメータに許可されていません。
  • RELOADOBJECTSパラメータは、オンライン論理移行でのみサポートされています。

オブジェクトレベルのフィルタリングでサポートされているオブジェクト・タイプ

objectNameは選択することも.*にすることもできる

DIRECTORY

FUNCTION

JOB

MATERIALIZED_VIEW

PACKAGE

PROCEDURE

TRIGGER

SEQUENCE

TABLE

ROLE

PROFILE (ジョブ・モードFULLに制限)

PROCOBJ

一般的なobjectTypeレベルの除外または包含でサポートされているオブジェクト・タイプ

(objectNameが.*である必要がある)

CLUSTER

DB_LINK

GRANT

OBJECT_GRANT

SYSTEM_GRANT

ROLE_GRANT

PROCOBJ_GRANT

PROCDEPOBJ_GRANT

INDEX

INDEXTYPE

MATERIALIZED_VIEW_LOG

MATERIALIZED_ZONEMAP

POST_TABLE_ACTION

PROCOBJ

PROFILE

REF_CONSTRAINT

RLS_POLICY

SYNONYM

TABLESPACE

TABLESPACE_QUOTA

USER

XMLSCHEMA

VIEW

AUDIT_TRAILS

ON_USER_GRANT

その他のオブジェクト・タイプのフィルタリング

COMMENTやFGA_POLICYなど、上でリストされていない他のオブジェクト・タイプをフィルタするには、DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELISTパラメータを使用します。

例

例5-1 スキーマMySchemaのすべてのオブジェクトを含める

INCLUDEOBJECTS-1=owner:MySchema, objectName:.*, objectType:ALL

owner objectName objectType
MySchema .* ALL

例5-2 スキーマMySchemaの、PRODで始まるすべての表、およびプロシージャMYPROCを含め、すべての依存オブジェクトを含める

INCLUDEOBJECTS-1=owner:MySchema, objectName:PROD.*, objectType:TABLE

INCLUDEOBJECTS-2=owner:MySchema, objectName:MYPROC, objectType:PROCEDURE

owner objectName objectType
MySchema PROD.* TABLE
MySchema MYPROC PROCEDURE

例5-3 名前がExperimentalで始まるスキーマ、表MySchema.OldTable (すべての依存オブジェクトも除外)、およびタイプがDB_LINKのすべてのオブジェクトを除外する

なお、OldTableという表が別のスキーマ(これも移行される)に存在する場合は、MySchema.OldTableは除外されません。

EXCLUDEOBJECTS-1=owner:Experimental.*, objectName:.*, objectType:ALL

EXCLUDEOBJECTS-2=owner:MySchema, objectName:OldTable, objectType:TABLE

EXCLUDEOBJECTS-3=owner:.*, objectName:.*, objectType:DB_LINK

owner objectName objectType
Experimental.* .* ALL
MySchema OldTable TABLE
.* .* DB_LINK

特殊文字を使用した含めるオブジェクトと除外するオブジェクトの指定

次の例は、EXCLUDEOBJECTSおよびINCLUDEOBJECTSパラメータで特殊文字を使用するオブジェクト名を指定する方法を示しています。

  • 特殊文字をエスケープするには、文字列内の特殊文字の前のすべての文字の前後に2つのスラッシュ(//)を使用します。

    たとえば、ドル記号($)をエスケープするには:

    \\INLUDEOBJECTS-3= owner:GRAF_MULTI\\$_HR

  • 接頭辞と接尾辞パターンの間にあるすべての文字を照合するには、照合の必要な場所にピリオドとアスタリスク(.*)を追加します。

    たとえば、GRAFで始まりHRで終わるすべてのスキーマを除外するには:

    EXCLUDEOBJECTS-3= owner:GRAF.*HR

5.7.1 様々なOracle GoldenGateサポート・モードでのオブジェクトの移行

様々なOracle GoldenGateサポート・モードでオブジェクトを移行できます。

ノート:

Zero Downtime Migrationでは、TABLEオブジェクトに対してのみOracle GoldenGateレプリケーションが設定されます。

ノート:

Oracle GoldenGateでは、UPDATE句を指定しないとマテリアライズド・ビューをレプリケートできません。また、マテリアライズド・ビューとソース表は同時にレプリケートできません。したがって、オンライン論理移行ジョブの場合、ZDMは、次の条件を満たすマテリアライズド・ビューをソース・データベースのdba_mviewsに問い合せます:
  • UPDATABLE = 'N' OR MASTER_LINK = NULL

    または

  • MASTER_LINK = <global_name>
ZDMは、前述の問合せを使用して識別されたマテリアライズド・ビューごとに、マテリアライズド・ビューがレプリケートされないようにGoldenGate ExtractのTABLEEXCLUDEパラメータを設定します。

support_mode = INTERNALを使用した表の移行

Zero Downtime Migrationでは、support_mode = INTERNALの表が検出され、通知されます。

ノート:

Zero Downtime Migration 21.3ユーザーは、パッチ33509650: ZDM PATCH USING MOSを適用してこの機能を使用する必要があります。

DMLレプリケーション: Oracle GoldenGateでは、support_mode = INTERNALの表に対するDMLが自動的に無視されます。Zero Downtime Migrationでは、support_mode = INTERNALの表に対してGoldenGate ExtractパラメータTABLEEXCLUDEは設定されません。

Oracle GoldenGateでは、グローバル一時表のDMLレプリケーションは除外されます。

DDLレプリケーション: パラメータGOLDENGATESETTINGS_REPLICATEDDL = TRUEを設定すると、Zero Downtime MigrationによってOracle GodenGate ExtractパラメータDDLOPTIONS CAPTUREGLOBALTEMPTABLEが設定されます。

support_mode = ID KEYを使用した表の移行

通常の操作で、Zero Downtime Migrationではエラーがレポートされ、Oracle GoldenGate support_mode = ID KEYのユーザー表がすべてリストされます。

ノート:

Zero Downtime Migration 21.3ユーザーは、パッチ33509650: ZDM PATCH USING MOSを適用してこの機能を使用する必要があります。

パラメータGOLDENGATESETTINGS_USEFLASHBACKQUERY = TRUEを設定すると、Zero Downtime Migrationにより、ID KEYサポート・モード・オブジェクトをレプリケートできる次のOracle GoldenGate Extractパラメータが設定されます。

  • STATOPTIONS REPORTFETCH

  • FETCHOPTIONS USESNAPSHOT, NOUSELATESTVERSION, MISSINGROW REPORT

Oracle GoldenGateでフラッシュバック問合せを使用できるように、ソース・データベースに十分なUNDOサイズがあることを確認してください。最適なフェッチ結果を得るには、『Oracle DatabaseでのOracle GoldenGateの使用』のフラッシュバック問合せの設定に関する項に記載されているようにソース・データベースを構成します。

support_mode = NONEおよびsupport_mode = PLSQLを使用した表の移行

ZDM_VALIDATE_SRCフェーズではビューDBA_GOLDENGATE_SUPPORT_MODEを問い合せ、support_mode = NONEおよびsupport_mode = PLSQLを含む表のリストをレポートします。

このようなオブジェクトを移行するには、次のZDMパラメータを設定します:

  • GOLDENGATESETTINGS_RELOADUNREPLICATEDOBJECTS
  • RELOADOBJECTS-LIST_ELEMENT_NUMBER

関連トピック

5.8 METADATAの移行

この機能を使用して段階的な移行を実行できます。

ZDMワークフローでMETADATAおよびDATAを別個のフェーズとして移行すると、次の利点があります:
  • ワークフローは、通常のエクスポートと、次が含まれるデータ前メタデータ・インポートを伴う段階的なインポートを実行します:
    • ユーザーおよびプロファイルの作成
    • METADATAの作成
    • DATAインポート
  • これは、ワークフローのカスタマイズをワークフローに挿入する場合に役立ちます。

DATAの前にMETADATAをインポートするには、DATAPUMPSETTINGS_METADATAFIRSTパラメータの値をTRUEに設定します。

関連トピック

5.9 拡張データ・ポンプ・パラメータの設定

Zero Downtime Migrationでは、パフォーマンスを向上させ、データのセキュリティを確保するために、Oracle Data Pumpのパラメータに最適なデフォルトが自動的に設定されます。パフォーマンスをさらに調整するためや、エクスポート・モードを変更するためや、データベース・オブジェクトの名前を変更するための、移行レスポンス・ファイル内で構成できるデータ・ポンプ設定がいくつかあります。

これらのパラメータは、レスポンス・ファイル($ZDM_HOME/rhp/zdm/template/zdm_logical_template.rsp)で設定されます。

5.9.1 Zero Downtime Migrationのデフォルトのデータ・ポンプ・パラメータ設定

次の表に、Zero Downtime Migrationによって設定されるデータ・ポンプ・パラメータと、その設定値を示します。デフォルトのオーバーライドに使用できるZero Downtime Migrationレスポンス・ファイル・パラメータがある場合は、「オーバーライドするZero Downtime Migrationレスポンス・ファイルのオプション・パラメータ」列にリストされます。オーバーライド・パラメータは、レスポンス・ファイル($ZDM_HOME/rhp/zdm/template/zdm_logical_template.rsp)で設定されます。

表5-2 データ・ポンプ・パラメータのデフォルト

データ・ポンプ・パラメータ デフォルト値 オーバーライドするZDMレスポンス・ファイルのオプション・パラメータ

EXCLUDE

cluster (ADB-D, ADB-S)

indextype (ADW-S)

db_link (ADB)

statistics (ユーザー管理ターゲットおよびADB)

追加のEXCLUDEエントリを指定できます詳細は、「EXCLUDEOBJECTS-LIST_ELEMENT_NUMBER」を参照してください。

ノート

EXCLUDEに無効なオブジェクト・タイプを指定すると、データ・ポンプ・エクスポート・エラーが発生します。DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELISTパラメータに有効なオブジェクト・タイプが指定されていることを確認します。

有効なオブジェクト・タイプのリストを表示するには、次のビューを問い合せます: DATABASE_EXPORT_OBJECTS (FULLモードの場合)、SCHEMA_EXPORT_OBJECTS (SCHEMAモードの場合)、TABLE_EXPORT_OBJECTS (TABLEおよびTABLESPACEモードの場合)。OBJECT_PATH列にリストされる値が有効なオブジェクト・タイプです。

たとえば、レスポンス・ファイルに無効なオブジェクト・タイプ・パラメータを指定すると、エクスポート・エラーが発生します。

ORA-39038: オブジェクト・パス"<specified invalid>"はSCHEMAジョブにサポートされていません。

PARALLEL

ZDMはデフォルトでPARALLELパラメータを次のように設定します

ユーザー管理DBの場合:- (ノード当たり2 x (物理CPUの数)の合計)で、最大32個の上限があります。

ADBの場合:- OCPUの数

DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE

DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE

CLUSTER

ZDMは常にクラスタ・モードをデフォルトとして設定します

DATAPUMPSETTINGS_DATAPUMPPARAMETERS_NOCLUSTER

COMPRESSION

COMPRESSION_ALGORITHMはBASIC (11.2の場合)およびMEDIUM (12.1以上の場合)に設定されます

COMPRESSIONはALLに設定されます

N/A

ENCRYPTION

ENCRYPTIONはALLに設定されます

ENCRYPTION_ALGORITHMはAES128に設定されます

ENCRYPTION_MODEはPASSWORDに設定されます

N/A

FILESIZE

FILESIZEは5Gに設定されます

N/A

FLASHBACK_SCN

OFFLINE_LOGICAL ZDMの場合、FLASHBACK_TIMEが現在のシステム時間に設定されます。

ONLINE LOGICAL ZDMの場合、FLASHBACK_SCNもFLASHBACK_TIMEも使用されません

N/A

REUSE_DUMPFILES

常にYESに設定されます

N/A

TRANSFORM

19c以上のターゲットの場合、常にOMIT_ENCRYPTION_CLAUSE:Yが設定されます

常にLOB_STORAGE:SECUREFILEが設定されます

ADBターゲットの場合、次の変換がデフォルトで設定されます

SEGMENT_ATTRIBUTES:N

DWCS_CVT_IOTS:Y

CONSTRAINT_USE_DEFAULT_INDEX:Y

追加のTRANSFORMを指定できます

METRICS

常にYesに設定されます

N/A

LOGTIME

常にALLに設定されます

N/A

TRACE

常に1FF0b00に設定されます

N/A

LOGFILE

常にデータ・ポンプ・ジョブ名に設定され、指定されたエクスポートまたはインポート・ディレクトリ・オブジェクトの下に作成されます。

データ・ポンプ・ジョブがZDM_2_DP_EXPORT_8417で、使用されるディレクトリ・オブジェクトがDATA_PUMP_DIRの場合、操作ログはZDM_2_DP_EXPORT_8417.logという名前でDATA_PUMP_DIRの下に作成されます。

N/A

5.9.2 表領域の自動作成

論理移行の場合、Zero Downtime Migrationでは、移行されるユーザー・スキーマに関連付けられたソース・データベース表領域が自動検出され、データ・ポンプ・インポート・フェーズの前に自動的にターゲット・データベースにそれらが作成されます。

ノート:

デフォルトでは、すべての表領域が自動的に作成されます。表領域を自動的に作成しない場合は、TABLESPACEDETAILS_EXCLUDEパラメータを使用して、ターゲット・データベースで自動作成から除外する表領域を指定します。
Zero Downtime Migrationは、表領域を事前作成するために必要なDDLを生成し、ターゲット上に表領域を作成し、生成されたDDLを実行します。

表領域の自動作成は、ADB(専用)ターゲットおよびADB以外のターゲットの場合はデフォルトで有効になります。自動作成が有効になっていると、Zero Downtime Migrationは、レスポンス・ファイルのREMAPセクションで指定されている表領域、またはターゲット・データベースにすでに存在するすべての表領域の自動作成をスキップします。

Zero Downtime Migrationは、指定されたターゲットで表領域の作成がサポートされるかどうかを検証します。共同管理データベース・システムに制限はありません。ターゲットがAutonomous Databaseシステムである場合、次の制限が適用されます。

  • Autonomous DatabaseシステムはBIGFILE表領域のみをサポートするため、Zero Downtime MigrationはAutonomous DatabaseターゲットにデフォルトでBIGFILE表領域を適用し、SMALLFILE表領域が見つかった場合はエラーを報告します。かわりに任意のSMALLFILE表領域を再マップできます。

  • Autonomous Database Sharedシステムは、表領域の自動作成をサポートしていません。DATAへの表領域自動REMAPは、デフォルトで適用されます。

次のレスポンス・ファイル・パラメータを使用して、ターゲット・データベースで必要な表領域を自動的に作成します。

  • TABLESPACEDETAILS_AUTOCREATEは、表領域の自動作成のためにデフォルトで有効になります。

    なお、TABLESPACEDETAILS_AUTOCREATEをFALSEに設定すると、表領域自動再マッピング(TABLESPACEDETAILS_AUTOREMAP)がデフォルトで適用されます。AUTOCREATEとAUTOREMAPが両方ともFALSEに設定されている場合は、何も適用されません。

  • TABLESPACEDETAILS_USEBIGFILEを使用すると、SMALLFILE表領域をBIGFILE表領域に変換できます。通常は、デフォルトではFALSEに設定され、Autonomous Databaseターゲットの場合はZero Downtime Migrationによって強制的にTRUEになります。

  • TABLESPACEDETAILS_EXTENDSIZEMBを使用すると、表領域でAUTOEXTENDが有効になって拡張エラーを回避でき、デフォルトのNEXT EXTENDサイズが512MBになります。

  • TABLESPACEDETAILS_EXCLUDEは、ユーザー・スキーマのインポート時にターゲット・データベースで自動作成から除外する表領域を指定します。デフォルトで、'SYSTEM'、'SYSAUX'、'USERS'表領域は除外されます。

ノート:

現在の使用量が100M未満である場合は、初期サイズとして、デフォルトのサイズである100Mが設定されます。表領域の現在の使用量が100Mより多い場合、初期サイズとして、現在の実際のサイズが設定されます。AUTOEXTENDを使用すると、上限がなくなります。

SMALLFILEの場合、incrementby句が0 (ゼロ)だと、デフォルト値である1が適用されてAUTOEXTEND ON NEXTサイズが決定されます。

5.9.3 表領域の自動再マップ

論理移行の場合、Zero Downtime Migrationでは、ソース・データベースの表領域をターゲット・データベースの指定した表領域に自動的に再マップできます。

Zero Downtime Migrationでは、移行に必要なソース・データベース表領域が自動的に検出されます。自動再マップが有効になっている場合、Zero Downtime Migrationは、次の条件を満たす表領域を除外することによって、再マッピングが必要なソース表領域を検出します。

  • DATAPUMPSETTINGS_METADATAREMAPSで再マップに指定

  • TABLESPACEDETAILS_EXCLUDEで除外に指定

  • ターゲット・データベースにすでに存在する同じ名前の表領域

次のレスポンス・ファイル・パラメータを使用して、必要な表領域を自動的に再マップします。

  • TABLESPACEDETAILS_AUTOREMAPは、表領域の自動再マップを有効にします。

  • TABLESPACEDETAILS_REMAPTARGETは、ソース・データベースの表領域の再マップ先となるターゲット・データベースの表領域の名前を指定します。デフォルト値はDATAです。

ノート:

Zero Downtime Migrationでは、ADB (サーバーレス)ターゲットの場合は、デフォルトでAUTOREMAPがTRUEに設定されます。これをオーバーライドするには、TABLESPACEDETAILS_AUTOREMAP=FALSEを設定します。

表領域の再マップの検証

コマンドZDMCLI migrate databaseを評価モード(-eval)で実行し、再マップに必要なすべての表領域がリストされていることを確認します。欠落している表領域がある場合は、DATAPUMPSETTINGS_METADATAREMAPSパラメータを使用して再マップします。

ノート:

表領域をREMAPターゲットとして使用するには、インポート操作を実行するユーザー(たとえば、SYSTEM)は、選択した表領域にある程度のクォータを持っている必要があります。

パフォーマンスに関する考慮事項

表領域の再マッピングには、データ・ポンプ全体のインポート時間に追加される運用上のオーバーヘッドが伴います。パフォーマンスを最適化するには、ソース・データベースから不要な表領域を確認して削除して、再マップされた表領域の数を最小限に抑えます。詳細は、What DataPump And Oracle RDBMS Parameters And Features Can Significantly Affect DataPump Performance ? (Doc ID 1611373.1)のREMAP_*セクションを参照してください。

5.9.4 メタデータの再マップ

DATAPUMPSETTINGS_METADATAREMAPS*パラメータを使用すると、移行ジョブの間にデータベース・オブジェクトの名前を変更できます。名前を変更するオブジェクトをtypeで指定し、oldValueとnewValueを入力します。

たとえば:

DATAPUMPSETTINGS_METADATAREMAPS-1=type:REMAP_TABLESPACE,oldValue:TS_DATA_X,newValue:DATA

DATAPUMPSETTINGS_METADATAREMAPS-2=type:REMAP_TABLESPACE,oldValue:DBS,newValue:DATA

サポートされているオブジェクト・タイプは、REMAP_DATAFILE、REMAP_SCHEMA、REMAP_TABLEおよびREMAP_TABLESPACEです。

表領域への個々のユーザーのクォータ付与は再マップされないため、表領域DATAに対するこれらの付与を手動で作成する必要があります。

Autonomous Database共有インフラストラクチャ・ターゲットに移行する場合は、すべての表領域が自動的にDATAにマップされます。これをオーバーライドするには、レスポンス・ファイル内で別のターゲットに表領域を明示的にマッピングします。

詳細は、METADATA_REMAPプロシージャを参照してください。

5.9.5 データ・ポンプのエラー処理

Zero Downtime Migrationでは一部のエラーが無視されます。データ・ポンプ・ログに表示される残りのエラーを確認する必要があります。

次のデータ・ポンプ・エラーは、Zero Downtime Migrationでは無視されます。

  • ORA-31684: XXXXはすでに存在します

  • ORA-39111: 依存オブジェクト型XXXXはスキップされ、ベース・オブジェクト型です

  • ORA-39082: オブジェクト型ALTER_PROCEDURE: XXXXの作成の際、コンパイル・エラーが発生しました

根本的なデータ・ポンプ・エラーを回避するために、クラウド移行前アドバイザ・ツール(CPAT)によって報告されたすべてのエラーをクリアします。

5.10 バッチを使用した並列でのスキーマの移行

Zero Downtime Migrationでは、複数のスキーマ移行をバッチとして並列で実行できます。

並列で移行する必要があるスキーマ・バッチを指定できます。依存スキーマのグループを特定し、同じバッチの一部としてすべての依存スキーマを指定します。

移行ワークフローでは、スキーマがバッチとして処理され、指定したバッチごとに、データ・ポンプ・エクスポート、ダンプ・アップロードおよびインポートの操作が並列で実行されます。

あるバッチで発生したエラーが、他のバッチ操作に影響することはありません。

進捗モニターにより、各バッチの進行状況が識別され、進行状況が個別にレポートされ、すべてのバッチのデータ・ポンプ・インポート操作の完了時にバッチ固有のエラーがレポートされます。

Zero Downtime Migrationでは、バッチ数によるランダム・バッチ選択もサポートされています。この機能では、特定した移行対象ユーザー・スキーマが、指定したバッチ数でランダムにグループ化され、並列で移行されます。

新しい移行ジョブ・フェーズZDM_PARALLEL_EXPORT_IMPORTは、ZDM_DATAPUMP_EXPORT_SRC、ZDM_UPLOAD_DUMPS_SRCおよびZDM_DATAPUMP_IMPORT_TGTフェーズの累積です。このフェーズでは、スレッドごとに、特定されたスキーマ・サブリストに対する3つすべてのアクションが処理されます(つまり、スキーマのサブリストが並列でエクスポート、転送およびインポートされる)。

バッチ・モードを構成するには:

RSPで、DATAPUMPSETTINGS_JOBMODEパラメータをSCHEMAに設定します。

操作のバッチ・モードはデフォルトでは有効になっていません。次のRSPパラメータのいずれかを設定することでそれを有効にする必要があります。

  • DATAPUMPSETTINGS_SCHEMABATCHCOUNT=integerにより、各バッチに含めるスキーマの数を指定します。

    この場合、Zero Downtime Migrationによってバッチ(データ・ポンプ・ジョブ)当たりの一連のスキーマが保証されるわけではありません。

  • DATAPUMPSETTINGS_SCHEMABATCH-n (ここでのnは-1、-2、03に置換可能)では、並列処理のためにバッチに含めるスキーマのリストを指定できます。

なお、DATAPUMPSETTINGS_SCHEMABATCHCOUNTとDATAPUMPSETTINGS_SCHEMABATCHは相互に排他的です。

また、データベース初期化パラメータMAX_DATAPUMP_JOBS_PER_PDBによってPDBごとの同時Oracle Data Pumpジョブの最大数が決まることに注意してください。

制限事項

スキーマのバッチを指定した場合、DATAPUMPSETTINGS_JOBMODEをSCHEMA以外の値にすることはできません。

スキーマのバッチを指定した場合、INCLUDEOBJECTSを指定することはできません。

SSHのないソースでの並列移行はできません。複数のダンプを手動でアップロードするためにジョブを休止させる必要があり、これは、複数のスキーマを並列でエクスポートするという目的に反しています。

MAX_DATAPUMP_JOBS_PER_PDBにより、PDBごとの同時Oracle Data Pumpジョブの最大数が決まります。この制限を超えると、ORA-39391「データ・ポンプ・ジョブの最大数を超えています。」が発生します。

5.11 Amazon Web Services RDS OracleからOracle Cloudへの移行

Zero Downtime Migrationの論理移行方法(オンラインおよびオフライン)を使用して、Amazon Web Services (AWS) RDSからOracle Autonomous Database (ADB)、OCIユーザー管理データベースおよびOracle Exadata Database Service on Cloud@CustomerにOracle Databaseを移行できます。

5.11.1 ソース環境としてのAmazonの設定

Zero Downtime Migrationの論理移行レスポンス・ファイルで、Amazon Web ServicesからOracleデータベースを移行するために次のパラメータを設定します。

SOURCEDATABASE_ENVIRONMENT_NAME=AMAZON

SOURCEDATABASE_ENVIRONMENT_DBTYPE=RDS_ORACLE

5.11.2 安全な接続の構成

サブネットのAmazon RDSセキュリティ・ポリシーで、Zero Downtime Migrationから指定されたセキュア・ポート上のDBインスタンスへの接続が許可されていることを確認します。詳細は、AWSのドキュメントを参照してください。

VPC内のDBインスタンスにアクセスするためのシナリオ

VPCにないDBインスタンスにアクセスするためのシナリオ

エンドポイント情報の設定

  1. RDSコンソールDBインスタンスの「Connectivity & security」タブで、Amazon RDS Oracleインスタンス・エンドポイント(DNS名)とポート番号を見つけます。

    詳細は、Oracle DBインスタンスのエンドポイントの検索を参照してください。

  2. 次のZero Downtime Migration論理レスポンス・ファイル・パラメータでエンドポイントおよびポート番号情報を指定します。

    SOURCEDATABASE_ADMINUSERNAME

    SOURCEDATABASE_CONNECTIONDETAILS_HOST

    SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME

    SOURCEDATABASE_CONNECTIONDETAILS_PORT

  3. Zero Downtime Migrationサービス・ホストからAmazon RDSへの接続にプロキシが必要な場合、次の論理レスポンス・ファイル・パラメータを指定します。

    SOURCEDATABASE_CONNECTIONDETAILS_PROXYDETAILS_HOSTNAME

    SOURCEDATABASE_CONNECTIONDETAILS_PROXYDETAILS_PORT

SSL/TLSを使用したZero Downtime MigrationからAmazon RDS Oracle DBインスタンスへの接続

  1. Amazon RDS OracleインスタンスでSecure Socket Layer (SSL)またはTransport Layer Security (TLS)を有効にして、Zero Downtime MigrationからAmazon RDS Oracleインスタンスへの接続を保護します。詳細は、SSLを使用したクライアント接続の暗号化を参照してください。

  2. 新しいSSL/TLS証明書を使用するためのアプリケーションの更新に説明されているようにorapkiウォレットを作成します。

  3. Zero Downtime Migration論理レスポンス・ファイルで次のパラメータを設定します。

    SOURCEDATABASE_CONNECTIONDETAILS_TLSDETAILS_DISTINGUISHEDNAME

    SOURCEDATABASE_CONNECTIONDETAILS_TLSDETAILS_CREDENTIALSLOCATION

5.11.3 データ転送方法の構成

AWSからデータを転送するには、次のオプションがあります。

  • Amazon Simple Storage Service (Amazon S3)バケット
  • データベース・リンク(DBLINK)
5.11.3.1 データベース・リンク転送方法の設定

データベース・リンク(DBLINK)を使用してAmazon RDS Oracle DatabaseスキーマをOracle Autonomous Database (ADB)に移行するには、Amazon RDS OracleインスタンスとADBターゲット間の直接ネットワーク接続が必要です。

Zero Downtime Migration論理レスポンス・ファイルで次のパラメータを設定します。

  1. パラメータDATATRANSFERMEDIUMをDBLINKに設定します。

  2. ソース環境としてのAmazonの設定に示されているように、パラメータSOURCEDATABASE_ENVIRONMENT_*を設定します。

5.11.3.2 S3バケット・データ転送メディアの設定

Zero Downtime Migrationでは、S3バケットを使用してAmazon RDS Oracle DatabaseスキーマをOracle Autonomous Databaseターゲットに移行するために、次のステップが実行されます。

  • ダンプのエクスポート - Amazon RDS Oracle DatabaseインスタンスでDBMS_DATAPUMPプロシージャを起動して、DATA_PUMP_DIRにダンプを生成します。

  • RDSADMINを使用したS3へのダンプのアップロード - RDSインスタンスから指定したS3バケットにダンプをアップロードします。

  • S3からADBへのダンプのインポート - S3バケットからADBインスタンスにスキーマをインポートします。

データ転送にS3バケットを使用するよう環境を構成するには、次のタスクを実行します。

AWS RDS前提条件の完了

RDS OracleインスタンスはS3と統合されており、DBユーザーはRDSADMINパッケージを介してS3バケットにダンプをアップロードできるようにする必要があります。

  1. RDSとS3の統合 - RDSインスタンスとS3が統合されていることを確認します。

    まだ構成されていない場合、Oracle DatabaseインスタンスのRDSとS3の統合を有効にします。

    詳細なステップは、Amazon S3統合を参照してください。

  2. S3アクセス・キー - AWS S3アクセス・キーとアクセス・シークレットでZero Downtime Migrationを作成して提供します。

    詳細なステップは、AWSアカウントとアクセス・キーを参照してください。

  3. S3およびRDSリージョン - S3バケットとRDS Oracle Databaseインスタンスが同じリージョンにあることを確認します(たとえば、us-east-2)。

必要なレスポンス・ファイル・パラメータの設定

S3バケットを使用して移行を実行するには、次のパラメータを設定します。

  1. パラメータDATATRANSFERMEDIUMをAMAZONS3に設定します。

  2. ソース環境としてのAmazonの設定に示されているように、SOURCEDATABASE_ENVIRONMENT_*を設定します。

  3. 次の追加パラメータを設定します。

    DUMPTRANSFERDETAILS_S3BUCKET_NAME=

    DUMPTRANSFERDETAILS_S3BUCKET_REGION=

    DUMPTRANSFERDETAILS_S3BUCKET_ACCESSKEY=

    DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME=

5.12 Oracle Autonomous Database on Exadata Cloud@Customerへの移行

Zero Downtime Migrationでは、論理移行方法とデータ転送メディアとしてのNFSを使用して、既存のExadata Cloud@Customerシステムを含め、オンプレミスOracle DatabaseからOracle Autonomous Database on Exadata Cloud@Customerへの移行をサポートします。

サポートされているユース・ケース

Zero Downtime Migrationでは、次の移行シナリオがサポートされています。

  • Oracle Exadata Database Service on Cloud@Customer (Gen 1またはGen 2)ソースからOracle Autonomous Database on Exadata Cloud@Customerターゲットへ(ソース・データベースとターゲット・データベースの標準UID/GIDがOracleユーザーに対して同じである場合)

  • オンプレミスのOracle DatabaseソースからOracle Autonomous Database on Exadata Cloud@Customerターゲットへ(ソース・データベースにOracleユーザーの標準以外のUID/GIDがある場合)

移行パラメータ

必須のソースおよびターゲット接続パラメータに加えて、論理移行レスポンス・ファイルで次を設定します。

MIGRATION_METHOD=OFFLINE_LOGICALまたはONLINE_LOGICAL

DATA_TRANSFER_MEDIUM=NFS

ソースの前提条件

論理移行のソース・データベースの前提条件に記載されている通常のソース・データベースの前提条件に加えて、次の手順に説明されているようにデータ・ポンプ・ダンプ・ディレクトリへのアクセスも設定する必要があります。

Exadata Cloud@Customer環境の前提条件の設定

  1. すべてのOracle RACノード:

    [root@onprem ~]# cat /etc/fstab | grep nfsshare
nas-server.us.com:/scratch/nfsshare /u02/app/oracle/mount nfs defaults 0 0
[root@onprem ~]#

  2. Autonomous Databaseターゲットで、次のパスをマウントします

    nas-server.us.com:/scratch/nfsshare

    宛先はExadataインフラストラクチャ・リソースで、次のようになります

    specified_mount_path/CDB/PDB_GUID

    たとえば:

    /scratch/nfsshare/CDB/PDB_GUID

    NFSをマウントするオプションの詳細は、サポートにお問い合せください。

  3. ソースPDBで、次を実行します。

    SQL> create or replace directory DATA_PUMP_DIR_ADBCC as '/u02/app/oracle/mount/CDB/PDB_GUID';

Directory created.

SQL> select grantee from all_tab_privs where table_name = 'DATA_PUMP_DIR_ADBCC';

no rows selected

SQL> grant read, write on directory DATA_PUMP_DIR_ADBCC to SYSTEM;

Grant succeeded.

  4. ソースでは、マウント・ポイントの権限が必要です(drwxr-x---) 

    [oracle@onprem opc]$ ls -ldrt /u02/app/oracle/mount/CDB/PDB_GUID
drwxr-x--- 2 oracle asmadmin 4096 Jul 12 11:34 /u02/app/oracle/mount/CDB/PDB_GUID
[oracle@onprem opc]$

オンプレミス環境の前提条件の設定

  1. すべてのOracle RACノード:

    [root@onprem ~]# cat /etc/fstab | grep nfsshare
nas-server.us.com:/scratch/nfsshare /u02/app/oracle/mount nfs defaults 0 0
[root@onprem ~]#

  2. GID 1001 - miggrpを指定してグループを作成します

    root> groupadd -g 1001 miggrp

  3. データベース・ユーザーをこのグループに追加します。

    root> usermod -aG migrp oracle

  4. Autonomous Databaseターゲットで、NFS共有をマウントします(グループはrwxを取得する必要があります)

    nas-server.us.com:/scratch/nfsshare

    宛先はExadataインフラストラクチャ・リソースで、次のようになります

    specified_mount_path/CDB/PDB_GUID

    たとえば:

    /scratch/nfsshare/CDB/PDB_GUID

    NFSをマウントするオプションの詳細は、サポートにお問い合せください。

  5. ディレクトリが書込み可能であることを確認します。

    touch specified_mount_path/CDB/PDB_GUID/test.txt

  6. ソースPDBで、次を実行します。

    SQL> create or replace directory DATA_PUMP_DIR_ADBCC as '/u02/app/oracle/mount/CDB/PDB_GUID';

Directory created.

SQL> select grantee from all_tab_privs where table_name = 'DATA_PUMP_DIR_ADBCC';

no rows selected

SQL> grant read, write on directory DATA_PUMP_DIR_ADBCC to SYSTEM;

Grant succeeded.

  7. ソースでは、マウント・ポイント権限が必要であり(drwxrwx—)、グループは、作成された移行ダミー・グループと一致する必要があります。 

    [oracle@onprem opc]$ ls -ldrt /u02/app/oracle/mount/CDB/PDB_GUID
drwxrwx--- 2 1001 asmadmin 4096 Jul 12 11:34 /u02/app/oracle/mount/CDB/PDB_GUID
[oracle@onprem opc]$

オンライン論理移行を実行するための前提条件:

オンライン論理移行にdocker上のOracle GoldenGateが含まれる場合は、docker上のOracle GoldenGateでターゲットAutonomous Databaseウォレットを設定します。「追加の論理移行の前提条件」を参照してください。

ノート:

OCIエンドポイントへの接続がない場合は、TARGETDATABASE_DBTYPEパラメータでターゲット・データベース・タイプを指定し、次のパラメータをスキップします:
  • TARGETDATABASE_OCID
  • OCIAUTHENTICATIONDETAILS_*

ZDMホストに付与されたOCIアクセス権を使用しないOracle Autonomous Database on Exadata Cloud@Customer への移行:

ZDMホストに付与されたOCIアクセス権を使用せずに、オンプレミスのOracle DatabaseソースからOracle Autonomous Database on Exadata Cloud@Customerへの論理移行を実行するには、次のステップに従います:

ノート:

OCIアクセス権を使用できない場合は、OCI認証詳細(OCIAUTHENTICATIONDETAILS_*)およびターゲット・データベースOCID (TARGETDATABASE_OCID)を指定しないでください。
  • 次のパラメータを設定します:
    TARGETDATABASE_DBTYPE=ADBCC
TARGETDATABASE_ADMINUSERNAME=<User performing import. For example, admin>
TARGETDATABASE_CONNECTIONDETAILS_HOST=<<Target database access endpoint. For example, adb.us-ashburn-1.oraclecloud.com>
TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME=<ADB service alias to be used to connect. For example, HIGH or
    HIGH_TLS>
  • Oracle Autonomous Database on Exadata Cloud@Customerデータベースをアクセスする際にプロキシが必要な場合、次のようにパラメータを指定します:
    TARGETDATABASE_CONNECTIONDETAILS_PROXYDETAILS_HOSTNAME=<<Proxy to be used>>
TARGETDATABASE_CONNECTIONDETAILS_PROXYDETAILS_PORT=<Port to be used>
  • ターゲットへのアクセスがTLS経由の場合は、次のようにパラメータを指定します:
    TARGETDATABASE_CONNECTIONDETAILS_TLSDETAILS_*

関連トピック

5.13 NFSデータ転送メディアを使用した共同管理データベース・サーバーへの移行

NFSマウント・パスのダンプは、ソース・データベース・ユーザーの一意の識別子(UID)がターゲット・データベース・ユーザーと一致しないかぎり、ターゲット・データベース・ユーザーには読み取れません。

論理移行の準備をするには、ソース・データベースで次の前提条件を完了します。

次のシナリオが考えられます:
  • IDが一致する場合、ダンプはデフォルトで読取り可能であり、アクションは必要ありません。
  • IDが一致しない場合、ZDMはターゲット・データベース・ユーザーのプライマリ・グループを自動的に検出し、ダンプのグループをターゲット・データベース・ユーザーのプライマリ・グループに変更します。

    ノート:

    現在、このオプションはIBM AIXではサポートされていません。
    • このアクションを実行するには、データベース・サーバーのソース・データベース・ユーザーが、ターゲット・データベース・ユーザーのプライマリ・グループと同じグループIDのグループに属している必要があります。
    • 使用可能なグループがない場合は、ターゲット・データベース・ユーザーのGIDと一致するGIDで補助グループをソース・データベース・サーバーに作成します。
    • ソース・データベース・ユーザーを補助グループの一部にします。

      ノート:

      例として、「Oracle Autonomous Database on Exadata Cloud@Customerへの移行」の「Exadata Cloud@Customer環境の前提条件の設定」のステップ1からステップ3を参照してください。
  • ただし、GIDが使用できず、前述の2つの条件を満たすことができない場合は、オプションとしてDUMPTRANSFERDETAILS_PUBLICREADの値をTRUEに設定し、NFS上のダンプ・ファイルを他のユーザーが読み取れるようにすることが可能です。

ノート:

DUMPTRANSFERDETAILS_PUBLICREADの値がTRUEの場合、ネットワーク・ストレージにアクセスできるすべてのユーザーがData Pumpダンプを読み取ることができます。