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

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

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

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

  • 物理データベース移行の準備
  • 論理移行の準備
    次の各トピックでは、論理移行ジョブを実行する前にZero Downtime Migrationの前提条件を構成する方法について説明します。
  • 断続的なネットワーク障害に対するレジリエンシの構成
    Zero Downtime Migrationは、バックアップまたはSSH接続の失敗の原因となる可能性のある断続的なネットワーク障害に対して回復力があります。
  • 要塞ホストを使用したデータベース・サーバーの接続
    Zero Downtime Migrationでは、物理移行ワークフローと論理移行ワークフローの両方の要塞ホストを介して、ソースおよびターゲットのデータベース・サーバーへの接続を構成できます。
  • 自動アプリケーション・スイッチオーバーの準備
    データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。
  • 移行ジョブのカスタマイズ
    指定した移行ジョブ・フェーズの最初または最後に実行できるスクリプトを使用して、Zero Downtime Migrationワークフローをカスタマイズできます。Zero Downtime Migrationでは、これらのカスタマイズはユーザー・アクションを含むカスタム・プラグインと呼ばれます。

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

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

  • 接続の前提条件の構成
    Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。
  • ソース・データベースおよびターゲット・データベースの準備
    移行ジョブを構成する前に、ソース・データベースとターゲット・データベースで完了しておく必要があるタスクがいくつかあります。
  • 物理移行レスポンス・ファイルの準備
    必要な物理移行レスポンス・ファイル・パラメータを設定します。データベース移行プロシージャのZero Downtime Migrationレスポンス・ファイルの作成に使用するレスポンス・ファイル・テンプレート$ZDM_HOME/rhp/zdm/template/zdm_template.rspを取得し、ここで説明するようにファイルを編集します。
  • オンプレミス・データベースのオンプレミスExadata Database Machineへの移行
    Zero Downtime Migrationを使用したオンプレミスExadata Database Machineターゲットへのオンプレミスの移行は、クラウド・ターゲットへの移行と同じように機能します。レスポンス・ファイルで、PLATFORM_TYPE=NON_CLOUDを設定して、移行ターゲットがオンプレミスであることを指定します。
  • 移行中の非CDBデータベースのCDBへの変換
    物理移行プロセスの一環として、Zero Downtime Migrationは非CDBソース・データベースからクラウド内の同じバージョンのPDBへの変換を処理できます。変換プロセスでは、ソース非CDBをターゲットPDBに変換してから、ターゲットの既存のCDBにプラグインします。

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

接続の前提条件の構成

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

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

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

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

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

  1. Zero Downtime Migrationサービス・ホストで、Zero Downtime Migrationソフトウェア・インストール・ユーザーにRSA認証キー・ペアがパスフレーズなしで使用できることを確認します。
    新しいキー・ペアをパスフレーズなしで生成する必要がある場合は、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クラウド・ユーザーですが、sudo権限を持つ任意の特権ユーザーを使用できます。ソース・データベースとターゲット・データベースに異なるユーザーを使用することもできます。

  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

    オプションで、Zero Downtime Migrationでは、論理移行と物理移行の両方で要塞ホストを介した接続ができます。

  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サービス・ホストとソースおよびターゲットのデータベース・サーバーの間に、パスフレーズの入力を必要としない非対話型の直接アクセスが必要です。
  7. TTYを無効にして、SSH特権ユーザーに対して無効になっていることを確認します。

    Zero Downtime Migrationがリモート・ホストで非対話形式でコマンドを実行できるように、TTYをオフにする必要があります。

    sudo権限を設定するには様々な方法があるため、zdmuserに対してTTYを無効にする多数の方法があります。たとえば、/etc/sudoersファイルで次のデフォルトを設定できます。 

    Defaults:zdmuser !requiretty

    次のコマンドを実行して、TTYが無効になっていることを確認します。

    
ssh -i zdm_service_host_private_key_file_location
 user@source_database/target_database_server_name
 "sudo_location_source/target_database /bin/sh -c date"

    TTYが無効になっている場合、前述のコマンドはエラーなしでリモート・ホストから日付を返します。

    SSHがTTYを必要とするように構成されている場合、出力には次のようなエラーが表示されます。

    

[opc@zdm-server ~]$ ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocidb1
 "/usr/bin/sudo /bin/sh -c date"

sudo: sorry, you must have a tty to run sudo
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を使用したSQL*Net接続とSSHの2つのオプションがあります。

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

オプション1: SCANを使用したSQL*Net接続

このオプションを使用するには、ターゲットの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プロセスを開始する前に、ソース・データベースで次の前提条件を満たします。

  • ソース・データベースは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プロセスを開始する前に、ターゲット・データベースで次の前提条件を満たす必要があります。

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

    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では、ソース・データベースのバックアップに使用されるメディアを指定します。有効な値は、MIGRATION_METHOD=ONLINE_PHYSICALまたはMIGRATION_METHOD=OFFLINE_PHYSICALのどちらであるかによって異なります。

MIGRATION_METHOD=ONLINE_PHYSICALの場合、次のいずれかのデータ転送方法の値を使用できます。

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

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

    Exadata Cloud at Customer (EXACC)に設定された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)に設定された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)に設定されたPLATFORM_TYPEでサポートされます

    また、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が作成され、このディレクトリにバックアップ・ピースが格納されます。

MIGRATION_METHOD=OFFLINE_PHYSICALの場合、次のいずれかのデータ転送方法の値を使用できます。

  • OSS - Object Storageサービスを介したバックアップおよびリストアを使用した移行。Oracle Cloud Infrastructure (VMDB)、Exadata Cloud Service (EXACS)およびExadata Cloud at Customer (EXACC)でサポートされています。ソースとターゲット間のSQL*Net接続は必要ありません。
  • NFS - NFSを介したバックアップおよびリストアを使用した移行。Exadata Cloud at Customer (EXACC)でサポートされています。ソースとターゲット間のSQL*Net接続は必要ありません。

追加のOracle Cloud Object Storage設定

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

TGT_SSH_TUNNEL_PORT

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

データおよびREDOの場所

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

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

オンプレミス・データベースのオンプレミス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でサポートされている任意の値に設定できます。クラウド移行の場合と同様に残りのパラメータを設定します。

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

移行中の非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  

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

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

論理移行の準備

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

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

論理移行の前提条件

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

  • OCI APIキー・ペアを作成します。詳細は、必要な鍵とOCIDを参照してください。

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

  • ソース・データベース・リスナーが自己署名付きデータベース・サーバー証明書を使用して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

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

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

  • オンライン移行の場合は、次の手順を実行します。

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

    • ターゲット・データベースがSSL/TLSを使用するように構成されている場合は、TLS認証用の証明書を含むウォレットが次のようにGoldenGateインスタンスの正しい場所にあることを確認します。

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

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

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

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

    • ソース・データベースの前提条件を完了します。論理移行のためのソース・データベースの準備を参照してください

    • ターゲット・データベースで、次を実行します。

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

      ターゲットがAutonomous Databaseでない場合は、ターゲットPDBでggadminユーザーを作成します。このユーザーの作成の詳細は、論理移行のためのソース・データベースの準備を参照してください。

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

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

    接続 ソース 接続先
    SQL*Net GoldenGateハブ ソース・データベース
    SQL*Net GoldenGateハブ ターゲット・データベース
    SQL*Net ZDMサーバー ソース・データベース
    SSH ZDMサーバー ソース・データベース・サーバー
    SQL*Net ZDMサーバー ターゲット・データベース
    HTTPS ZDMサーバー1 GoldenGateハブ

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

    詳細は、「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で構成されていないソースへのデータベース・リンクは許可されません。

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

  • ソースが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.200414には、Oracle GoldenGateパフォーマンス・バグ28849751 - IE PERFORMANCE DEGRADES WHEN NETWORK LATENCY BETWEEN EXTRACT AND CAPTURE IS MORE THAN 8MSの修正が含まれています

    • OGG RDBMSパッチ31704157 MERGE REQUEST ON TOP OF DATABASE PSU 11.2.0.4.200414 FOR BUGS 31182000 20448066 - このパッチは、Oracle GoldenGate Microservicesバグ20448066 DBMS_XSTREAM_GG APIS SHOULD BE ALLOWED FOR SCA PROCESSESの必須の修正と必須のOGG RDBMSパッチ31182000 MERGE REQUEST ON TOP OF DATABASE PSU 11.2.0.4.200414 FOR BUGS 2990912 12668795を組み合せたものです。

      MOSノート1557031.1にOGGパッチ31177512が記載されていますが、バグ20448066のパッチと競合しています。そのため、OGGパッチ31177512のかわりにOGGパッチ31704157を使用する必要があります。

  • ソースが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パッケージをインストールします。

    UTL_RPADVパッケージを使用したXStream統計の収集を参照してください。Oracle Database 19cでは、パッケージの名前がUTL_SPADVからUTL_RPADVに変更されています。

  • 例にリストされているすべての権限を付与して、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> grant connect, resource to c##ggadmin;
SQL> grant unlimited tablespace to c##ggadmin;
SQL> alter user c##ggadmin quota 100M ON USERS;
SQL> grant select any dictionary to c##ggadmin;
SQL> grant create view to c##ggadmin;
SQL> grant execute on dbms_lock to c##ggadmin;
SQL> exec dbms_goldengate_auth.GRANT_ADMIN_PRIVILEGE('c##ggadmin',container=>'all');

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

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

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

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

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

親トピック: 論理移行の準備

論理移行レスポンス・ファイルの準備

必要な論理移行レスポンス・ファイル・パラメータを設定します。データベース移行プロシージャの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に設定します。

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

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

  • 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の場合です。

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

    • 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も参照してください

  • 次の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論理移行レスポンス・ファイル・パラメータのリファレンスを参照してください。

Oracle Data Pump設定

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

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

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

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

親トピック: 論理移行の準備

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

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

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

  • OSS: Oracle Cloud Object Storage

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

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

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

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

    Autonomous Database共有(データ・ウェアハウスまたはトランザクション処理)および共同管理ターゲットへのオンラインおよびオフラインの移行でのみサポートされます。

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

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

ノート:

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

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

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

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

このオプションは、オンプレミスのExadata Database Machineおよび共同管理クラウド・ターゲット・データベースにのみ適用されます。

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

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

Autonomous Database共有(データ・ウェアハウスまたはトランザクション処理)および共同管理ターゲットへのオンラインおよびオフラインの移行でのみサポートされます。

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

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

NFS転送メディアの使用

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

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

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

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

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

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は、バックアップまたは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

論理移行のレジリエンシ

データ・ポンプ・ダンプの転送中に発生する断続的なネットワーク障害は、DUMPTRANSFERDETAILS_RETRYCOUNTパラメータを設定することで軽減できます。デフォルト値は3です。

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

要塞ホストを使用したデータベース・サーバー接続

Zero Downtime Migrationでは、物理移行ワークフローと論理移行ワークフローの両方について、要塞ホストを介してソースおよびターゲットのデータベース・サーバーへの接続を構成できます。

要塞ホストは、JDBC接続を除き、Autonomous Databaseへの接続には使用できません。

次の各項を参照して、要塞ホストを介してソースまたはターゲットのデータベース・サーバーに接続する必要がある物理および論理移行の適切なパラメータを構成します。

データベース・サーバーへのSSH接続

要塞ホストを介してデータベース・サーバーを接続するには、次の情報が必要です。

  • 要塞ホストのIPアドレスおよびソース・データベース・サーバーのIPアドレス: 要塞ホストを介してデータベース・サーバーに接続するには、要塞ホストのIPアドレスおよびソース・ノードのIPアドレスが必要です。

  • 要塞ポート番号: 指定しない場合、ポート番号は22にデフォルト設定されます。

  • 要塞ユーザー: 要塞ホストのユーザーは、引数zdmauthプラグインに指定したユーザーが要塞ホストのユーザーと異なる場合にのみ必要です。プロパティを指定しない場合、要塞ユーザーはソースzdmauthプラグインに指定したユーザーにデフォルト設定されます。

  • 要塞アイデンティティ・ファイル: SRC/TGT_BASTION_IDENTITY_FILEパラメータを指定しない場合、値はzdmauthプラグイン引数のidentity_file引数に指定した値にデフォルト設定されます。

物理移行レスポンス・ファイル・パラメータ

物理移行用に次のレスポンス・ファイル・パラメータを構成します。

ソース・データベース・サーバー

SRC_BASTION_HOST_IP=

SRC_BASTION_PORT=

SRC_BASTION_USER=

SRC_BASTION_IDENTITY_FILE=

SRC_HOST_IP=

ターゲット・データベース・サーバー

TGT_BASTION_HOST_IP=

TGT_BASTION_PORT=

TGT_BASTION_USER=

TGT_BASTION_IDENTITY_FILE=

TGT_HOST_IP=

論理移行レスポンス・ファイル・パラメータ

論理移行用に次のレスポンス・ファイル・パラメータを構成します。

ソース・データベース・サーバー

SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IP=

SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_PORT=22

SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IDENTITYFILE=

SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_USERNAME=

SOURCECONTAINERDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_REMOTEHOSTIP=

ターゲット・データベース・サーバー(Autonomous Databaseを含む)

TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IP=

TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_PORT=22

TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_IDENTITYFILE=

TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_USERNAME=

TARGETDATABASE_CONNECTIONDETAILS_BASTIONDETAILS_REMOTEHOSTIP=

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

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

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

ノート:

物理的な移行では、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ワークフローをカスタマイズできます。Zero Downtime Migrationでは、これらのカスタマイズはユーザー・アクションを含むカスタム・プラグインと呼ばれます。

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

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

ユーザー・アクションを含むカスタム・プラグインについて

Zero Downtime Migrationでは、プラグインして移行ジョブの一部として実行するカスタム・スクリプトまたはスクリプトのバンドルは、ユーザー・アクションを含むカスタム・プラグインと呼ばれます。

ユーザー・アクションを含むカスタム・プラグインは、ユーザー・アクションとも呼ばれ、移行ジョブの操作フェーズに関連付けて、フェーズの前または後に実行できます。

事前アクションは、関連付けられたフェーズの開始時に実行されるユーザー・アクションです。同様に、事後アクションは、関連付けられたフェーズの終了時に実行されます。

ユーザー・アクションが移行フェーズに関連付けられると、Zero Downtime Migrationはそれを各ノード(Autonomous Database以外の場合)にコピーし、ユーザー・アクションをローカルで実行します。Zero Downtime Migrationは、開発者がDBNAME、DBHOME、DB SCANおよびZDMログの場所を使用するための一連のパラメータと、その他の多数のパラメータをユーザー・アクション・スクリプトの実行に提供します。

Autonomous Databaseの場合、Zero Downtime Migrationを使用すると、SQLをユーザー・アクションとして登録し、JDBC接続を介してZero Downtime MigrationサーバーからAutonomous DatabaseインスタンスでSQLを実行できます。

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

ユーザー・アクションを含むカスタム・プラグインに提供されるパラメータ

Zero Downtime Migrationは、実行時にユーザー・アクション・スクリプトを起動し、ロジックのプログラミングに使用できる自動移入ENV変数のセットを提供します。

これらの変数はENV変数として値とともに提供されるため、これらの値を使用してカスタム・プラグインをプログラミングできます。

たとえば、ZDM_SRCDBHOMEの値は、現在の移行ジョブのソース・データベースに関連付けられたデータベース・ホームを指定し、同様にSRC_SCAN_NAMEは、データベースへの接続に使用できるソース・データベースのスキャン・リスナー情報を示します。

次に、ユーザー・アクション・パラメータと予想される値のリストを示します。詳細は、脚注を参照してください。

RHP_OPTYPE=MIGRATE_DATABASE
RHP_PHASE=PRE
ZDM_SRCDB=src_db_name
ZDM_SRCDBHOME=src_db_home
ZDM_TARGETDB=tgt_db_name
ZDM_TARGETDBHOME=tgt_db_home
RHP_PROGRESSLISTENERHOST=zdm_node_name
RHP_PROGRESSLISTENERPORT=zdm_progress_listener_port
LOG_PATH=src/tgt_zdm_log_path1
SRC_SCAN_NAME=src_scan_name
SRC_SCAN_PORT=src_scan_port
TGT_SCAN_NAME=tgt_scan_name
TGT_SCAN_PORT=tgt_scan_port
RHP_USERACTIONDATA=user_action_data2
RHP_OP_PHASE=current_job_phase3

1LOG_PATHは、将来の参照用にログ・ファイルを格納するカスタム・プラグインのソースまたはターゲット・ノードのZero Downtime Migrationログ・パスを指定します。

2RHP_USERACTIONDATAは、zdmcli migrate databaseコマンドのオプション-useractiondata user_action_dataで指定されたuseraction引数を指定します

3RHP_OP_PHASEは、移行ジョブの現在のフェーズを指定します(例: ZDM_VALIDATE_SRC)。

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

ユーザー・アクション・スクリプト

次のユーザー・アクション・スクリプトの例を使用して、独自のスクリプトを作成できます。

オンプレミス・ソースおよびノード・アクセスのあるクラウド・ターゲットの場合、Zero Downtime Migrationではユーザー・アクションがスクリプトである必要があります。スクリプト・ファイルがそれぞれのノードにコピーされ、ローカルで実行されます。

Autonomous Databaseターゲットの場合、Zero Downtime Migrationでは、ユーザー・アクション・スクリプトがSQLファイル(.sql)である必要があり、これはJDBC接続を使用してAutonomous Databaseターゲットで実行されます。

例3-1 action.sh

指定されたパラメータを検出するユーザー・アクション・スクリプトの例を次に示します。

    #!/bin/sh  

    for var in $@
    do
    if [[ ${var} == *"ZDM_SRCDB="* ]]
    then
    IFS='=' read -ra DBARR <<< "${var}"
    SRCDBNAME=${DBARR[1]}
    fi
    if [[ ${var} == *"ZDM_TARGETDB="* ]]
    then
    IFS='=' read -ra DBARR <<< "${var}"
    TARGETDBNAME=${DBARR[1]}
    fi
    if [[ $var == *"ZDM_SRCDBHOME="* ]]
    then
    IFS='=' read -ra PATHARR <<< "$var"
    SRCDBHOME=${PATHARR[1]}
    fi
    if [[ $var == *"ZDM_TARGETDBHOME="* ]]
    then
    IFS='=' read -ra PATHARR <<< "$var"
    TARGETDBHOME=${PATHARR[1]}
    fi
    if [[ $var == *"RHP_OP_PHASE="* ]]
    then
    IFS='=' read -ra PHASEARR <<< "$var"
    ZDMPHASE=${PHASEARR[1]}
    fi
    if [[ $var == *"eval"* ]]
    then
    IFS='=' read -ra PATHARR <<< "$var"
    EVALRUN=${PATHARR[1]}
    fi
    if [[ $var == *"LOG_PATH"* ]]
    then
    IFS='=' read -ra PATHARR <<< "$var"
    LOGPATH=${PATHARR[1]}
    fi
    done

    echo "`date` Starting CUSTOM_USERACTION" >> $LOG_PATH/CUSTOM_USERACTION.log
    echo $@ >> $LOG_PATH/CUSTOM_USERACTION.log

例3-2 ユーザー・アクションでのSQL*Plusの実行

#!/bin/sh  
 
for var in $@
do
if [[ ${var} == *"ZDM_SRCDB="* ]]
then
IFS='=' read -ra DBARR <<< "${var}"
SRCDBNAME=${DBARR[1]}
fi
if [[ ${var} == *"ZDM_TARGETDB="* ]]
then
IFS='=' read -ra DBARR <<< "${var}"
TARGETDBNAME=${DBARR[1]}
fi
if [[ $var == *"ZDM_SRCDBHOME="* ]]
then
IFS='=' read -ra PATHARR <<< "$var"
SRCDBHOME=${PATHARR[1]}
fi
if [[ $var == *"ZDM_TARGETDBHOME="* ]]
then
IFS='=' read -ra PATHARR <<< "$var"
TARGETDBHOME=${PATHARR[1]}
fi
if [[ $var == *"RHP_OP_PHASE="* ]]
then
IFS='=' read -ra PHASEARR <<< "$var"
ZDMPHASE=${PHASEARR[1]}
fi
if [[ $var == *"eval"* ]]
then
IFS='=' read -ra PATHARR <<< "$var"
EVALRUN=${PATHARR[1]}
fi
if [[ $var == *"LOG_PATH"* ]]
then
IFS='=' read -ra PATHARR <<< "$var"
LOGPATH=${PATHARR[1]}
fi
done
 
    check_dv_staus()
    {
        export ORACLE_HOME=${2}
        export PATH=$ORACLE_HOME/bin:$PATH
        export LOGFILE=$3
        export currenthostname=`hostname -a` >> $LOGFILE
        echo "Current DB Host=$currenthostname" >> $LOGFILE
        CURRENTNODE=`srvctl status database -db ${1} | grep $currenthostname | cut -d" " -f2` >> $LOGFILE
        SQLRETURN=$?
        echo "Curent DB Node=${CURRENTNODE}" >> $LOGFILE
        if [ "$SQLRETURN" -ne "0" ]; then
            return 1
        fi
        export ORACLE_SID=${CURRENTNODE}
        echo "`date` Checking Database Vault Status" >> $LOGFILE
        $ORACLE_HOME/bin/sqlplus -s / as sysdba 2>> $LOGFILE << EOF > /dev/null
        whenever sqlerror exit 1
        SET PAGESIZE 60
        SET LINESIZE 1300
        SET VERIFY OFF TRIMSPOOL ON  HEADING OFF  TERMOUT OFF  FEEDBACK OFF
        spool ${LOGFILE} append;
 
        SELECT 'Check Status : '||PARAMETER FROM V\$OPTION WHERE PARAMETER = 'Oracle Database Vault' AND VALUE='TRUE';
        SELECT 'Check Grant : '||GRANTED_ROLE from dba_role_privs where GRANTED_ROLE in ('DV_PATCH_ADMIN') and grantee='SYS';
        select distinct ('Check TDE enabled ' || ENCRYPTED) from dba_tablespaces where ENCRYPTED='YES';
        spool off
        EOF
        SQLRETURN=$?
        if [ "$SQLRETURN" -ne "0" ]; then
            return 1
        fi
 
        if grep -q "Check Status : Oracle Database Vault" $LOGFILE;
        then
            echo "`date`:$ORACLE_SID:Database Vault is enabled " >> $LOGFILE
        if grep -q "Check Grant : DV_PATCH_ADMIN" $LOGFILE;
        then
            return 3 # sys privs already granted
        else
            return 4 # sys privs are not granted
        fi
        else
            echo "`date`:$ORACLE_SID: DV is not enabled" >> $LOGFILE
        return 2
        fi
    }
 
if [[ $ZDMPHASE == "ZDM_VALIDATE_SRC" || $ZDMPHASE == "ZDM_VALIDATE_TGT" ]]
then
  export LOGFILE=$LOG_PATH/${SRCDBNAME}_${ZDMPHASE}_datavault.log
  echo "`date` Start User Action for Phase: $ZDMPHASE " > $LOGFILE
  echo $@ >> $LOGFILE
  check_dv_staus $SRCDBNAME $SRCDBHOME $LOGFILE
  CHECKDV_STATUS_RETURN_CODE=$?
  if [ "$CHECKDV_STATUS_RETURN_CODE" -eq "1" ]; then
  echo "`date`:${SRCDBNAME}:Unable to check DataVault status" >> $LOGFILE
  exit 1
  fi
 
  if [ "$CHECKDV_STATUS_RETURN_CODE" -eq "2" ]; then
    echo "`date`:${SRCDBNAME}:DataVault is not enabled " >> $LOGFILE
    exit 0
  fi
 
  if [ "$CHECKDV_STATUS_RETURN_CODE" -eq "3" ];
  then
     echo "`date`:${SRCDBNAME}:Database Vault SYS privileges granted" >> $LOGFILE
     exit 0
  fi

例3-3 アクション・ファイル・アーカイブ・エクストラクタaction_extract.sh

ユーザー・アクションの登録の説明に従って複数のユーザー・アクションをアクション・ファイルにバンドルする場合は、この例に示すように、アクション・ファイルを解凍するスクリプトも指定する必要があります。 

#!/bin/sh  
MKDIR=/bin/mkdir
DATE=/bin/date
UNZIP=/usr/bin/unzip
#get the current location, extract path from it and then from the same
directory perform unzip to /tmp directory
script_path=$0
script_dir=${script_path%/*}
timestamp=$($DATE +%s)
unzip_dir=/tmp/rhp_${timestamp}
$MKDIR $unzip_dir
$UNZIP ${script_dir}/pack.zip -d $unzip_dir

echo "/bin/sh ${unzip_dir}/pack/main.sh $@"
/bin/sh ${unzip_dir}/pack/main.sh  "$@"

アーカイブが抽出されると、action_extract.shによってmain.shが実行され、ユーザー・アクション・スクリプトが実行されます。

 #!/bin/sh  
script_path=$0
script_dir=${script_path%/*}
#extract args and execute all scripts
echo "/bin/sh ${script_dir}/wc_add_pre.sh $@"
/bin/sh ${script_dir}/wc_add_pre.sh  "$@"

action_phase_pre.sh

#!/bin/sh
touch /tmp/SAMPLE_PRE_OUT.txt;
echo $* >> /tmp/SAMPLE_PRE_OUT.txt;

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

ユーザー・アクションの登録

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

ZDMCLI add useractionコマンドは、ソース・サーバーまたはターゲット・サーバーで実行する必要があるカスタム・アクション・スクリプトを登録します。ユーザー・アクション・スクリプトはZero Downtime Migrationメタデータにコピーされます。スクリプトを変更する必要がある場合は、modify useractionコマンドを使用できます。アクション・スクリプトは、特定の移行ジョブの任意の数のカスタム・アクションに含めることができます。

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

カスタム・プラグインは、移行ジョブ・ワークフローのZDM_SETUP_TGTの後の操作フェーズに登録できます。

ユーザー・アクションで実行時にエラーが発生した場合、-onerrorオプションを使用して動作を指定できます。このオプションは、ABORTに設定してプロセスを終了するか、CONTINUEに設定して、カスタム・プラグインがエラーで終了した場合でも移行ジョブを続行できます。

Zero Downtime Migrationソフトウェア・インストール・ユーザー(zmduserなど)を使用してデータベース移行ジョブにユーザー・アクションを追加します。

次の例は、ユーザー・アクション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サービス・ホストのリポジトリ・メタデータにコピーされ、アクション・テンプレートを使用して実行される移行ジョブに関連付けられている場合に実行されます。

1つのアクションでの複数のスクリプトの実行

複数のスクリプトを単一の事前アクションまたは事後アクションとして実行する必要がある場合は、次の例に示すように、すべてのアクション・スクリプトをアクション・ファイル・アーカイブとしてバンドルし、アクション・スクリプトとともに指定できます。アクション・スクリプトは、アクション・ファイルを解凍し、その中のスクリプトを起動する必要があります。 

zdmuser> $ZDM_HOME/bin/zdmcli add useraction -useraction reconfigure_services   
 -optype MIGRATE_DATABASE -phase ZDM_RECOVER_TGT -post -onerror ABORT
 -actionscript /home/zdmuser/action_extract.sh
 -actionfile /home/zdmuser/pack.zip

スクリプトの例およびスクリプトの要件は、ユーザー・アクション・スクリプトを参照してください。

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

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

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

アクション・テンプレートは、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

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

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

アクション・プラグインの問合せ

Zero Downtime Migrationサービス・ホストに登録されたアクション・プラグインを問い合せることができます。

ユーザー・アクションの構成を表示するには:

zdmuser> $ZDM_HOME/bin/zdmcli query useraction -h

使用方法の詳細は、query useractionを参照してください。

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

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

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

例として、前述の例で作成したアクション・テンプレート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

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