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

4 物理データベース移行の準備

Zero Downtime Migrationの物理データベース移行を開始する前に、サーバー間の接続の構成、ソース・データベースとターゲット・データベースの準備、レスポンス・ファイルでのパラメータの設定、必要な移行ジョブのカスタマイズの構成を実行する必要があります。

新機能、既知の問題、My Oracle Supportノートの最新情報は、Zero Downtime Migrationリリース・ノートを参照してください。

ソース・データベースおよびターゲット・データベースの準備

移行ジョブを構成する前に、ソース・データベースとターゲット・データベースで完了しておく必要があるタスクがいくつかあります。

ノート:

Zero Downtime Migrationのオンライン物理移行ではOracle Data Guardを利用するため、ソースとターゲットの両方で同じオペレーティング・システムおよびデータベース・バージョンが必要です。

ただし、Standard EditionデータベースではZero Downtime Migrationを使用できますが、Data Guardを使用しないバックアップおよびリストア方法に基づいたオフライン移行方法を使用する必要があることに注意してください。

Zero Downtime Migrationの物理移行ワークフローでは、エディション間の移行はサポートされていませんが、論理移行ワーク・フローを使用して、Standard EditionをEnterprise Editionに移行できます。

ソース・データベースの前提条件

Zero Downtime Migrationプロセスを開始する前に、ソース・データベースで次の前提条件を満たします。

  • ソース・データベースはARCHIVELOGモードで稼働している必要があります。データベースのアーカイブ・モードの変更を参照してください。

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

  • Oracle Database 12cリリース2以降でTDEウォレットを構成します。Oracle Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1でのTDEの有効化はオプションです。

    Oracle Database 12cリリース2以降では、ソース・データベースで透過的データ暗号化(TDE)が有効になっていない場合、移行を開始する前にTDEウォレットを構成する必要があります。WALLET_TYPEは、AUTOLOGIN (優先)またはPASSWORDベースのいずれかです。

    ウォレットのSTATUSがOPENであり、WALLET_TYPEがAUTOLOGIN (AUTOLOGINウォレット・タイプの場合)またはWALLET_TYPEがPASSWORD (PASSWORDベースのウォレット・タイプの場合)であることを確認します。マルチテナント・データーベースの場合は、すべてのPDBおよびCDBでウォレットがオープンされており、マスター・キーがすべてのPDBおよびCDBに設定されていることを確認します。 

    SQL> SELECT * FROM v$encryption_wallet;

  • ソースがOracle RACデータベースで、SNAPSHOT CONTROLFILEが共有の場所にない場合、Oracle Object Storeへのバックアップ中にORA-00245エラーが発生しないように、すべてのOracle RACノード上にある共有の場所を指すようSNAPSHOT CONTROLFILEを構成します。

    たとえば、データベースがASMストレージにデプロイされている場合は次のようにします。

    $ rman target /  
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/db_name/snapcf_db_name.f';

    データベースがACFSファイル・システムにデプロイされている場合は、前述のコマンドに共有のACFSの場所を指定します。

  • ソース・データベース・サーバーのポート22でZero Downtime Migrationサービス・ホストからの着信接続が許可されることを確認します。

  • ソース・データベース・サーバーのSCANリスナー・ポート(1521など)でターゲット・データベース・サーバーからの着信接続およびターゲット・データベース・サーバーへの発信接続が許可されることを確認します。

    ファイアウォールでSCANリスナー・ポートを使用する着信リモート接続がブロックされる場合は、代替SQL接続を使用可能にする必要があります。

  • 移行時にソース・データベースのリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を保持するには、既存のRMANバックアップ計画を保持する必要があります。

    移行中に、デュアル・バックアップ計画が実施されます。既存のバックアップ計画と、Zero Downtime Migrationにより使用される計画です。2つのRMANバックアップ・ジョブ(既存のジョブとZero Downtime Migrationにより開始されたジョブ)を同時に実行することは避けてください。ソース・データベースでアーカイブ・ログが削除され、これらのアーカイブ・ログが、ターゲット・クラウド・データベースを同期させるためにZero Downtime Migrationで必要な場合は、Zero Downtime Migrationで移行プロセスを続行できるように、これらのファイルをリストアする必要があります。

  • ソース・データベースがOracle Grid Infrastructureを使用してデプロイされ、SRVCTLを使用してデータベースが登録されていない場合は、移行前にデータベースを登録する必要があります。

  • ソース・データベースではサーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。

  • 制御ファイルおよびSPFILEを自動的にバックアップするようにRMANがまだ構成されていない場合は、CONFIGURE CONTROLFILE AUTOBACKUPをONに設定し、移行の完了後にOFFに戻します。 

    RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

  • オフライン移行の場合は、移行中にデータが失われないように、ZDM_BACKUP_DIFFERENTIAL_SRCフェーズの前にソース・データベースで受信トランザクションが行われないように計画します。Zero Downtime Migrationがバックアップの生成を開始して転送すると、ソース上の新しいトランザクションはバックアップの一部にならないため、クラウド内のターゲットにはこれらの変更が含まれません。

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

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

  • ソース・データベースとターゲット・データベースで、COMPATIBLEデータベース初期化パラメータを同じ値に設定します。有効な値は、Oracle DatabaseのCOMPATIBLE初期化パラメータの値を参照してください。

関連項目:

透過的データ暗号化キーストアの設定

Zero Downtime Migrationのポートの要件

ターゲット・データベースの前提条件

Zero Downtime Migrationプロセスを開始する前に、ターゲット・データベースで次の前提条件を満たす必要があります。

  • プレースホルダ・ターゲット・データベースを作成する必要があります。

    Exadata Cloud ServiceおよびExadata Cloud at Customerターゲットの場合、データベースの移行を開始する前に、Grid Infrastructureデータベース・サービスではなくコントロール・プレーンを使用してプレースホルダ・データベースを作成する必要があります。

    ノート:

    このリリースでは、Grid Infrastructureベースのデータベース・サービスのみがターゲットとしてサポートされます。たとえば、LVMベースのインスタンスまたはGrid Infrastructureがないコンピュート・ノードに作成されたインスタンスは、サポートされているターゲットではありません。

    プレースホルダ・ターゲット・データベースは移行時に上書きされますが、全体の構成は維持されます。

    次の要件に細心の注意を払ってください。

    • 将来のサイズ - コンソールからデータベースを作成する際、選択したシェイプがソース・データベースを収容でき、将来のサイズ変更の要件に適応できることを確認します。適切なガイドラインは、ソース・データベースと同程度以上のサイズのシェイプを使用することです。
    • 名前パラメータの設定
      • DB_NAME - ターゲット・データベースがExadata Cloud ServiceまたはExadata Cloud at Customerの場合、データベースDB_NAMEはソース・データベースDB_NAMEと同じである必要があります。ターゲット・データベースがOracle Cloud Infrastructureの場合、データベースDB_NAMEはソース・データベースDB_NAMEと同じでも、異なってもかまいません。
      • DB_UNIQUE_NAME: ターゲット・データベースがOracle Cloud Infrastructure、Exadata Cloud ServiceまたはExadata Cloud at Customerの場合、Oracle Data Guardがターゲットをソース・データベースとは異なるデータベースとして識別できるように、ターゲット・データベースのDB_UNIQUE_NAMEパラメータ値は一意である必要があります。
    • ソースSYSパスワードとの一致 - ソース・データベースのパスワードと一致するSYSパスワードを指定します。
    • 自動バックアップの無効化 - 自動バックアップを有効にせずに、コンソールからターゲット・データベースをプロビジョニングします。

      Oracle Cloud InfrastructureおよびExadata Cloud Serviceの場合は、「Configure database backups」セクションの「Enable automatic backups」オプションを選択しないでください。

      Exadata Cloud at Customerの場合は、「Configure Backups」セクションでバックアップ先の「Type」を「None」に設定します。

  • ターゲット・データベース・バージョンをソース・データベース・バージョンと同じにする必要があります。ターゲット・データベースのパッチ・レベルもソース・データベースと同じ(またはそれ以上)にする必要があります。

    ターゲット・データベース環境のパッチ・レベルがソース・データベースよりも高い場合(たとえば、ソース・データベースがJan 2020 PSU/BPで、ターゲット・データベースがApril 2020 PSU/BPの場合)、Zero Downtime Migrationは移行の一部としてdatapatchユーティリティを実行します。

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

  • ターゲット・データベースのタイムゾーン・バージョンは、ソース・データベースのタイムゾーン・バージョンと同じである必要があります。現在のタイムゾーン・バージョンを確認するには、次に示すようにV$TIMEZONE_FILEビューを問い合せ、必要に応じてタイムゾーン・ファイルをアップグレードします。 

    SQL> SELECT * FROM v$timezone_file;

  • TDEウォレット・フォルダが存在することを確認し、ウォレットのSTATUSがOPENで、WALLET_TYPEがAUTOLOGIN (自動ログイン・ウォレット・タイプの場合)またはWALLET_TYPEがPASSWORD (パスワードベースのウォレットの場合)であることを確認します。マルチテナント・データーベースの場合は、すべてのPDBおよびCDBでウォレットがオープンされており、マスター・キーがすべてのPDBおよびCDBに設定されていることを確認します。 

    SQL> SELECT * FROM v$encryption_wallet;

  • ターゲット・データベースではサーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。

  • ターゲットがOracle RACデータベースの場合、oracleユーザーのOracle RACサーバー間にパスフレーズなしのSSH接続が設定されていることを確認します。

  • ターゲット・データベースのディスク・グループ(ASMディスク・グループまたはACFSファイル・システム)のサイズおよび使用率をチェックし、十分な記憶域がターゲット・データベース・サーバーでプロビジョニングされ、使用可能であることを確認します。

  • ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。

  • Oracle Cloud Infrastructure、Exadata Cloud ServiceまたはExadata Cloud at Customer環境のターゲット・サーバーのポート22および1521 (または構成済のデータベース・リスナー・ポート)がオープンされており、ファイアウォールによってブロックされていないことを確認します。

  • ターゲット・データベース・サーバーのポート22でZero Downtime Migrationサービス・ホストからの着信接続が許可されることを確認します。

  • 移行後のRMAN設定を比較できるように、RMAN SHOW ALLコマンドの出力を取得した後、変更されたRMAN構成設定をリセットして問題なくバックパップが機能することを確認します。 

    RMAN> show all;

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

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

  • ソース・データベースとターゲット・データベースで、COMPATIBLEデータベース初期化パラメータを同じ値に設定します。有効な値は、Oracle DatabaseのCOMPATIBLE初期化パラメータの値を参照してください。

関連項目:

Object Storageバックアップ用の認証トークンの生成方法の詳細は、ユーザー資格証明の管理を参照してください。

Zero Downtime Migrationのポートの要件

透過的データ暗号化キーストアの設定

Oracle Database 12cリリース2以降では、ソース・データベースおよびターゲット・データベースで透過的データ暗号化(TDE)が有効になっていない場合、移行を開始する前にTDEキーストアを構成する必要があります。

TDEは有効になっている必要があり、ソース・データベースとターゲット・データベースの両方でTDE WALLETステータスをOPENに設定する必要があります。WALLET_TYPEは、自動ログイン・キーストアの場合はAUTOLOGIN (優先)、パスワードベースのキーストアの場合はPASSWORDです。マルチテナント・データベースで、すべてのPDBおよびCDBでキーストアがオープンされており、マスター・キーがすべてのPDBおよびCDBに設定されていることを確認します。

ソースおよびターゲットのデータベースでTDEが必須としてまだ構成されていない場合は、次の手順に従ってTDEキーストアを設定します。

パスワードベースのキーストアの場合はステップ1、2および4のみを実行し、自動ログイン・キーストアの場合はすべてのステップを実行します。

  1. $ORACLE_HOME/network/admin/sqlnet.oraファイルにENCRYPTION_WALLET_LOCATIONを設定します。 

    /home/oracle>cat /u01/app/oracle/product/12.2.0.1/dbhome_4/network/admin/sqlnet.ora 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
  (METHOD_DATA=(DIRECTORY=/u01/app/oracle/product/12.2.0.1/dbhome_4/network/admin/)))

    Oracle RACインスタンスの場合は、2番目のOracle RACノードでもENCRYPTION_WALLET_LOCATIONを設定します。

  2. キーストアを作成して構成します。

    1. データベースに接続してキーストアを作成します。

      $ sqlplus "/as sysdba"
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin'
 identified by password;

    2. キーストアを開きます。

      非CDB環境の場合は、次のコマンドを実行します。

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
keystore altered.

      CDB環境の場合は、次のコマンドを実行します。

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password container = ALL;
keystore altered.

    3. マスター暗号化キーを作成してアクティブにします。

      非CDB環境の場合は、次のコマンドを実行します。

      SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password with backup;
keystore altered.

      CDB環境の場合は、次のコマンドを実行します。

      SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password with backup container = ALL;
keystore altered.

    4. V$ENCRYPTION_KEYSを問い合せて、キーストアのステータス、キーストアのタイプおよびキーストアの場所を取得します。 

      SQL> SELECT * FROM v$encryption_keys;

WRL_TYPE    WRL_PARAMETER
--------------------            --------------------------------------------------------------------------------
STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC    CON_ID
------------------------------ -------------------- --------- ---------            ----------
FILE        /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN                           PASSWORD             SINGLE    NO         0

    パスワードベースのキーストアの構成はこの段階で完了し、キーストアはステータスOPENで有効になり、WALLET_TYPEは前述の問合せ出力でPASSWORDと表示されます。

    自動ログイン・キーストアを構成する必要がある場合のみステップ3に進み、それ以外の場合はステップ4に進みます。

  3. 自動ログイン・キーストアの場合のみ、キーストア構成を実行します。

    1. 自動ログイン・キーストアを作成します。

      SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
 '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/' IDENTIFIED BY password;
keystore altered.

    2. パスワードベースのキーストアを閉じます。

      SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password;
keystore altered.

    3. V$ENCRYPTION_WALLETを問い合せて、キーストアのステータス、キーストアのタイプおよびキーストアの場所を取得します。 

      SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE WRL_PARAMETER
-------------------- --------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR FULLY_BAC CON_ID
------------------------------ -------------------- --------- --------- ---------
FILE /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN AUTOLOGIN SINGLE NO

      問合せ出力で、TDEキーストアのSTATUSがOPENで、WALLET_TYPEがAUTOLOGINに設定されていることを確認します。そうでない場合、自動ログイン・キーストアは正しく設定されていません。

      これで、自動ログイン・キーストアの構成が完了しました。

  4. キーストア・ファイルを2番目のOracle RACノードにコピーします。

    Oracle RACの共有ファイル・システムでキーストアを構成した場合、または単一インスタンス・データベースに対してTDEを有効にする場合、アクションは必要ありません。

    キーストアへの共有アクセスなしでOracle RACデータベースに対してTDEを有効にする場合は、次のファイルを2番目のノードの同じ場所にコピーします。

    • /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/ew*

    • /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/cw*

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

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

次のレスポンス・ファイル設定は、一般的なユースケースの構成方法を示しています。構成をさらにカスタマイズするには、Zero Downtime Migration物理移行レスポンス・ファイル・パラメータのリファレンスで説明されている追加パラメータを参照してください。

TGT_DB_UNIQUE_NAME

TGT_DB_UNIQUE_NAMEをターゲット・データベースのDB_UNIQUE_NAME値に設定します。DB_UNIQUE_NAMEを見つけるには、次を実行します。 

SQL> show parameter db_unique_name

クラウド・タイプExadata Cloud at Customer Gen 1の場合、TGT_DB_UNIQUE_NAMEを現在使用されていない別のDB_UNIQUE_NAMEに設定します

PLATFORM_TYPE

PLATFORM_TYPEを次のいずれかの値に設定します。

  • VMDB - Oracle Cloud Infrastructure仮想マシンまたはベア・メタル・ターゲット。

  • EXACS - Exadata Cloud Service

  • EXACC - Exadata Cloud at Customer

  • NON_CLOUD - オンプレミスExadata Database Machine

MIGRATION_METHOD

MIGRATION_METHODを次のいずれかの値に設定します。

  • ONLINE_PHYSICAL - Oracle Data Guard (オンライン)

  • OFFLINE_PHYSICAL - RMANのバックアップおよびリストア(オフライン)。これは、Oracle Standard Editionデータベースでサポートされている唯一の移行方法です。

DATA_TRANSFER_MEDIUM

DATA_TRANSFER_MEDIUMでソース・データベースのバックアップに使用するメディアを指定するか、直接データ転送を構成できます。

  • OSS - スタンバイ初期化にObject Storageサービス(OSS)を使用するOracle Data Guard。

    Oracle Cloud Infrastructure (VMDB)、Exadata Cloud Service (EXACS)およびExadata Cloud at Customer (EXACC)に設定されたPLATFORM_TYPEでサポートされます。

    また、移行ログをCloud Object Storageにアップロードする場合は、ZDM_LOG_OSS_PAR_URLをCloud Object Storeの事前認証済URLに設定します。事前認証済URLの取得の詳細は、Oracle Cloudのドキュメント(https://docs.cloud.oracle.com/en-us/iaas/Content/Object/Tasks/usingpreauthenticatedrequests.htm#usingconsole)を参照してください。

    Object Storage Serviceを介してバックアップおよびリストア(OFFLINE_PHYSICAL)を使用して移行を実行する場合、ソースとターゲットの間のSQL*Net接続は必要ありません。

  • EXTBACKUP - 外部の場所に既存のバックアップがあるOracle Data Guard。

    Exadata Cloud at Customer (EXACC)またはオンプレミスのExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPEでサポートされます

    また、指定したパスにスタンバイ制御ファイルのバックアップを作成し、ターゲット・データベース・ユーザーのバックアップ・ピースに対する読取り権限を付与します。次に例を示します。

    RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT 'BACKUP_PATH/lower_case_dbname/standby_ctl_%U';

    standby_ctl_%Uは、システム生成の一意のファイル名です。

  • ZDLRA - スタンバイ初期化にZDLRAを使用するOracle Data Guard。

    Exadata Cloud at Customer (EXACC)またはオンプレミスのExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPEでサポートされ、次のパラメータを設定します。

    • 次のように、SRC_ZDLRA_WALLET_LOCをウォレットの場所に設定します。 

      SRC_ZDLRA_WALLET_LOC=/u02/app/oracle/product/12.1.0/dbhome_3/dbs/zdlra

    • TGT_ZDLRA_WALLET_LOCをウォレット・ロケーションに設定します(例: TGT_ZDLRA_WALLET_LOC=target_database_oracle_home/dbs/zdlra)。

    • 次のように、ZDLRA_CRED_ALIASをウォレットの資格証明別名に設定します。 

      ZDLRA_CRED_ALIAS=zdlra_scan:listener_port/zdlra9:dedicated

  • NFS - NFSなどのバックアップ場所を使用するOracle Data Guard。

    Exadata Cloud at Customer (EXACC)またはオンプレミスのExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPEでサポートされます。

    また、BACKUP_PATHを設定して、ソースとターゲットの両方のデータベース・サーバーからアクセスできるようになっている実際のNFSパス(NFSマウント・ポイントなど)を指定します。NFSマウント・パスはソースとターゲットの両方のデータベース・サーバーで同じである必要があります。このパスは、Zero Downtime Migrationサービス・ホストにマウントされている必要はありません。

    NFSを介してバックアップおよびリストア(OFFLINE_PHYSICAL)を使用して移行を実行する場合、ソースとターゲットの間のSQL*Net接続は必要ありません。

    次の考慮事項に注意してください。

    • ソース・データベースは、RMAN SQL*Net接続を使用して、指定されたパスにバックアップされ、Exadata Cloud at Customerにリストアされます。

    • BACKUP_PATHに設定するパスには、ソース・データベース・ユーザーの場合は'rwx'権限が、ターゲット・データベース・ユーザーの場合は読取り権限以上が必要です。

    • BACKUP_PATHで指定したパスに、Zero Downtime Migrationバックアップ手順によってディレクトリ$BACKUP_PATH/dbnameが作成され、このディレクトリにバックアップ・ピースが格納されます。

  • DIRECT - RMANのアクティブなデータベースの複製またはサービスからのリストアを使用して、データをソースからターゲットに直接転送します。

    RMANのアクティブ・データベースの複製は、Oracle Database 11g (11.2)以降のリリースでサポートされており、11gR2データベースで使用可能な唯一のオプションになります。サービスからのRMANのリストアは、Oracle Database 12g (12.1)以降のリリースでサポートされています。

    接続はターゲット・データベース・ホストから開始されるため、アクティブな複製とサービスからのリストアの直接転送方法の両方で、ターゲットからソース・データベースへのSQL*Net接続が必要です。

    転送方法(サービスからのリストアまたはアクティブな複製)は、デフォルトでRESTORE_FROM_SERVICEに設定されているZDM_RMAN_DIRECT_METHODで構成されます。

    サービス方式からのリストアを使用するには、ZDM_SRC_DB_RESTORE_SERVICE_NAMEを、移行に使用されるソース・データベースのサービスの完全修飾名にも設定します。指定しない場合は、デフォルトのデータベース・サービスが使用されます。

    転送方法の詳細は、直接データ転送のサポートを参照してください。

    ソースとターゲット間に非対話型のアクセスも設定する必要があります。ウォレットを使用した非対話型のパスワード指定を参照してください。

追加のOracle Cloud Object Storage設定

DATA_TRANSFER_MEDIUM=OSSの場合、Oracle Cloud Object Storageにアクセスするために次のパラメータを設定します。ソース・データベースは、指定されたコンテナにバックアップされ、RMAN SQL*Net接続を使用してターゲットにリストアされます。

  • HOSTをクラウド・ストレージのRESTエンドポイントURLに設定します。

    • Oracle Cloud Infrastructureの記憶域の場合、一般的な値の形式はHOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/ObjectStorageNamespaceです

      Object Storage Namespaceの値を見つけるには、Cloudコンソールにログインして「Menu」→「Administration」→「Tenancy Detail」を選択し、「Object Storage Settings」セクションで「Value against entry Object Storage Namespace」を見つけます。

    • Oracle Cloud Infrastructure Classicの記憶域の場合、一般的な値の形式はHOST=https://acme.storage.oraclecloud.com/v1/Storage-tenancy nameです

  • Object StorageバケットのOPC_CONTAINERパラメータを設定します。

    バケットは、Oracle Cloud Infrastructure Classicストレージではコンテナとも呼ばれます。必要に応じてOracle Cloud Serviceコンソールを使用してObject Storageバケットが作成されていることを確認します。ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。

TGT_SSH_TUNNEL_PORT

SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。

データおよびREDOの場所

Zero Downtime Migrationでは、指定されたターゲット・データベースからdata、recoおよびredo (Exadata以外のシステムの場合)ストレージ・ボリュームの場所が自動的に検出されます。検出された値をオーバーライドする必要がある場合は、適切なパラメータ・セットを使用してターゲット・データベース・データ・ファイルの記憶域(ASMまたはACFS)の場所を指定します。

  • ASM: TGT_DATADG、TGT_REDODGおよびTGT_RECODG
  • ACFS: TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS

SKIP_FALLBACK

任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。

TGT_SKIP_DATAPATCH

Zero Downtime Migrationは、ターゲット・データベース環境のパッチ・レベルがソース・データベースよりも高い場合(たとえば、ソース・データベースがJan 2020 PSU/BPで、ターゲット・データベースがApril 2020 PSU/BPの場合)、デフォルトでdatapatchユーティリティを移行プロセスの一部として実行します。

このタスクをスキップする場合は、TGT_SKIP_DATAPATCH=FALSEレスポンス・ファイル・パラメータを設定します。

PHASE_NAME_MONITORING_INTERVAL

Zero Downtime Migrationで、移行中に構成された時間間隔でバックアップおよびリストア操作のステータスをモニターおよびレポートする場合は、PHASE_NAME_MONITORING_INTERVAL=n minsを設定します。デフォルトの間隔値は10分です。モニタリングを無効にするには、これらの値を0 (ゼロ)に設定します。 

ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL= 
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL= 
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL= 
ZDM_CLONE_TGT_MONITORING_INTERVAL= 
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL= 
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=

ZDM_BACKUP_RETENTION_WINDOW

移行後にソース・データベースのバックアップを保持する場合は、ZDM_BACKUP_RETENTION_WINDOW=number of daysを設定します。

ZDM_SRC_TNS_ADMIN

カスタムの場所の場合は、ZDM_SRC_TNS_ADMIN=TNS_ADMIN valueを設定します。

ウォレットを使用した非対話型のパスワード指定

Rundeckを使用して自動化を行う場合など、コマンドラインでパスワードを入力することを避け、ユーザーとのやり取りなしでZDMCLI migrate databaseコマンドを実行できます。

ノート:

このウォレットベースのパスワード入力オプションは、物理オンラインおよびオフライン移行ジョブでのみサポートされています。

現在、$ZDM_HOME/bin/zdmcli migrate databaseコマンドを発行するたびに、ソース・データベースのSYSパスワード、Object Storeユーザー・スイフト認証トークンおよびソース・データベースの透過的データ暗号化(TDE)キーストア・パスワード(PASSWORDベースのTDEウォレットとしてウォレットが構成されている場合)の入力を求められます。

さらに、非マルチテナント・ソース・データベースをターゲット上のマルチテナント・アーキテクチャ、つまりプラガブル・データベース(PDB)に変換する場合は、ターゲット・コンテナ・データベース(CDB)のTDEキーストア・パスワード用の自動ログイン・ウォレットを作成することもできます。

Zero Downtime Migrationサービス・ホストで、Zero Downtime Migrationソフトウェア所有者(zdmuserなど)として次のコマンドを実行します。

ソース・データベースSYSユーザーの自動ログイン・ウォレットを作成するには:

  1. ウォレットを作成して格納するディレクトリを作成します。

    zdmuser> mkdir sys_wallet_path

    次に例を示します。 

    /u01/app/zdmhome> mkdir sysWallet

  2. ウォレットを作成します。

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet sys_wallet_path 
-auto_login_only

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet sysWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. SYSユーザー・ログイン資格証明をウォレットに追加します。 

    zdmuser> $ZDM_HOME/bin/mkstore -wrl sys_wallet_path 
-createCredential store sysuser

    プロンプトで、ソース・データベースのSYSパスワードを入力します。

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./sysWallet 
-createCredential store sysuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. ウォレット・ファイルが作成されたことを確認します。

    zdmuser> ls -l sys_wallet_path

    次に例を示します

    /u01/app/zdmhome> ls -l sysWallet/
total 4
-rw-------. 1 opc opc 581 Jun  2 08:00 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:00 cwallet.sso.lck

Object Storeユーザーの自動ログイン・ウォレットを作成するには:

  1. ウォレットを作成して格納するディレクトリを作成します。

    zdmuser> mkdir oss_wallet_path

    次に例を示します

    /u01/app/zdmhome> mkdir ossWallet

  2. ウォレットを作成します

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet oss_wallet_path 
-auto_login_only

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create 
-wallet ./ossWallet -auto_login_only 
Oracle PKI Tool Release 19.0.0.0.0 -Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019,
Oracle and/or its affiliates. All rights reserved.

 Operation is successfully completed.

  3. Object Storeユーザー・ログイン資格証明をウォレットに追加します。

    zdmuser> $ZDM_HOME/bin/mkstore -wrl oss_wallet_path 
-createCredential store ossuser

    プロンプトで、

    • バックアップ先がObject Store (バケット)の場合は、ユーザーswift認証トークンを入力します。

    • バックアップ先がStorage Classic (コンテナ)の場合は、テナンシ・ログイン・パスワードを入力します。

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./ossWallet 
-createCredential store ossuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. ウォレット・ファイルが作成されたことを確認します。

    zdmuser> ls -l oss_wallet_path

    次に例を示します

    /u01/app/zdmhome> ls -l ./ossWallet
total 4
-rw-------. 1 opc opc 597 Jun  2 08:02 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:01 cwallet.sso.lck

ソース・データベースのTDEキーストアの自動ログイン・ウォレットを作成するには:

  1. ウォレットを作成して格納するディレクトリを作成します。

    zdmuser> mkdir tde_wallet_path

    次に例を示します

    /u01/app/zdmhome> mkdir tdeWallet

  2. ウォレットを作成します。

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet tde_wallet_path 
-auto_login_only

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet ./tdeWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. ソース・データベースTDEキーストア資格証明をウォレットに追加します。

    zdmuser> $ZDM_HOME/bin/mkstore -wrl tde_wallet_path 
-createCredential store tdeuser

    プロンプトで、TDEキーストア・パスワードを入力します。

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./tdeWallet 
-createCredential store tdeuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

  4. ウォレット・ファイルが作成されたことを確認します。

    zdmuser> ls -l tde_wallet_path

    次に例を示します

    /u01/app/zdmhome> ls -l tdeWallet
total 4
-rw-------. 1 opc opc 581 Jun  2 08:06 cwallet.sso
-rw-------. 1 opc opc   0 Jun  2 08:04 cwallet.sso.lck

ターゲットCDBデータベースのTDEキーストア・パスワードの自動ログイン・ウォレットを作成するには:

  1. ウォレットを作成して格納するディレクトリを作成します。

    zdmuser> mkdir cdb_tde_wallet_path

    次に例を示します

    /u01/app/zdmhome> mkdir cdbtdeWallet

  2. ウォレットを作成します。

    zdmuser> $ZDM_HOME/bin/orapki wallet create -wallet cdb_tde_wallet_path 
-auto_login_only

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/orapki wallet create -wallet ./cdbtdeWallet 
-auto_login_only
Oracle PKI Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Operation is successfully completed.

  3. ソース・データベースTDEキーストア資格証明をウォレットに追加します。

    zdmuser> $ZDM_HOME/bin/mkstore -wrl cdb_tde_wallet_path 
-createCredential store cdbtdeuser

    プロンプトで、TDEキーストア・パスワードを入力します。

    次に例を示します

    /u01/app/zdmhome> $ZDM_HOME/bin/mkstore -wrl ./cdbtdeWallet 
-createCredential store cdbtdeuser
Oracle Secret Store Tool Release 19.0.0.0.0 - Production
Version 19.4.0.0.0
Copyright (c) 2004, 2019, Oracle and/or its affiliates. All rights reserved.

Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:

ウォレットにアクセスするためのコマンド・オプションの設定

ZDMCLI MIGRATE DATABASEコマンドでウォレット情報を指定するには、次に示されているように-sourcesyswallet、-osswallet、-tdekeystorewalletおよび-tgttdekeystorewalletオプションを設定します。 

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name 
-srcauth zdmauth
-srcarg1 user:source_database_server_login_user_name
-srcarg2 identity_file:zdm_installed_user_private_key_file_location
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode target_database_server_name
-backupuser object_store_login_user_name 
-rsp response_file_location
-tgtauth zdmauth 
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:zdm_installed_user_private_key_file_location 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet sys_wallet_path 
-osswallet oss_wallet_path  
-tdekeystorewallet tde_wallet_path 
-tgttdekeystorewallet cdb_tde_wallet_path 
-eval
  • -sourcesyswallet sys_wallet_pathは、ソース・データベースのSYSパスワードを含むZero Downtime Migrationホスト上の自動ログイン・ウォレット・ファイルのフルパスを指定します。
  • -osswallet oss_wallet_pathは、Object Storage Serviceバックアップ・ユーザーの資格証明を含むZero Downtime Migrationホスト上の自動ログイン・ウォレット・ファイルのフルパスを指定します
  • -tdekeystorewallet tde_wallet_pathは、TDEキーストア・パスワードを含むZero Downtime Migrationホスト上の自動ログイン・ウォレット・ファイルのフルパスを指定します。
  • -tgttdekeystorewallet cdb_tde_wallet_pathは、ターゲットCDBのTDEキーストア・パスワードを含むZero downtime Migrationホスト上の自動ログイン・ウォレット・ファイルのフルパスを指定します

評価モードの例 

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb zdmsdb 
-sourcenode ocicdb1 
-srcauth zdmauth 
-srcarg1 user:opc 
-srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode ocidb1 
-backupuser backup_user@example.com 
-rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp 
-tgtauth zdmauth 
-tgtarg1 user:opc 
-tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet /u01/app/zdmhome/sysWallet 
-osswallet /u01/app/zdmhome/ossWallet 
-eval

Operation "zdmcli migrate database" scheduled with the job ID "1".

移行モードの例

zdmuser> $ZDM_HOME/bin/zdmcli migrate database 
-sourcedb zdmsdb 
-sourcenode ocicdb1 
-srcauth zdmauth 
-srcarg1 user:opc 
-srcarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-srcarg3 sudo_location:/usr/bin/sudo 
-targetnode ocidb1 
-backupuser backup_user@example.com 
-rsp /u01/app/zdmhome/rhp/zdm/template/zdm_template_zdmsdb.rsp 
-tgtauth zdmauth 
-tgtarg1 user:opc 
-tgtarg2 identity_file:/home/zdmuser/.ssh/zdm_service_host.ppk 
-tgtarg3 sudo_location:/usr/bin/sudo 
-sourcesyswallet /u01/app/zdmhome/sysWallet 
-osswallet /u01/app/zdmhome/ossWallet

Operation "zdmcli migrate database" scheduled with the job ID "2".

自動アプリケーション・スイッチオーバーの準備

データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。

ノート:

物理的な移行では、Autonomous Databaseターゲットは、自動アプリケーション・スイッチオーバーをサポートしていません。

次のサンプル接続文字列では、アプリケーションはソース・データベースに接続し、使用できない場合は、接続がターゲット・データベースに切り替わります。

(DESCRIPTION=
    (FAILOVER=on)(LOAD_BALANCE=on)(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
    (ADDRESS_LIST=
        (ADDRESS=(PROTOCOL=TCP)(HOST=source_database_scan)(PORT=1521))
        (ADDRESS=(PROTOCOL=TCP)(HOST=target_database_scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=zdm_prod_svc)))

この例では、ソース・データベースで、zdm_prod_svcという名前のサービスを作成します。

srvctl add service -db clever -service zdm_prod_svc -role PRIMARY
 -notification TRUE -session_state dynamic -failovertype transaction
 -failovermethod basic -commit_outcome TRUE -failoverretry 30 -failoverdelay 10
 -replay_init_time 900 -clbgoal SHORT -rlbgoal SERVICE_TIME -preferred clever1,clever2
 -retention 3600 -verbose

db_domainがソースとターゲットの間で変更された場合、フェイルオーバーを有効にするには、アプリケーションで指定された接続文字列が両方に対応している必要があります。 

(DESCRIPTION_LIST=
            (FAILOVER=ON)
            (LOAD_BALANCE=ON)
            (DESCRIPTION=
            (ADDRESS= (PROTOCOL=TCP) (HOST=SRC_SCAN) (PORT=1521))
            (CONNECT_DATA=
            (SERVICE_NAME=SVC.SRC_DOMAIN)))            
            (DESCRIPTION=
            (ADDRESS= (PROTOCOL=TCP) (HOST=TGT_SCAN) (PORT=1521))
            (CONNECT_DATA=
            (SERVICE_NAME= SVC.TGT_DOMAIN))

関連項目:

https://www.oracle.com/goto/maaのOracle Active Data Guardのベスト・プラクティス・ページのクライアント・フェイルオーバーのベスト・プラクティスに関するOracle MAAホワイト・ペーパー

Oracle Database開発ガイドの高可用性

断続的なネットワーク障害に対するレジリエンシの構成

Zero Downtime Migrationの物理移行は、バックアップまたはSSH接続の失敗を引き起こす可能性のある断続的なネットワーク障害に対する回復力を備えています。

Zero Downtime Migrationでは、断続的なネットワーク障害を自動検出できます。Zero Downtime Migrationでは、RMANの再試行可能なエラーが自動的に再試行され、再試行のカスタマイズが可能です。

SSH接続の再試行は、次のパラメータを使用してカスタマイズします。

SRC_SSH_RETRY_TIMEOUT

TGT_SSH_RETRY_TIMEOUT

次のパラメータを使用して、RMANバックアップの再試行をカスタマイズできます。

ZDM_OPC_RETRY_WAIT_TIME

ZDM_OPC_RETRY_COUNT

ZDM_OPC_RETRY_WAIT_TIME

移行中の非CDBのCDBへの変換

物理的移行プロセスの一環として、Zero Downtime Migrationは非CDBソース・データベースからクラウド内の同じバージョンのPDBへの変換を処理できます。変換プロセスでは、ソース非CDBをターゲットPDBに変換してから、ターゲットの既存のCDBにプラグインします。

非CDBからCDBへの変換により、停止時間が長くなります。このプロセスはオフラインであり(REDO転送および適用なし)、ロールバックはできません。

ソース非CDBデータベースの前提条件

  • Oracle Database 12c以降のバージョン(マルチテナント・アーキテクチャが使用可能になったため)

  • ターゲットCDBと同じキャラクタ・セット

ターゲット・データベースCDBおよびPDBの前提条件

  • Zero Downtime MigrationによってPDBが作成されるため、ターゲットCDBには結果として変換されたPDBと同じ名前のPDBを含めることはできません。

  • ターゲット・データベースは、少なくともソース・データベースと同じメジャー・バージョンである必要があります。

    • ターゲットでマイナー・バージョンが異なる場合、ソース・データベースよりも高いマイナー・バージョンである必要があります。
    • パッチ・レベルが異なる場合は、レスポンス・ファイル・パラメータTGT_SKIP_DATAPATCH=FALSEを設定する必要があります。

透過的データ暗号化の要件

  • ソース・データベースでは、透過的データ暗号化(TDE)はオプションです。TDEが設定されていない場合、これ以上の情報は必要ありませんが、ソースでTDEが設定されている場合は、TDE鍵をエクスポートおよびインポートするための資格証明が必要です。

  • ソース資格証明では、migrate databaseコマンドに-tdekeystorepasswdまたは-tdekeystorewallet自動ログイン・オプションを含める必要があります。

  • これらのオプションのいずれかを使用する場合は、-tgttdekeystorepasswdまたは-tgttdekeystorewallet自動ログイン・オプションを使用してターゲット資格証明も指定する必要があります。

Application Expressの要件

  • ソースにApplication Express (APEX)がインストールされていない場合、追加の要件はありません。

  • APEXがソースに存在し、ソース・データベースが非CDBである場合、次のいずれかのオプションを選択する必要があります。

    • ソース非CDBからAPEXを削除します。
    • ターゲットCDBのAPEXバージョンがソースのAPEXバージョンと同じであることを確認します。

      APEXが同じバージョンでない場合、変換はできません。APEXスキーマはバージョン間で異なり、ターゲットPDBを開くことができません。

ターゲットCDBはプロセスで削除されず、他のPDBの有無は変換およびプラグインの結果に影響しません。

レスポンス・ファイル・パラメータは次のように設定します。

  • (必須) NONCDBTOPDB_CONVERSION: ソース・データベースを非CDBからPDBに変換する場合はTRUEに設定します。
  • (オプション) NONCDBTOPDB_SWITCHOVER: 非CDBからPDBへの変換が有効な移行ジョブ中にスイッチオーバー操作を実行するには、Data Guardスイッチオーバーを使用した物理移行に対してTRUEに設定します。

TDE資格証明を使用した移行時に非CDBをPDBに変換するためのZDMCLI migrate databaseコマンドの使用例を次に示します。

対話的にパスワードを提供する例:

zdmuser> $ZDM_HOME/bin/zdmcli migrate database
  -sourcedb source_db_unique_name_value 
  -sourcenode source_database_server_name 
  -srcroot
  -targetnode target_database_server_name 
  -backupuser Object_store_login_user_name
  -rsp response_file_location 
  -tgtauth zdmauth 
  -tgtarg1 user:target_database_server_login_user_name
  -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
  -tgtarg3 sudo_location:/user/bin/sudo
  -tdekeystorepasswd 
  -tgttdekeystorepasswd

CDBのTDEキーストアに自動ログイン・ウォレットを使用する例:

zdmuser> $ZDM_HOME/bin/zdmcli migrate database
  -sourcedb source_db_unique_name_value 
  -sourcenode source_database_server_name 
  -srcroot
  -targetnode target_database_server_name 
  -backupuser Object_store_login_user_name
  -rsp response_file_location 
  -tgtauth zdmauth 
  -tgtarg1 user:target_database_server_login_user_name
  -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location 
  -tgtarg3 sudo_location:/user/bin/sudo
  -tdekeystorepasswd 
  -tgttdekeystorewallet /scratch/credentials/cdbtde.sso

既存のRMANバックアップを使用した移行ジョブの実行

Zero Downtime Migrationでは、既存のレベル0のバックアップを使用して、移行ジョブの全体バックアップ・フェーズをスキップできます。

Zero Downtime Migrationでは、オンラインおよびオフラインの両方の物理移行ジョブについて、レベル0およびレベル1のバックアップを即時に取得します。移行ジョブ中、Zero Downtime Migrationでは、全体バックアップを実行するかわりに既存のソース・データベースのバックアップを再利用できます。

DISK、SBT_TAPE、ZDLRAなどのすべてのタイプのバックアップ・デバイスが、この移行方法のデータ転送メディアとしてサポートされています。

このユースケースでは、incremental_level=0を指定したレベル0のバックアップのみが有効です。

既存のRMANバックアップを使用するには、次のレスポンス・ファイル・パラメータを設定します。

ZDM_USE_EXISTING_BACKUP=TRUE
ZDM_BACKUP_TAG=RMAN backup tag

ZDMCLI database migrationコマンドを評価モード(ZDMCLI database migration -eval)で実行すると、Zero Downtime Migrationによってバックアップの存在が検証され、そのバックアップが有効かどうかがチェックされ、ジョブ出力でバックアップが使用可能および検証されているかどうかが表示されます。

移行モード(ZDMCLI database migration)では、Zero Downtime Migrationは評価モードで実行されたものと同じステップを実行してから、全体バックアップをスキップし、増分バックアップや差分バックアップなどの他のバックアップ操作を実行します。

バックアップの作成

移行ソースとして使用する有効なRMANバックアップを取得するには、次のコマンドを実行します。

DISKの場合:

RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE DISK FORMAT 'directory_path/%d_backup_%U';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
 DATABASE FORMAT 'directory_path/%d_backup_%U_DBF' SECTION SIZE 4G ;
}

SBT_TAPEの場合:

RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE SBT FORMAT '%d_%I_%T-%s_%p'
 PARMS 'SBT_LIBRARY=path/libopc.so, SBT_PARMS=(OPC_PFILE=path/OPC/mzdm.conf)';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
 DATABASE FORMAT '%d_%I_%T-%s_%p_DBF' SECTION SIZE 4G ;
}

代替ユース・ケース

ZDM_BACKUP_TAG値が指定され、ZDM_USE_EXISTING_BACKUP=FALSEの場合、Zero Downtime Migrationによって、指定されたタグを含む全体バックアップが作成されます。

パスワード認証でのバックアップの使用

バックアップ・パスワード認証で既存のバックアップを使用するには、コマンドmigrate databaseで-backuppasswd passwordオプションを使用してパスワードを指定できます。

migrate databaseコマンドで-backupwalletを使用して、バックアップ・ウォレット・パスを指定することもできます。

オンプレミス・データベースのオンプレミスExadata Database Machineへの移行

Zero Downtime Migrationを使用したオンプレミスのExadata Database Machineターゲットへのオンプレミス移行は、クラウド・ターゲットへの移行と同じように機能します。レスポンス・ファイルで、PLATFORM_TYPE=NON_CLOUDを設定して、移行ターゲットがオンプレミスであることを指定します。

クラウド移行のシナリオと同様に、移行を開始する前に、初期化パラメータの構成を含め、必要なシェイプとサイズでターゲット・データベースをプロビジョニングする必要があります。ターゲット・データベースはソース・データベースと同じメジャー・バージョンである必要があり、Oracle Grid Infrastructureはターゲット・データベースで必須であり、ターゲット・データファイルはASMまたはACFSに格納できます。

オンプレミスからオンプレミスへの移行がクラウドへの移行と異なる点は、透過的データ暗号化(TDE)の処理です。クラウドでは、Oracle Database 12.2以上のリリースにTDEが必須ですが、オンプレミスからオンプレミスへの移行では、ソースでTDEが使用される場合にのみ、ターゲットでTDEを構成する必要があります。移行を開始する前に、ターゲットでTDEを構成する必要があります。Zero Downtime Migrationでは、TDEは構成されません。

レスポンス・ファイル・パラメータZDM_TDE_MANDATORY=FALSEを設定して、ソースまたはターゲットでTDEが構成されないことを指定できます。このパラメータは、PLATFORM_TYPE=NON_CLOUDを設定した場合にのみ使用できます。ZDM_TDE_MANDATORY=FALSEが設定されている場合、Zero Downtime Migrationでは、ソースでTDEが使用されていないときはターゲットでTDEを必要とせず、リストア時にターゲットを暗号化しません。

オンプレミスExadataターゲット・データベースの移行の場合、MIGRATION_METHODはONLINE_PHYSICALまたはOFFLINE_PHYSICALに設定でき、DATA_TRANSFER_MEDIUMはZero Downtime Migrationでサポートされている任意の値に設定できます。クラウド移行の場合と同様に残りのパラメータを設定します。