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

3 データベース移行の準備

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

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

  • 接続の前提条件の構成
    Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。
  • ソース・データベースおよびターゲット・データベースの準備
    移行のためにソースおよびターゲットのデータベースを準備する方法の詳細は、次の各トピックを参照してください。
  • レスポンス・ファイルの準備
    移行プロセスで使用している移行ターゲットおよびバックアップ・メディアのレスポンス・ファイル・パラメータを設定します。
  • 自動アプリケーション・スイッチオーバーの準備
    データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。
  • 移行ジョブのカスタマイズ
    移行ジョブに含まれる操作フェーズの一環として実行するために、アクション・スクリプトまたはアクション・プラグインをアクション前またはアクション後として登録すると、Zero Downtime Migrationワークフローをカスタマイズできます。

接続の前提条件の構成

Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。

次の各トピックでは、移行ジョブを実行する前にZero Downtime Migration接続の前提条件を構成する方法について説明します。

親トピック: データベース移行の準備

Zero Downtime Migrationサービス・ホストからソースおよびターゲットのデータベース・サーバーへの接続の構成

次の手順を実行して、Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間で必要な接続を確保します。

  1. Zero Downtime Migrationサービス・ホストで、Zero Downtime Migrationソフトウェア・インストール・ユーザーに認証鍵ペアがパスフレーズなしで使用できることを確認します。
    新しい鍵ペアをパスフレーズなしで生成する必要がある場合は、Zero Downtime Migrationソフトウェア・インストール・ユーザーとして、パスフレーズなしのSSH鍵の生成の説明に従って新しい鍵ペアを生成します。
  2. 秘密鍵ファイルの名前を変更します。
    zdm_installed_user_home/.ssh/id_rsaファイルの名前をzdm_installed_user_home/.ssh/zdm_service_host.ppkに変更します。
  3. 次の依存関係を使用して、zdm_installed_user_home/.ssh/id_rsa.pubファイルの内容をopc_user_home/.ssh/authorized_keysファイルに追加します。

    ソース・データベース・サーバーの場合:

    • ソース・データベース・サーバーにrootユーザーでアクセスする場合、アクションは必要ありません。
    • ソース・データベース・サーバーにSSHを介してアクセスする場合は、zdm_installed_user_home/.ssh/id_rsa.pubファイルの内容をすべてのソース・データベース・サーバー上にあるopc_user_home/.ssh/authorized_keysファイルに追加します。

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

    • ターゲット・データベース・サーバーはクラウド上にのみあり、SSHを介したアクセスであるため、zdm_installed_user_home/.ssh/id_rsa.pubファイルの内容をすべてのターゲット・データベース・サーバー上にあるopc_user_home/.ssh/authorized_keysファイルに追加します。

    opcユーザーは、データベース・サーバーへのアクセスに使用される標準のOracleクラウド・ユーザーですが、任意のユーザーを使用でき、ソース・データベース・サーバーとターゲット・データベース・サーバーに異なるユーザーを使用できます。

  4. ソースおよびターゲットのデータベース・サーバー名は、名前の解決サーバーまたはITインフラストラクチャで承認されている代替方法でZero Downtime Migrationサービス・ホストから解決可能であることを確認します。
    ソースおよびターゲットのデータベース・サーバー名の解決方法の1つとして、ソースおよびターゲットのデータベース・サーバー名およびIPアドレスの詳細をZero Downtime Migrationサービス・ホストの/etc/hostsファイルに追加します。

    次の例では、IPアドレス・エントリが192.x.x.xと表示されていますが、実際のパブリックIPアドレスを追加する必要があります。

    #OCI public IP two node RAC server details
192.0.2.1 ocidb1
192.0.2.2 ocidb2
#OCIC public IP two node RAC server details
192.0.2.3 ocicdb1
192.0.2.4 ocicdb2
  5. ソースおよびターゲットのデータベース・サーバーのポート22がZero Downtime Migrationサービス・ホストからの着信接続要求を受け入れることを確認します。
  6. Zero Downtime Migrationサービス・ホストからすべてのソースおよびターゲットのデータベース・サーバーへの接続をテストします。
    zdmuser> ssh -i zdm_service_host_private_key_file_location user@source/target_database_server_name

    次に例を示します。 

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocidb1
zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocicdb1

    ノート:

    Zero Downtime Migrationの操作時のSSH接続では、Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバーの間に、パスフレーズの入力を必要としない非対話型の直接アクセスが必要です。

関連項目:

Zero Downtime Migrationのポートの要件

親トピック: 接続の前提条件の構成

SUDOアクセスの構成

場合によっては、ソースおよびターゲットのデータベース・サーバーでsudoを使用して操作を実行するための権限を特定のユーザーに付与する必要があります。

ソース・データベース・サーバーの場合:

  • ソース・データベース・サーバーにrootユーザーでアクセスする場合は、Sudo操作を構成する必要はありません。

  • SSHを介してソース・データベース・サーバーにアクセスする場合は、データベース・インストール・ユーザーおよびrootユーザーのパスワードを要求せずに実行されるようにSudo操作を構成します。

    たとえば、データベース・インストール・ユーザーがoracleの場合は、sudo su - oracleを実行します。

    rootユーザーの場合は、sudo su -を実行します。

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

  • ターゲット・データベース・サーバーはクラウド上にのみあるため、Sudo操作はすでに構成されています。それ以外の場合は、データベース・インストール・ユーザーおよびrootユーザーのパスワードを要求せずに実行されるようにすべてのSudo操作を構成します。

    たとえば、データベース・インストール・ユーザーがoracleの場合は、sudo su - oracleを実行します。

    rootユーザーの場合は、sudo su -を実行します。

たとえば、ログイン・ユーザーがopcの場合、opcユーザーに対してSudo操作を有効にできます。

親トピック: 接続の前提条件の構成

ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続の構成

ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続を構成するのに、SCANとSSHの2つのオプションがあります。

次のいずれかのオプションを使用して接続を構成します。

  • オプション1: SCANの使用
    このオプションを使用するには、ターゲットのSCANはソース・データベース・サーバーから解決可能である必要があり、ソースのSCANはターゲット・サーバーから解決可能である必要があります。
  • オプション2: SSHトンネルの設定
    ソース・データベース・サーバーとターゲット・データベース・サーバー間でSCANおよびSCANポートを使用した接続ができない場合は、ソース・データベース・サーバーからターゲット・データベース・サーバーへのSSHトンネルを設定します。

親トピック: 接続の前提条件の構成

オプション1: SCANの使用

このオプションを使用するには、ターゲットのSCANはソース・データベース・サーバーから解決可能である必要があり、ソースのSCANはターゲット・サーバーから解決可能である必要があります。

ZDMCLI MIGRATE DATABASEコマンドの-sourcenodeパラメータに指定したソース・データベース・サーバーは、それぞれのSCANポートを介してターゲットSCANでターゲット・データベース・インスタンスに接続できます。逆も同様です。

両側からのSCAN接続により、ソース・データベースとターゲット・データベースはどちらの方向からも同期できます。ソース・データベース・サーバーのSCANがターゲット・データベース・サーバーから解決できない場合は、レスポンス・ファイルでSKIP_FALLBACKパラメータをTRUEに設定する必要があり、スイッチオーバー後はターゲット・データベースとソース・データベース間で同期をとることができません。

接続のテスト

ソース環境からターゲット環境への接続をテストするには、ターゲット・データベースのTNSエントリをソース・データベース・サーバーの$ORACLE_HOME/network/admin/tnsnames.oraファイルに追加します。 

[oracle@sourcedb ~] tnsping target-tns-string

ターゲット環境からソース環境への接続をテストするには、ソース・データベースのTNSエントリをターゲット・データベース・サーバーの$ORACLE_HOME/network/admin/tnsnames.oraファイルに追加します。 

[oracle@targetdb ~] tnsping source-tns-string

ノート:

Zero Data Loss Recovery Applianceを使用してExadata Cloud at Customerにデータベースを移行するには、ターゲット・データベース・サーバーからソース・データベース・サーバーへの必須のSQL*Net接続が必要です。
オプション2: SSHトンネルの設定

ソース・データベース・サーバーとターゲット・データベース・サーバー間でSCANおよびSCANポートを使用した接続ができない場合は、ソース・データベース・サーバーからターゲット・データベース・サーバーへのSSHトンネルを設定します。

次の手順では、rootユーザーに対してソース・データベース・サーバーでSSHトンネルを設定します。この手順は、一時チャネルと見なされるものを設定することになります。この接続オプションを使用すると、スイッチオーバー後にターゲット・データベースとソース・データベース間で同期できなくなり、この構成では元のソース・データベースに戻すことができません。

注意:

次の手順は、Oracle Cloud Infrastructureに言及していますが、Exadata Cloud at CustomerおよびExadata Cloud Serviceにも適用できます。
  1. パスフレーズなしのSSH鍵の生成の情報を使用して、ターゲットのOracle Cloud Infrastructureサーバーでopcユーザー用にパスフレーズなしのSSH鍵ファイルを生成します。ターゲットがOracle RACデータベースである場合は、最初のOracle RACサーバーからパスフレーズなしでSSH鍵ファイルを生成します。
  2. Oracle Cloud Infrastructureサーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容をOracle Cloud Infrastructure server opc_user_home/.ssh/authorized_keysファイルに追加します。
  3. ターゲットのOracle Cloud Infrastructureサーバーの秘密SSH鍵ファイルをソース・サーバーの/root/.ssh/ディレクトリにコピーします。ソースがOracle RACデータベースである場合は、ファイルをすべてのソース・サーバーにコピーします。
    管理しやすくするために、秘密SSH鍵ファイルの名前はターゲット・サーバー名と同じままにし、.ppk拡張子を付けたままにしておきます。たとえば、ocidb1.ppk (ocidb1はターゲット・サーバー名)とします。

    ファイルの権限は次のようになります。

    /root/.ssh>ls -l ocidb1.ppk
-rw------- 1 root root 1679 Oct 16 10:05 ocidb1.ppk
  4. ソース・サーバーの/root/.ssh/configファイルに次のエントリを挿入します。
    Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host OCI_server_name   
  HostName OCI_server_IP_address
  IdentityFile Private_key_file_location 
  User OCI_user_login  
  ProxyCommand /usr/bin/nc -X connect -x proxy_name:proxy_port %h %p

    説明

    • OCI_server_nameは、ドメイン名なしのOracle Cloud Infrastructureターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。
    • OCI_server_IP_addressは、Oracle Cloud Infrastructureターゲット・データベース・サーバーのIPアドレスです。Oracle RACデータベースの場合は、最初のOracle RACサーバーのIPアドレスを使用します。
    • Private_key_file_locationは、ソース・データベース・サーバー上の秘密鍵ファイルの場所で、これは前述のステップ3でターゲット・データベース・サーバーからコピーしたファイルです。
    • OCI_user_loginは、ターゲット・データベース・サーバーへのアクセスに使用されるOSユーザーです。
    • proxy_nameは、プロキシ・サーバーのホスト名です。
    • proxy_portは、プロキシ・サーバーのポートです。

    プロキシ設定は、プロキシ・サーバーを接続に使用しない場合には不要になることもあります。たとえば、ソース・データベース・サーバーがOracle Cloud Infrastructure Classic上にある場合、ProxyCommandで始まる行を削除したり、コメントにすることができます。

    たとえば、関係のある値を指定した後の/root/.ssh/configファイルは次のようになります。

    Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host ocidb1
  HostName 192.0.2.1
  IdentityFile /root/.ssh/ocidb1.ppk
  User opc
  ProxyCommand /usr/bin/nc -X connect -x www-proxy.example.com:80 %h %p

    ファイルの権限は次のようになります。

    /root/.ssh>ls -l config
-rw------- 1 root root 1679 Oct 16 10:05 config

    前述の例では、Oracle Cloud Infrastructureサーバー名はocidb1であり、Oracle Cloud InfrastructureサーバーのパブリックIPアドレスは192.0.2.1です。

    ソースがOracle Cloud Infrastructure Classicサーバーである場合、proxy_nameは必要ないため、ProxyCommandで始まる行を削除したり、コメントにすることができます。

    ソースがOracle RACデータベースである場合は、同じ/root/.ssh/configファイルをすべてのソースOracle RACデータベース・サーバーにコピーします。このファイルには、Oracle Cloud Infrastructureサーバー名、Oracle Cloud InfrastructureサーバーのパブリックIPアドレスおよび最初のOracle Cloud Infrastructure Oracle RACサーバーの秘密鍵ファイルの場所といった情報が構成されます。

  5. 最初のターゲットOracle Cloud Infrastructureサーバーにソース・サーバーからSSHできることを確認してから、SSHトンネルを有効にします。
    Oracle RACデータベースの場合は、すべてのソース・サーバーから最初のターゲットOracle Cloud Interfaceサーバーへの接続をテストします。

    秘密鍵を使用して、次のようにします。

    [root@ocicdb1 ~] ssh -i /root/.ssh/ocidb1.ppk opc@ocidb1
Last login: Fri Dec  7 14:53:09 2018 from 192.0.2.3

[opc@ocidb1 ~]$

    注意:

    SSH接続には、ソース・データベース・サーバーとターゲット・データベース・サーバー間に、パスフレーズの入力を必要としない非対話型の直接アクセスが必要です。
  6. ソース・サーバーで次のコマンドを実行してSSHトンネルを有効にします。
    ssh -f OCI_hostname_without_domain_name -L ssh_tunnel_port_number:OCI_server_IP_address:OCI_server_listener_port -N

    説明

    • OCI_hostname_without_domain_nameは、ドメイン名なしのOracle Cloud Infrastructureターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。
    • ssh_tunnel_port_numberは、1024-65545の範囲の使用できる一時的なポートです。SSHトンネル・ポートは、サーバーの他のプロセスで使用されていないことを確認してから使用します。
    • OCI_server_listener_portはターゲット・データベースのリスナー・ポート番号です。リスナー・ポートは、ソース・データベース・サーバーとOracle Cloud Infrastructureターゲット・サーバー間でオープンされている必要があります。
    • OCI_server_IP_addressは、ターゲット・データベース・サーバーのIPアドレスです。シングル・インスタンス・データベースの場合は、Oracle Cloud InfrastructureサーバーのIPアドレスを指定します。Oracle RACデータベースの場合は、Oracle Cloud InfrastructureのSCAN名をドメイン名付きで指定します。ドメイン名付きのSCAN名が解決できない場合や機能しない場合は、lsnrctl statusコマンド出力を使用して取得したIPアドレスを指定します。次に例を示します。
      Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.9)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.10)(PORT=1521)))

    次に、SSHトンネルを有効にするために実行するコマンドの例を示します。

    [root@ocicdb1~]ssh -f ocidb1 -L 9000:192.0.2.9:1521 -N

    Oracle RACデータベースの場合は、すべてのソース・サーバーについてこのステップを繰り返す必要があります。

  7. SSHトンネルをテストします。
    ソース・サーバーにログインし、oracleユーザーに切り替えてデータベース環境をソースとして参照し、次のコマンドを実行します。 
    tnsping localhost:ssh_tunnel_port

    次に例を示します。 

    [oracle@ocicdb1 ~] tnsping localhost:9000

    コマンド出力は、次のようになります。

    TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 22-JAN-2019 05:41:57
Copyright (c) 1997, 2014, Oracle.  All rights reserved.
Used parameter files:
Used HOSTNAME adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=9000)))
OK (50 msec)

    tnspingが機能しない場合、SSHが有効になっていません。

    Oracle RACの場合は、すべてのソース・サーバーについてこのステップを繰り返す必要があります。

パスフレーズなしのSSH鍵の生成

Zero Downtime Migrationサービス・ホストで、Zero Downtime Migrationソフトウェア・インストール・ユーザーに認証鍵ペアがパスフレーズなしで使用できない場合は、パスフレーズなしで新しいSSH鍵を生成できます。

ノート:

現在、SSH接続の構成ではRSA鍵形式のみがサポートされているため、ssh-keygenコマンドを使用して、両方の認証鍵ペア(公開と秘密)を生成します。

次の例は、Zero Downtime Migrationソフトウェア・インストール・ユーザーのSSH鍵ペアを生成する方法を示しています。このコマンドを使用して、opcユーザーのSSH鍵ペアを生成することもできます。

Zero Downtime Migrationサービス・ホストで次のコマンドを実行します。

zdmuser> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zdmuser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zdmuser/.ssh/id_rsa.
Your public key has been saved in /home/zdmuser/.ssh/id_rsa.pub.
The key fingerprint is:
c7:ed:fa:2c:5b:bb:91:4b:73:93:c1:33:3f:23:3b:30 zdmuser@zdm_service_host
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         . . .   |
|        S o . =  |
|         . E . * |
|            X.+o.|
|          .= Bo.o|
|          o+*o.  |
+-----------------+

このコマンドにより、id_rsaファイルおよびid_rsa.pubファイルがzdmuserホーム(/home/zdmuser/.sshなど)に生成されます。

親トピック: 接続の前提条件の構成

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

移行のためにソースおよびターゲットのデータベースを準備する方法の詳細は、次の各トピックを参照してください。

親トピック: データベース移行の準備

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

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

  • ソース・データベースはアーカイブ・ログ・モードで稼働している必要があります。

  • 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/snapcf_matrix.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)を使用する必要があります。

  • ソース・データベースには、$ORACLE_HOME/dbs/orapwORACLE_SIDにあるパスワード・ファイルが必要です。ない場合は、ORAPWDユーティリティを使用して作成します。

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

    RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

関連項目:

透過的データ暗号化ウォレットの設定

Zero Downtime Migrationのポートの要件

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

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

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

  • データベースの移行を開始する前に、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である場合など)は、データベースの移行後に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がオープンされており、ファイアウォールによってブロックされていないことを確認します。

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

    RMAN> show all;

関連項目:

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レスポンス・ファイル・パラメータのリファレンスで説明されている追加パラメータを参照してください。

親トピック: データベース移行の準備

Oracle Cloud Infrastructureへの移行用のレスポンス・ファイル設定

Oracle Cloud Infrastructure仮想マシンまたはベア・メタル・ターゲットにデータを移行するには、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

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

    SQL> show parameter db_unique_name

  • PLATFORM_TYPEをVMDBに設定します。

  • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。

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

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

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

  • 移行ログを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)を参照してください。

  • 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=number of daysを設定します。

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

  • Oracle Cloud Object Storageにアクセスするには、レスポンス・ファイルに次のパラメータを設定します。

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

親トピック: レスポンス・ファイルの準備

Exadata Cloud Serviceへの移行用のレスポンス・ファイル設定

Exadata Cloud Serviceターゲットにデータを移行するには、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

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

    SQL> show parameter db_unique_name

  • PLATFORM_TYPEをEXACSに設定します。

  • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。

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

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

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

  • 移行ログを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)を参照してください。

  • 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=number of daysを設定します。

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

  • Oracle Cloud Object Storageにアクセスするには、レスポンス・ファイルに次のパラメータを設定します。

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

親トピック: レスポンス・ファイルの準備

Zero Data Loss Recovery Applianceバックアップを使用するExadata Cloud at Customer用のレスポンス・ファイル設定

Zero Data Loss Recovery Applianceをバックアップ・メディアとして使用してExadata Cloud at Customerターゲットにデータを移行するには、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

  • 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をEXACCに設定します。

  • MIGRATION_METHODをDG_ZDLRAに設定します(DGはData Guardの略、ZDLRAはZero Data Loss Recovery Applianceの略です)。

  • Zero Data Loss Recovery Applianceに存在するバックアップを使用するように、次のZero Data Loss Recovery Applianceのパラメータを設定します。

    • 次のように、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

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

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

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

    ZDM_CLONE_TGT_MONITORING_INTERVAL=

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

親トピック: レスポンス・ファイルの準備

Object Storageバックアップを使用するExadata Cloud at Customer用のレスポンス・ファイル設定

Oracle Cloud Infrastructure Object Storageサービスをバックアップ・メディアとして使用してExadata Cloud at Customerターゲットにデータを移行するには、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

  • 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をEXACCに設定します。

  • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。

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

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

  • 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=number of daysを設定します。

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

  • Oracle Cloud Object Storageにアクセスするには、レスポンス・ファイルに次のパラメータを設定します。

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

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

親トピック: レスポンス・ファイルの準備

NFSバックアップを使用するExadata Cloud at Customer用のレスポンス・ファイル設定

NFSストレージをバックアップ・メディアとして使用してExadata Cloud at Customerターゲットにデータを移行するには、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

  • 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をEXACCに設定します。

  • MIGRATION_METHODをDG_SHAREDPATHまたはDG_EXTBACKUPに設定します(DGはData Guardの略です)。

    DG_STORAGEPATHは、新しいバックアップを作成して、外部ストレージ・マウント(NFSマウント・ポイントなど)に配置する場合に使用します。

    すでに外部共有マウント(NFSストレージ)に配置されている既存のバックアップを使用する場合は、DG_EXTBACKUPを使用します。

    MIGRATION_METHODをDG_EXTBACKUPに設定した場合、Zero Downtime Migrationでは新しいバックアップが実行されません。

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

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

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

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

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

  • DG_EXTBACKUPをMIGRATION_METHODとして使用する場合は、スタンバイ制御ファイルのバックアップを指定のパスに作成し、バックアップ・ピースに対する読取り権限をターゲット・データベース・ユーザーに付与する必要があります。次に例を示します。 

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

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

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

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

  • 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=number of daysを設定します。

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

親トピック: レスポンス・ファイルの準備

オフライン移行(バックアップおよびリカバリ)用のレスポンス・ファイル設定

データベースをOracle Cloud Infrastructure、Exadata Cloud at CustomerまたはExadata Cloud Serviceのターゲット環境にオフラインで移行する前に、次のレスポンス・ファイル設定を構成します。

レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。

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

    SQL> show parameter db_unique_name

  • ターゲット環境に応じて、PLATFORM_TYPEを適切な値に設定ます。

    • Oracle Cloud Infrastructureの場合は、PLATFORM_TYPE=VMDBを設定します。
    • Exadata Cloud at Customerの場合は、PLATFORM_TYPE=EXACCを設定します。
    • Exadata Cloud Serviceの場合は、PLATFORM_TYPE=EXACSを設定します。

  • Object Storageサービスをバックアップ・メディアに使用する場合は、MIGRATION_METHODをBACKUP_RESTORE_OSSに設定します。

    Exadata Cloud at Customerプラットフォームでは、NFSバックアップ・メディアを使用することもできます。その場合は、MIGRATION_METHODをBACKUP_RESTORE_NFSに設定し、Oracle Cloud Object Storageのパラメータ設定を無視します。

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

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

  • ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがJan 2020 PSU/BPであり、ターゲット・データベースがApril 2020 PSU/BPである場合など)は、TGT_SKIP_DATAPATCH=FALSEパラメータを使用してdatapatchユーティリティを実行し、移行後のタスクの一環としてターゲット・データベースにデータベース・パッチを適用します。それ以外の場合は、移行後にdatapatchユーティリティを手動で実行する必要があります。

  • 移行ログを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)を参照してください。

  • 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=number of daysを設定します。

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

  • Oracle Cloud Object Storageにアクセスするには、レスポンス・ファイルに次のパラメータを設定します。

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

親トピック: レスポンス・ファイルの準備

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

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

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

(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

関連項目:

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

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

親トピック: データベース移行の準備

移行ジョブのカスタマイズ

移行ジョブに含まれる操作フェーズの一環として実行するために、アクション・スクリプトまたはアクション・プラグインをアクション前またはアクション後として登録すると、Zero Downtime Migrationワークフローをカスタマイズできます。

次の各トピックでは、移行ジョブをカスタマイズする方法について説明します。

親トピック: データベース移行の準備

アクション・プラグインの登録

カスタム・プラグインは、特定の操作フェーズのためのカスタマイズとしてプラグインするために、Zero Downtime Migrationサービス・ホストに登録する必要があります。

特定のプラグインを関連付ける必要がある操作フェーズを決定し、-optype MIGRATE_DATABASEと操作の各フェーズ、プラグインがそのフェーズと比較して-preまたは-postのどちらで実行されるか、エラー時の要件を指定して、ZDMCLIコマンドADD USERACTIONを実行します。カスタム・プラグインは、移行ジョブ・ワークフローのZDM_SETUP_TGTの後の操作フェーズに登録できます。

ユーザー・アクションでエラーが発生した場合の実行時の処理は、-onerrorオプションを使用して指定できます。このオプションは、ABORT (処理を終了する場合)またはCONTINUE (エラー状態のカスタム・プラグインが存在していても移行ジョブを続行する場合)のいずれかに設定できます。コマンドの使用例は次を参照してください。

Zero Downtime Migrationソフトウェア・インストール・ユーザー(zmduserなど)を使用してデータベース移行ジョブにユーザー・アクションを追加します。ADD USERACTIONコマンドを使用したユーザー・アクションzdmvaltgtおよびzdmvalsrcの追加は、次のようになります。 

zdmuser> $ZDM_HOME/bin/zdmcli add useraction -useraction zdmvaltgt -optype MIGRATE_DATABASE 
-phase ZDM_VALIDATE_TGT -pre -onerror ABORT -actionscript /home/zdmuser/useract.sh

zdmuser> $ZDM_HOME/bin/zdmcli add useraction -useraction zdmvalsrc -optype MIGRATE_DATABASE 
-phase ZDM_VALIDATE_SRC -pre -onerror CONTINUE -actionscript /home/zdmuser/useract1.sh

前述のコマンドでは、-actionscriptオプションに指定されているスクリプトuseract.shおよびuseract1.shがZero Downtime Migrationサービス・ホストのリポジトリにコピーされ、アクション・テンプレートを使用して実行される任意の移行ジョブに関連付けられている場合に実行されます。

親トピック: 移行ジョブのカスタマイズ

アクション・テンプレートの作成

ユーザーアクション・プラグインを登録したら、移行ジョブに関連付けることができる一連のアクション・プラグインをまとめるアクション・テンプレートを作成します。

アクション・テンプレートは、ZDMCLIコマンドadd imagetypeを使用して作成します(イメージ・タイプimagetypeは、特定のタイプのデータベース移行に必要なすべてのユーザーアクションをまとめたものです)。データベースの移行に必要なすべてのユーザーアクション・プラグインを関連付けるイメージ・タイプを作成します。作成したイメージ・タイプは、同じプラグイン・セットを必要とするすべての移行操作で再利用できます。

ここで作成するイメージ・タイプの基本タイプは、次の例に示すようにCUSTOM_PLUGINである必要があります。

たとえば、前述の例で作成したユーザーアクションzdmvalsrcとzdmvaltgtの両方をまとめるイメージ・タイプACTION_ZDMを作成できます。 

zdmuser> $ZDM_HOME/bin/zdmcli add imagetype -imagetype ACTION_ZDM -basetype 
CUSTOM_PLUGIN -useractions zdmvalsrc,zdmvaltgt

親トピック: 移行ジョブのカスタマイズ

アクション・プラグインの更新

Zero Downtime Migrationサービス・ホストに登録されたアクション・プラグインを更新できます。

次の例では、ユーザーアクションzdmvalsrcを変更して-preアクションのかわりに、-postアクションにする方法を示します。 

zdmuser> $ZDM_HOME/bin/zdmcli modify useraction -useraction zdmvalsrc -phase ZDM_VALIDATE_SRC
 -optype MIGRATE_DATABASE -post

この変更は、すべての関連するアクション・テンプレートに伝播されるため、アクション・テンプレートを更新する必要はありません。

親トピック: 移行ジョブのカスタマイズ

移行ジョブとのアクション・テンプレートの関連付け

移行ジョブを実行する際、移行ジョブの一環として実行するプラグインを指定するイメージ・タイプを指定できます。

例として、前述の例で作成したアクション・テンプレートACTION_ZDMを指定して(-imagetype ACTION_ZDM)移行コマンドを実行すると、イメージ・タイプが組み込まれて移行ジョブ・ワークフローの一環としてuseract.shスクリプトおよびuseract1.shスクリプトが実行されます。

デフォルトでは、アクション・プラグインは、クラスタのすべてのノードの指定された操作フェーズで実行されます。移行コマンド・オプション-tgtarg2で指定されたアクセス資格証明が指定のターゲット・ノードに対して一意である場合、追加のauth引数を組み込んで、他のクラスタ・ノードへのアクセスに必要な認証資格証明を指定する必要があります。たとえば、-tgtarg2 nataddrfile:auth_file_with_node_and_identity_file_mappingと指定します。

node1およびnode2で構成される2クラスタ・ノード用の一般的なnataddrfileを次に示します。

node1:node1:identity_file_path_available_on_zdmservice_node 
node2:node2:identity_file_path_available_on_zdmservice_node

親トピック: 移行ジョブのカスタマイズ