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

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

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

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

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

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

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

  • 初期化パラメータ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 (Exadata Cloud@Customer)に移行する場合、追加の前提条件設定タスクについて、Exadata Cloud@Customer上のOracle Autonomous Databaseへの移行を参照してください。

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

  • ソースが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 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の作成、変更および削除操作はレプリケートされません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Object Storageをデータ転送メディアとして使用している場合は、Oracle Cloud Infrastructureでオブジェクト・ストア・バケットを作成します。これは、Exadata Cloud at 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への移行にあります。

  • 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ユーザーに似ていますが、より多くの権限が必要です。Replicatのすべてのモード・ユーザーに必要な権限の詳細は、Oracle GoldenGate資格証明の確立を参照してください。

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

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

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

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

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

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

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

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

必要な論理移行レスポンス・ファイル・パラメータを設定します。データベース移行プロシージャの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専用インフラストラクチャ、およびCloud@Customer上のAutonomous Databaseの場合は、このパラメータに、適切なサービス別名を指定する必要があります。

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

      • TP_TLS、TP、LOW_TLSまたはLOW (Autonomous Transaction Processingのワークロードの場合)
      • LOW_TLSまたはLOW (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の設定

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

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

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

Oracle Data Pump設定

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

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への移行を参照してください。

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

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サーバーを転送ノードとして利用することで、追加の転送ノード要件を回避できます。

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

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

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

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が使用可能であることを確認します。

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

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

EXLCUDEOBJECTS-nおよびINCLUDEOBJECTS-nレスポンス・ファイル・パラメータを使用して、移行ジョブに含めるオブジェクトまたは含めないオブジェクトのルールを指定します。

移行にオブジェクトを含めるか含めないかのどちらかが可能であり、両方はできません。

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

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

除外ルールを指定した場合、移行では、指定したオブジェクトとその依存オブジェクトが除外されます。他のすべてのオブジェクトは移行に含まれます。

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

単一の包含ルールの例:

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

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

INCLUDEOBJECTS-nおよびEXLCUDEOBJECTS-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の場合のみ使用できます。

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

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

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

DIRECTORY

FUNCTION

JOB

MATERIALIZED_VIEW

PACKAGE

PROCEDURE

TRIGGER

SEQUENCE

TABLE

一般的な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

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

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

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は設定されません。

グローバル一時表は常に除外されます。

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の使用』のフラッシュバック問合せの設定に関する項に記載されているようにソース・データベースを構成します。

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

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

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

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

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

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

データ・ポンプ・パラメータ デフォルト値 オーバーライドする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

表領域の自動作成

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

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サイズが決定されます。

表領域の自動再マップ

論理移行の場合、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_*セクションを参照してください。

メタデータの再マッピング

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プロシージャを参照してください。

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

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

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

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

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

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

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

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

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「データ・ポンプ・ジョブの最大数を超えています。」が発生します。

Exadata Cloud@Customer上のOracle Autonomous Databaseへの移行

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

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

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

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

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

移行パラメータ

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

MIGRATION_METHOD=OFFLINE_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]$