1. Runbook: Oracle Cloud Serviceへのオンプレミス・データベースとOracle Cloud Infrastructure Classicインスタンスの移動
  2. データベース移行の準備

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

次の各トピックでは、データベース移行の準備方法について説明します。

3.1 Zero Downtime Migrationソフトウェアの設定

要件 説明 コメント
Zero Downtime Migrationソフトウェアの設定
  1. 既存のユーザーを使用するか、Zero Downtime Migrationサービス・ホストでrootユーザーとして、zdmグループを作成し、zdmuserユーザーをグループに追加します。

    次に例を示します。

    root> groupadd zdm

    root> useradd –g zdm zdmuser

    Zero Downtime Migrationの設定には、任意の非rootユーザーを使用できます。このドキュメントの例では、すべてのコマンドはzdmuserとして実行する場合を示しています。

  2. Zero Downtime Migrationソフトウェア・キットをhttps://www.oracle.com/database/technologies/rac/zdm-downloads.htmlからZero Downtime Migrationサービス・ホストにダウンロードします。
  3. ダウンロードに含まれるREADMEで必須パッケージについて調べて、該当するパッケージをインストールします。
  4. ディレクトリをZero Downtime Migrationソフトウェアのダウンロード先に変更します。

    zdmuser> cd zdm_download_directory

    Zero Downtime Migrationのインストール・スクリプトを実行します。

    zdmuser>./zdminstall.sh setup oraclehome=zdm_oracle_home oraclebase=zdm_base_directory ziploc=zdm_software_location –zdm

    zmdinstall.shは、インストール・スクリプトです。

    oraclehomeは、Zero Downtime MigrationキットをインストールするOracleホームです。

    oraclebaseは、すべてのZero Downtime Migrationの構成ファイル、ログおよびその他のアーティファクトが格納されるベース・ディレクトリです。

    ziplocは、Zero Downtime Migrationキットに含まれているソフトウェアの圧縮ファイル(ZIP)の場所です。

    たとえば、次のようにします。

    zdmuser>./zdminstall.sh setup oraclehome=/u01/app/zdmhome

    oraclebase=/u01/app/zdmbase ziploc=/u01/app/oracle/zdm/shiphome/zdm_home.zip -zdm

    今後、oraclehome値はZDM_HOMEと呼び、oraclebase値はZDM_BASEと呼びます。

  5. Zero Downtime Migrationサービスをユーザーzdmuserとして開始します。

    zdmuser> /u01/app/zdmhome/bin/zdmservice start

    Zero Downtime Migrationを使用してデータベースを移行するには、zdmserviceを開始する必要があります。

  6. Zero Downtime Migrationサービスを停止するには、次のコマンドを実行します。

    zdmuser> /u01/app/zdmhome/bin/zdmservice stop

  7. Zero Downtime Migrationサービスのインストールが正常に終了したことを確認します。

    次のコマンドを実行すると、出力は次に示すようなものになります。

    zdmuser> /u01/app/zdmhome/bin/zdmservice status

    ---------------------------------------

    Service Status

    ---------------------------------------

    Running: true

    Tranferport: 5000-7000

    Conn String: jdbc:derby:/u01/app/zdmbase/derbyRepo;create=true

    Repo Path: /u01/app/zdmbase/derbyRepo

    RMI port: 8895

    HTTP port: 8896

    Wallet path: /u01/app/zdmbase/crsdata/fopds/security

 インストールの最後に端末に表示される次のメッセージは無視します。これらのスクリプトを実行する必要はありません。

"As a root user, execute the following script(s):

  1. /u01/app/zdmhome/inventory/orainstRoot.sh
  2. /u01/app/zdmhome/root.sh"

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

3.2 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_name.ppkに変更します

  3. ZDM_installed_user_home/.ssh/id_rsa.pubファイルの内容をすべてのソースおよびターゲットのデータベース・サーバーのopc_user_home/.ssh/authorized_keysファイルに追加します。

    opcユーザーは、標準のOracle Cloudユーザーであり、Oracle Cloud Infrastructure ClassicおよびExadata Cloud Serviceデータベースへのアクセスに使用します。

  4. ソースおよびターゲットのデータベース・サーバーの名前とIPアドレスの詳細をZero Downtime Migrationサービス・ホストの/etc/hostsファイルに追加します。

    たとえば、次のようにします。

    #OCI-C public IP of two node RAC server details

    192.0.2.1 zdm122011

    192.0.2.2 zdm122012

    #OCI public IP of two node RAC server details

    192.0.2.3 ocitarget1

    192.0.2.4 ocitarget2

  5. ソースおよびターゲットのデータベース・サーバーのポート22がZero Downtime Migrationサービス・ホストからの着信接続要求を受け入れることを確認します。
  6. Zero Downtime Migrationサービス・ホストからすべてのソースおよびターゲットのデータベース・サーバーへの接続をテストします。

    zdmuser> ssh -i ZDM_service_node_private_key_file_location user@source/target_database_server_name

    たとえば、次のようにします。

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@zdm122011

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@zdm122012

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@ocitarget1

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@ocitarget2

注意1: ソース・データベース・サーバーにrootアクセスできる場合は、ソース・データベース・サーバーのSSH鍵による接続を構成する必要はありません。

注意2: SSH鍵による接続を構成する場合、Zero Downtime Migrationサービス・ホストは、秘密鍵ファイルを使用してパスワードの入力を求められることなく、ソースおよびターゲットのデータベース・サーバーに接続できるようにする必要があります。

注意3: ターゲット・サーバーへの接続のためにZero Downtime Migrationサービス・ホストがプロキシの詳細を必要とする場合は、SSH鍵とともに次の詳細でZDM_installed_user_home/.ssh/configを構成する必要もあります。それ以外の場合は、ZDM_installed_user_home/.ssh/configファイルを構成する必要はありません。

cat ZDM_installed_user_home/.ssh/config

Host *

ServerAliveInterval 10

ServerAliveCountMax 2

Host Target_server_name

HostName Target_server_IP_address

IdentityFile Private_key_file_location

User Target_user_login

ProxyCommand /usr/bin/nc --proxy proxy_url:port %h %p

次に例を示します。

Host *

ServerAliveInterval 10

ServerAliveCountMax 2

Host ocitarget1

HostName 192.0.2.3

IdentityFile /home/zdmuser/.ssh/zdm_service_host.ppk

User opc

ProxyCommand /usr/bin/nc --proxy www-proxy-example.com:80 %h %p

注意4: authorized_keysファイルの権限は、次に示すようになっている必要があります。

/home/opc/.ssh>ls -l authorized_keys

-rw------- 1 opc opc 1679 Oct 16 10:05 authorized_keys

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

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

要件 説明 コメント
ソースおよびターゲットのデータベース・サーバー間の接続の構成

2つのオプションのいずれかを使用して、ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続を構成できます。

オプション1

ZDMCLIコマンドの-sourcenodeパラメータで指定したソース・データベース・サーバーは、それぞれのSCANポートを通過するターゲットSCANによってターゲット・データベース・インスタンスに接続できます(その逆も同様です)。ターゲットのSCANはソース・データベース・サーバーから解決可能である必要があり、ソースのSCANはターゲット・サーバーから解決される必要があります。

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

「オプション1」の接続をテストするには、次のようにします。

  1. ソースからターゲット環境への接続をテストします。

    ターゲット・データベースのTNSエントリをソース・データベース・サーバーのtnsnames.oraファイルに追加します。

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

  2. ターゲットからソース環境への接続をテストします。

    ソース・データベースのTNSエントリをターゲット・データベース・サーバーのtnsnames.oraファイルに追加します。

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

オプション2

ソース・データベース・サーバーとターゲット・データベース・サーバー間でSCANおよびSCANポートを使用した接続ができない場合は、次の手順に従ってソース・データベース・サーバーからターゲット・データベース・サーバーへのSSHトンネルを設定します。このオプションを使用すると、ターゲット・データベースとソース・データベース間で同期をとることができません。

ソース・データベース・サーバーでrootユーザー用のSSHトンネルを設定するには、次のようにします。

  1. ターゲット・サーバーのopcユーザー用に、パスフレーズなしの秘密SSH鍵ファイルを生成します。

    「パスフレーズなしの秘密SSH鍵の生成」を参照してください。

    ターゲットがOracle RACデータベースである場合は、最初のOracle RACサーバーからパスフレーズなしで秘密SSH鍵ファイルを生成します。

  2. ターゲット・サーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容をソース・サーバーのopc_user_home/.ssh/authorized_keysファイルに追加します。

    ソースがOracle RACデータベースの場合は、ターゲット・サーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容をすべてのOracle RACソース・サーバーのopc_user_home/.ssh/authorized_keysファイルに追加します。

  3. ターゲット・サーバーの秘密SSH鍵ファイルをソース・サーバーの/root/.ssh/ディレクトリ内にコピーします。

    ソースがOracle RACデータベースである場合は、ファイルをすべてのソース・サーバーにコピーします。管理しやすくするために、秘密SSH鍵ファイルの名前はターゲット・サーバー名と同じままにし、.ppk拡張子を付けたままにしておきます。たとえば、exacstarget1.ppkのようにします(exacstarget1はターゲット・サーバーの名前)。

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

    /root/.ssh>ls -l exacstarget1t.ppk

    -rw------- 1 root root 1679 Oct 16 10:05 exacstarget1.ppk

  4. ソース・サーバーの/root/.ssh/configファイルに次のエントリを挿入します。

    Host *

    ServerAliveInterval 10

    ServerAliveCountMax 2

    Host Target_server_name

    HostName Target_server_IP_address

    IdentityFile Private_key_file_location

    User Target_user_login

    Target_server_nameは、ドメイン名なしのターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。

    Target_server_IP_addressは、ターゲット・データベース・サーバーのIPアドレスです。Oracle RACデータベースの場合は、最初のOracle RACサーバーのIPアドレスを使用します。

    Private_key_file_locationは、秘密鍵ファイルの場所です。

    Target_user_loginは、ターゲット・データベース・サーバーにアクセスするために使用するOSユーザーです。

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

    Host *

    ServerAliveInterval 10

    ServerAliveCountMax 2

    Host exacstarget1

    HostName 192.0.2.3

    IdentityFile ~/.ssh/exacstarget1.ppk

    User opc

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

    /root/.ssh>ls -l config

    -rw------- 1 root root 1679 Oct 16 10:05 config

    この例では、ターゲット・サーバーの名前はexacstarget1で、ターゲット・サーバーのパブリックIPアドレスは192.0.2.3です。

    ソースがOracle RACデータベースの場合は、同じ/root/.ssh/configファイルをすべてのソースOracle RACデータベース・サーバーにコピーします。

    ソース・サーバーから最初のターゲット・サーバーへのSSHが可能なことを確認してから、SSHトンネルを有効にします。

    Oracle RACデータベースの場合は、すべてのソース・サーバーから最初のターゲット・サーバーへの接続をテストします。

    秘密鍵ファイルを使用して接続をテストし、ソース・データベース・サーバーがパスワードの入力を求められることなくターゲット・データベース・サーバーに接続できることを確認します。

    [root@zdm122011 ~] ssh -i /root/.ssh/exacstarget1.ppk opc@exacstarget1

    [root@zdm122012 ~] ssh -i /root/.ssh/exacstarget1.ppk opc@exacstarget1

  5. ソース・サーバーで次のコマンドを実行してSSHトンネルを有効にします。

    ssh -f Target_hostname_without_domain_name -L \ ssh_tunnel_port_number:Target_server_IP_address: Target_server_listener_port -N

    Target_hostname_without_domain_nameは、ドメイン名なしのターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。

    ssh_tunnel_port_numberは、範囲内(1024-65545)で使用可能な一時ポートです。SSHトンネル・ポートは、サーバーの他のプロセスで使用されていないことを確認してから使用します。

    Target_server_listener_portは、ターゲット・データベースのリスナー・ポート番号です。このリスナー・ポートは、ソース・データベース・サーバーとターゲット・サーバーの間で開いている必要があります。

    Target_server_IP_addressは、データベース・アーキテクチャに基づいて構成します。単一インスタンス・データベースの場合は、ターゲット・サーバーのIPアドレスを指定します。Oracle RACデータベースの場合は、ドメイン名付きのターゲット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@zdm122011 ~]ssh -f exacstarget1 -L 9001:192.0.2.9:1521 -N

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

  6. 「オプション2」のSSHトンネルで接続をテストします。

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

    ソース・サーバーにログインして、oracleユーザーに切り替えてデータベース環境をソースとして参照し、次のコマンドを実行します。

    tnsping localhost:ssh_tunnel_port

    次に例を示します。

    [oracle@zdm122011 ~] tnsping localhost:9001

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

    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=9001)))

    OK (50 msec)

    tnspingが動作しない場合は、SSHトンネルが有効化されていません。

ソース・データベース・サーバーがパスワードの入力を求められることなくターゲット・データベース・サーバーに接続できることを確認してください。それ以外の場合は、ソースからターゲット側へのData Guard同期が実施できなくなります。

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

3.4 レスポンス・ファイル・テンプレートの準備

レスポンス・ファイル・テンプレートは、オンラインとオフラインのどちらで移行を実行するかに応じて準備します。

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

3.4.1 Oracle Cloud Infrastructureターゲットへのオンライン移行用レスポンス・ファイルの準備

要件 説明 コメント
オンライン移行用レスポンス・ファイルの準備

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次の設定を編集します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • MIGRATION_METHODをDG_OSSに設定します。DGは、Data Guardを表す略号です。また、OSSは、Object Storageサービスを表す略号です。
  • PLATFORM_TYPEをVMDBに設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • HOSTとOPC_CONTAINERには、Object StoreのURLとバケット名を設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSには、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSには、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
たとえば、レスポンス・ファイルを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、次に示すようにソースとターゲットに基づいて値を設定に追加します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=DG_OSS

PLATFORM_TYPE=VMDB

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_SSH_TUNNEL_PORT=9001

TGT_DATADG=+DATA

TGT_REDODG=+RECO

TGT_RECODG=+RECO

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SKIP_FALLBACK=TRUE

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=6

サンプルのレスポンス・ファイルは、/$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

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

3.4.2 Exadata Cloud Serviceターゲットへのオンライン移行用レスポンス・ファイルの準備

要件 説明 コメント
オンライン移行用レスポンス・ファイルの準備

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次の設定を編集します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • MIGRATION_METHODをDG_OSSに設定します。DGは、Data Guardを表す略号です。また、OSSは、Object Storageサービスを表す略号です。
  • PLATFORM_TYPEをEXACSに設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • HOSTとOPC_CONTAINERには、Object StoreのURLとバケット名を設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSには、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSには、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
たとえば、レスポンス・ファイルを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、次に示すようにソースとターゲットに基づいて値を設定に追加します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=DG_OSS

PLATFORM_TYPE=EXACS

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_SSH_TUNNEL_PORT=9001

TGT_DATADG=+DATAC1

TGT_REDODG=+RECOC1

TGT_RECODG=+RECOC1

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SKIP_FALLBACK=TRUE

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=6

サンプルのレスポンス・ファイルは、/$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

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

3.4.3 Exadata Cloud at Customerターゲットへのオンライン移行用レスポンス・ファイルの準備

要件 説明 コメント
オンライン移行用レスポンス・ファイルの準備

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次に示す設定を編集します。Exadata Cloud at Customerの場合は、ここに示すように3つのタイプのバックアップ媒体がサポートされています。

Exadata Cloud at Customerターゲット用のレスポンス・ファイルをZero Data Loss Recovery Applianceバックアップで準備するには、次のパラメータを設定します。

  • 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のパラメータを設定します。

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

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

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

      ZDLRA_CRED_ALIAS=zdlra_scan:listener_port/zdlra9:dedicated

  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSには、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSには、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。

Exadata Cloud at Customerターゲット用のレスポンス・ファイルをObject Storageサービスのバックアップで準備するには、次のパラメータを設定します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • MIGRATION_METHODをDG_OSSに設定します。DGは、Data Guardを表す略号です。また、OSSは、Object Storageサービスを表す略号です。
  • PLATFORM_TYPEをEXACCに設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • HOSTとOPC_CONTAINERをObject StoreのURLとバケット名に設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSには、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSには、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。

Exadata Cloud at Customerターゲット用のレスポンス・ファイルをNFSバックアップで準備するには、次のパラメータを設定します。

  • 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アクセス・ホストで同じにする必要があります。このパスは、Zero Downtime Migrationサービス・ホストにマウントされている必要はありません。

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

      • ソース・データベースは、RMAN SQL*Net接続を使用して、指定されたパスにバックアップされ、Exadata Cloud at Customerにリストアされます。
      • BACKUP_PATHに設定するパスには、ソース・データベース・ユーザーの場合は'rwx'権限が、ターゲット・データベース・ユーザーの場合は読取り権限以上が必要です。
      • BACKUP_PATHで指定したパスに、$BACKUP_PATH/dbnameディレクトリがZero Downtime Migrationバックアップ・プロシージャによって作成され、このディレクトリにバックアップ・ピースが格納されます。
      • DG_EXTBACKUPをMIGRATION_METHODに使用する場合は、スタンバイ制御ファイルのバックアップを指定のパスに作成して、バックアップ・ピースに対する読取り権限をターゲット・データベース・ユーザーに付与する必要があります。次に例を示します。

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

  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • HOSTとOPC_CONTAINERをObject StoreのURLとバケット名に設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSには、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSには、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数を設定します。デフォルトは10です。
たとえば、レスポンス・ファイルを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、次に示すようにソースとターゲットに基づいて値を設定に追加します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=DG_OSS

PLATFORM_TYPE=EXACC

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_SSH_TUNNEL_PORT=9001

TGT_DATADG=+DATA

TGT_REDODG=+RECO

TGT_RECODG=+RECO

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SKIP_FALLBACK=TRUE

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=8

サンプルのレスポンス・ファイルは、/$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

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

3.4.4 オフライン移行(バックアップとリカバリ)用レスポンス・ファイルの準備

要件 説明 コメント
オフライン移行用レスポンス・ファイルの準備(バックアップとリカバリを使用)

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次に示す設定を編集します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • ターゲット環境に応じて、PLATFORM_TYPEを適切な値に設定ます。
    • Oracle Cloud Infrastructureの場合は、PLATFORM_TYPE=VMDBを設定します。
    • Exadata Cloud at Customerの場合は、PLATFORM_TYPE=EXACCを設定します。
    • Exadata Cloud Serviceの場合は、PLATFORM_TYPE=EXACSを設定します。
  • MIGRATION_METHODをBACKUP_RESTORE_OSSに設定します。OSSは、Object Storageサービスを表す略号です。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADG、TGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFSを設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • HOSTとOPC_CONTAINERには、Object StoreのURLとバケット名を設定します。
  • SHUTDOWN_SRC=TRUEは、データベースの移行後にソース・データベースを停止する場合に設定します。
  • SRC_RMAN_CHANNELSを、ソースに割り当ててRMANバックアップの実行に使用するRMANチャネルの数に設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSを、ターゲットに割り当ててRMANリストアの実行に使用するRMANチャネルの数に設定します。デフォルトは10です。

たとえば、レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、次に示すようにソースとターゲットに基づいて設定の値を入力します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=BACKUP_RESTORE_OSS

PLATFORM_TYPE=VMDB

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_DATADG=+DATA

TGT_REDODG=+RECO

TGT_RECODG=+RECO

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=6

サンプルのレスポンス・ファイルは、$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

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

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

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

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

(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

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

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

要件 説明 コメント
移行ジョブのカスタマイズ

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

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

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

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

特定のプラグインを関連付ける必要がある操作フェーズを決定して、ZDMCLIコマンドadd useractionを実行します。このコマンドには、-optype MIGRATE_DATABASEと操作の各フェーズ、プラグインがそのフェーズを基準として-preまたは-postのどちらで実行されるかと、エラー時の要件を指定します。操作フェーズのカスタム・プラグインは、移行ジョブ・ワークフローの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

このコマンドでは、スクリプト/home/zdmuser/useract.shと/home/zdmuser/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

 なし

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