4 物理データベース移行の準備
Zero Downtime Migrationの物理データベース移行を開始する前に、ソース・データベースとターゲット・データベースの準備、レスポンス・ファイルでのパラメータの設定、必要な移行ジョブのカスタマイズの構成を実行する必要があります。オンライン物理移行用に、ソース・データベースとターゲット・データベース間の接続を構成します。
ノート:
ホスト名はソースとターゲットとで異なっている必要があります。ホスト名が同一の場合は、移行に失敗します。4.1 オンライン物理移行の前提条件
オンライン物理移行のために接続の前提条件を構成する必要があります。ソース・データベース・サーバーとターゲット・データベース・サーバー間でSCANおよびSCANポートを使用した接続ができない場合は、ソース・データベース・サーバーからターゲット・データベース・サーバーへのSSHトンネルを設定します。
関連トピック
4.2 ソース・データベースおよびターゲット・データベースの準備
移行ジョブを構成する前に、ソース・データベースとターゲット・データベースで完了しておく必要があるタスクがいくつかあります。次に、ソース・データベースとターゲット・データベースの両方に適用される前提条件を示します。
-
Zero Downtime Migrationのオンライン物理移行ではOracle Data Guardを利用するため、ソースとターゲットの両方で同じオペレーティング・システムおよびデータベース・バージョンが必要です。
-
Zero Downtime Migrationの物理移行ワークフローでは、エディション間の移行はサポートされていませんが、論理移行ワーク・フローを使用して、Standard EditionをEnterprise Editionに移行できます。
-
ソース・データベースの文字セットは、ターゲット・データベースと同じである必要があります。
-
ソース・データベースとターゲット・データベースではサーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。
- ZDMでは、オフライン移行にSPFILEを使用していないソース・データベースがサポートされます。オンライン移行の場合は、SPFILEを使用してソース・データベースを実行する必要があります。
-
Zero Downtime Migrationサービス・ホストおよびソース・データベース・サーバーのシステム時間は、Oracle Cloud Infrastructureターゲットと同期している必要があります。
これらのいずれかのシステムの時間がOCIの時間から6分を超えて異なる場合は、調整する必要があります。NTPが構成されている場合は、
ntp time check
を使用して時刻を同期できます。NTPが構成されていない場合は、構成することをお薦めします。NTPを構成するオプションがない場合は、時間を手動で修正して、OCI時間と同期するようにする必要があります。 -
ソース・データベースとターゲット・データベースで、
COMPATIBLE
データベース初期化パラメータを同じ値に設定します。有効な値は、Oracle DatabaseのCOMPATIBLE初期化パラメータの値を参照してください。 -
ソースSQLNET.ORAとターゲットSQLNET.ORAの両方に同じ暗号化アルゴリズムがあることを確認してください。
- ターゲット・データベースのタイムゾーンがソース以降であることを確認してください。ソース・データベースのタイムゾーン・バージョンがターゲット・データベースより前の場合は、移行後、データベースのタイムゾーンをアップグレードする必要があります。タイムゾーンを調整すると、タイムゾーンのアップグレードで停止時間が発生し、これにはデータベースの再起動が2回必要となります。タイムゾーンのアップグレードに伴う停止時間は、変更が必要なデータの量によって異なります。ソース・データベースとターゲット・データベースのタイムゾーン・バージョンを一致させて、長時間停止するタイムゾーンのアップグレードを回避することをお薦めします。ただし、ZDMでは、ワークフローの一部として物理移行のタイムゾーンのアップグレードを自動化します。ZDM_TGT_UPGRADE_TIMEZONE_FILEを参照してください。
- ZDMを使用すると、バックアップ圧縮および暗号化をオフにできます。暗号化は、オンプレミス・データベース間での移行時のみ、オフにできます。クラウド・ターゲットへの移行時には、暗号化は必須です。「ZDM_RMAN_ENCRYPT_BACKUP」を参照してください。
- RMANで使用されるセクション・サイズを構成できます。「ZDM_RMAN_SECTION_SIZE」を参照してください。
- 物理移行を実行する場合は、ソース・データベースおよびターゲット・データベースの前提条件として、
/tmp
がexecute
権限でマウントされていることを確認します。
4.3 ソース・データベースの前提条件
Zero Downtime Migrationプロセスを開始する前に、ソース・データベースで次の前提条件を満たします。
-
アーカイブ・モードの設定
ソース・データベースは
ARCHIVELOG
モードで稼働している必要があります。データベースのアーカイブ・モードの変更を参照してください。 -
Oracle Database 12cリリース2以降での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 Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1でのTDEの有効化はオプションです。
-
Oracle RACの場合:
ソースが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接続を使用可能にする必要があります。
-
-
RMANバックアップ計画の保守
移行時にソース・データベースのリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を保持するには、既存のRMANバックアップ計画を保持する必要があります。
移行中に、デュアル・バックアップ計画が実施されます。既存のバックアップ計画と、Zero Downtime Migrationにより使用される計画です。
2つのRMANバックアップ・ジョブ(既存のジョブとZero Downtime Migrationにより開始されたジョブ)を同時に実行することは避けてください。
ソース・データベースでアーカイブ・ログが削除され、これらのアーカイブ・ログが、ターゲット・クラウド・データベースを同期させるためにZero Downtime Migrationで必要な場合は、Zero Downtime Migrationで移行プロセスを続行できるように、これらのファイルをリストアする必要があります。
-
制御ファイルに自動的にバックアップするRMANの構成
制御ファイルおよびSPFILEを自動的にバックアップするようにRMANがまだ構成されていない場合は、
CONFIGURE CONTROLFILE AUTOBACKUP
をON
に設定し、移行の完了後にOFF
に戻します。RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
-
SRVCTLへの登録
ソース・データベースがOracle Grid Infrastructureを使用してデプロイされ、SRVCTLを使用してデータベースが登録されていない場合は、移行前にデータベースを登録する必要があります。
-
オフライン移行の場合
移行中にデータが失われないように、
ZDM_BACKUP_DIFFERENTIAL_SRC
フェーズの前にソース・データベースで受信トランザクションが行われないように計画します。Zero Downtime Migrationがバックアップの生成を開始して転送すると、ソース上の新しいトランザクションはバックアップの一部にならないため、クラウド内のターゲットにはこれらの変更が含まれません。
-
DB_nK_CACHE_SIZEの処理
Zero Downtime Migrationでは、ソースinit
ファイルからターゲット・データベースへのDB_nK_CACHE_SIZE値のコピーが自動化されます。この自動化は、ソース・データベースがdb_block_size
以外の可変ブロック・サイズの表領域を使用する移行に役立ちます。このような場合、DB_nK_CACHE_SIZE
のZero Downtime Migration処理がないと、リストア・プロセスは失敗します。ノート:
非CDBからPDBへの変換が実行される移行の場合は、ソースがプラグインされる実際のターゲットCDBでこの値を設定する必要があります。
4.4 ターゲット・データベースの前提条件
ターゲット環境への移行を開始する前に、プレースホルダ・ターゲット・データベースを作成する必要があります。Zero Downtime Migrationプロセスを開始する前に、ターゲット・データベースで次の前提条件を満たす必要があります。
プレースホルダ・ターゲット・データベースは移行時に上書きされますが、全体の構成は維持されます。
-
このリリースでは、Grid Infrastructureベースのデータベース・サービスのみがターゲットとしてサポートされます。たとえば、LVMベースのインスタンスまたはGrid Infrastructureがないノードに作成されたインスタンスは、サポートされているターゲットではありません。
-
Oracle Exadata Database Service on Dedicated InfrastructureおよびOracle Exadata Database Service on Cloud@Customerターゲットの場合、データベースの移行を開始する前に、Grid Infrastructureデータベース・サービスではなくコントロール・プレーンを使用してプレースホルダ・データベースを作成する必要があります。
-
将来のサイズ
コンソールからデータベースを作成する際、選択したシェイプがソース・データベースを収容でき、将来のサイズ変更の要件に適応できることを確認します。適切なガイドラインは、ソース・データベースと同程度以上のサイズのシェイプを使用することです。
-
名前パラメータの設定
-
DB_NAME
ターゲット・データベースがOracle Exadata Database Service on Dedicated InfrastructureまたはOracle Exadata Database Service on Cloud@Customerの場合、データベース
DB_NAME
はソース・データベースDB_NAME
と同じである必要があります。ターゲット・データベースがOracle Cloud Infrastructureの場合、データベース
DB_NAME
はソース・データベースDB_NAME
と同じでも、異なってもかまいません。 -
DB_UNIQUE_NAME
ターゲット・データベースがOracle Cloud Infrastructure、Oracle Exadata Database Service on Dedicated InfrastructureまたはOracle Exadata Database Service on Cloud@Customerの場合、Oracle Data Guardがターゲットをソース・データベースとは異なるデータベースとして識別できるように、ターゲット・データベースのDB_UNIQUE_NAME
パラメータ値は一意である必要があります。ノート:
ソース・データベースとターゲット・データベースの名前が同じであり、大/小文字の区別も同じであることを確認してください。
-
-
ソースのSYSパスワードとの一致
ソース・データベースのパスワードと一致する
SYS
パスワードを指定します。 -
自動バックアップの無効化
自動バックアップを有効化しないで、コンソールからターゲット・データベースをプロビジョニングします。
Oracle Cloud InfrastructureおよびOracle Exadata Database Service on Dedicated Infrastructureの場合は、「Configure database backups」セクションの「Enable automatic backups」オプションを選択しないでください。
Oracle Exadata Database Service on Cloud@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ウォレット・フォルダが存在することの確認
TDEウォレット・フォルダが存在することを確認し、ウォレットの
STATUS
がOPEN
で、WALLET_TYPE
がAUTOLOGIN
(自動ログイン・ウォレット・タイプの場合)またはWALLET_TYPE
がPASSWORD
(パスワードベースのウォレットの場合)であることを確認します。マルチテナント・データーベースの場合は、すべてのPDBおよびCDBでウォレットがオープンされており、マスター・キーがすべてのPDBおよびCDBに設定されていることを確認します。SQL> SELECT * FROM v$encryption_wallet;
-
Oracle RACターゲットの場合:
ターゲットがOracle RACデータベースの場合、oracleユーザーのOracle RACサーバー間にパスフレーズなしのSSH接続が設定されていることを確認します。
-
ディスク・グループのサイズおよび使用率の確認
ターゲット・データベースのディスク・グループ(ASMディスク・グループまたはACFSファイル・システム)のサイズおよび使用率をチェックし、十分な記憶域がターゲット・データベース・サーバーでプロビジョニングされ、使用可能であることを確認します。
-
接続の確認
-
Oracle Cloud Infrastructure、Oracle Exadata Database Service on Dedicated InfrastructureまたはOracle Exadata Database Service on Cloud@Customer環境のターゲット・サーバーのポート22および1521 (または構成済のデータベース・リスナー・ポート)がオープンされており、ファイアウォールによってブロックされていないことを確認します。
Zero Downtime Migrationホストおよびソース・データベース・サーバーからのオープン接続が必要です。
-
ターゲット・データベース・サーバーのポート22でZero Downtime Migrationサービス・ホストからの着信接続が許可されることを確認します。
-
-
RMANの
SHOW ALL
コマンドの出力を取得します。移行後のRMAN設定を比較できるように出力を取得した後、変更されたRMAN構成設定をリセットして問題なくバックアップが機能することを確認します。
RMAN> show all;
4.5 透過的データ暗号化キーストアの設定
Oracle Database 12cリリース2以降では、ソース・データベースおよびターゲット・データベースで透過的データ暗号化(TDE)が有効になっていない場合、移行を開始する前にTDEキーストアを構成する必要があります。
ノート:
Oracle Database 11.2および12.1ソースの場合、TDEウォレット構成は必要ありません。ソースにTDEウォレットが構成されていない場合、ターゲット上のTDE構成はすべて削除されます。移行後、ターゲットでTDEウォレットを構成する必要があります。ノート:
Oracle Database 11.2および12.1のソースを移行するときに、暗号化されていないソースである場合は、TDEウォレット(これは要件)の提供時でも、ZDMで、ターゲット・データベースでのENCRYPT on RESTOREは使用できません。これは、CDBデータベースを移行およびアップグレードする場合に当てはまります。不足している暗号化タスクは、移行後に手動で実行する必要があります。
TDE WALLET
ステータスをOPEN
に設定する必要があります。WALLET_TYPE
は、自動ログイン・キーストアの場合はAUTOLOGIN
(優先)、パスワードベースのキーストアの場合はPASSWORD
です。マルチテナント・データベースで、すべてのPDBおよびCDBでキーストアがオープンされており、マスター・キーがすべてのPDBおよびCDBに設定されていることを確認します。
ノート:
前述のコマンドを実行する前に、必ずすべてのPDBをオープンします。ソースおよびターゲットのデータベースでTDEが必須としてまだ構成されていない場合は、次の手順に従ってTDEキーストアを設定します。
ノート:
ソースTDEウォレットがLOCAL_AUTOLOGIN
シングル・サインオン証明書で構成されている場合、ZDMはシングル・サインオンをコピーしません。これは、LOCAL_AUTOLOGIN
シングル・サインオン証明書が、生成されたノードでのみ有効であるためです。かわりに、TDEウォレット・パスワードを入力して、ターゲット・ノードのAUTOLOGIN
証明書を生成する必要があります。そのため、ソースがLOCAL_AUTOLOGIN
ウォレットを使用している場合、移行後、ターゲットにはAUTOLOGIN
ウォレットがあります。ZDMはLOCAL_AUTOLOGIN
ウォレットを生成しません。
ノート:
ソースまたはターゲット・データベースでFILE
またはASM
ウォレットとは異なるキーストアの場所を使用している場合、ZDMはTDEキーを移行しません。キーストアがファイル・システム・キーストアで使用できない場合、キーのエクスポート、インポートまたは移行はキーストア固有のツールを使用して処理する必要があるため、ターゲットからアクセスできるソースでウォレット・キーを確認してください。ZDMは、FILE
またはASM
とは異なるキーストアからキーを移行できません。
ZDMでは、Oracle Database 19c以上のバージョンがあるターゲットの場合に、データベース全体に対して、encrypt on restore
を含む単一のリストア文が使用されるようになりました。
RESTORE DATABASE AS ENCRYPTED AS ENCRYPTED FROM TAG 'ZDM_JOB_10';
ノート:
この機能は、バックアップ/リストアを使用する移行、またはサービスからのリストアを使用する直接移行に影響します。ZDLRAを使用した移行、またはアクティブな複製を使用した直接移行の場合、ZDMでは、暗号化がさらに実行されることはなく、リストア後のターゲットでの暗号化ステータスはソース・データベースと同じです。パスワードベースのキーストアの場合はステップ1、2および4のみを実行し、自動ログイン・キーストアの場合はすべてのステップを実行します。
-
$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インスタンスの場合は、すべてのノードでも
ENCRYPTION_WALLET_LOCATION
を設定します。 -
キーストアを作成して構成します。
-
データベースに接続してキーストアを作成します。
$ sqlplus "/as sysdba" SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin' identified by password;
-
キーストアを開きます。
非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.
-
マスター暗号化キーを作成してアクティブにします。
非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.
-
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に進みます。
-
-
自動ログイン・キーストアの場合のみ、キーストア構成を実行します。
-
自動ログイン・キーストアを作成します。
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.
-
パスワードベースのキーストアを閉じます。
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password; keystore altered.
-
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
に設定されていることを確認します。そうでない場合、自動ログイン・キーストアは正しく設定されていません。これで、自動ログイン・キーストアの構成が完了しました。
-
-
キーストア・ファイルを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*
-
ノート:
ZDMは、WALLET_ROOT
で構成されているウォレット・ファイルおよびサブディレクトリをすべて移行できます。ソースに分離モードのPDBウォレットがある場合、ZDMはWALLET_ROOT
のサブディレクトリにあるウォレットのファイルをすべて移行します。
関連トピック
4.6 サポートされているデータ転送メディアの使用
Zero Downtime Migrationの物理移行プロセスには、ソース・データベースのバックアップの作成およびターゲット・データベースへのリストア、または既存のバックアップの使用が含まれます。
Oracle Cloud Infrastructure Object Storage
OCI Object Storageは、データベースをOracle Cloud Infrastructure、Oracle Exadata Database Service on Dedicated Infrastructure、または任意のオンプレミスOracle Exadata Database Service on Cloud@Customerターゲットに移行する際に、バックアップ媒体としてサポートされます。
Zero Downtime Migrationサービスでは、移行ワークフローの一部としてソース・データベースのバックアップが開始されるか、またはObject Storageバケット内の既存のバックアップを指定できます。Zero Downtime Migrationによってそれがターゲット環境にリストアされるため、Object Storageにソース環境とターゲット環境の両方からアクセスできる必要があります。
ソース・データベースは、指定されたコンテナにバックアップされ、RMAN SQL*Net接続を使用してターゲットにリストアされます。
Zero Downtime Migrationサービス・ホストではソースおよびターゲットのデータベース・サーバーへのSSH接続を使用して、Object Storageに対するバックアップおよびリストアに必要なバックアップ・モジュール・ソフトウェアをインストールして構成します。ソース・データベースからObject Storageへのバックアップは、RMANチャネルを介して行われます。
必要に応じてOracle Cloud Serviceコンソールを使用してObject Storageバケットが作成されていることを確認します。
また、ソース・データベースのバックアップを収容するのに十分なストレージがオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。
Zero Data Loss Recovery Appliance
Zero Data Loss Recovery Applianceは、データベースをOracle Exadata Database Service on Cloud@CustomerターゲットまたはOracle Exadata Database Machineに移行するためのバックアップ媒体としてサポートされます。
Zero Data Loss Recovery Applianceをバックアップ・メディアとして選択した場合、Zero Data Loss Recovery Applianceにソース・データベースの有効なバックアップがあることを確認する必要があります。これは、Zero Downtime MigrationではZero Data Loss Recovery Applianceへのバックアップをワークフローの一環として開始しないためです。
また、Zero Data Loss Recovery Applianceへのバックアップを開始する前に、データベースのすべてのインスタンスが稼働していることを確認する必要があります。インスタンスの停止時にバックアップが開始されると、データベースの複製操作が失敗する場合があります。
Zero Downtime Migrationサービスでは、Zero Data Loss Recovery Applianceのバックアップにアクセスし、Oracle Exadata Database Service on Cloud@Customerにリストアします。Zero Data Loss Recovery Applianceのアクセス資格証明およびウォレットの場所は必須の入力パラメータであるため、Zero Downtime Migrationでは、ターゲット・データベースでのZero Data Loss Recovery Applianceウォレットの設定を処理できます。
ソースとターゲットのデータベース・サーバー間でのREDOストリームの転送はいずれの方向にも、SQL*Netリンクを介して行われます。
バックアップの作成の詳細は、Zero Data Loss Recovery Applianceのドキュメントを参照してください。
ネットワーク・ファイル・システム(NFS)
NFSは、Oracle Exadata Database Service on Cloud@CustomerターゲットまたはオンプレミスOracle Exadata Database Machineターゲットにデータベースを移行する際のバックアップ媒体としてサポートされます。
データベースをNFSマウントにバックアップすることを選択した場合は、Zero Downtime Migrationサービスによってソース・データベースのバックアップが開始され(または、既存のバックアップを指定できる)、それがExadataターゲット環境にリストアされます。NFSには、ソース環境とターゲット環境の両方からアクセスできる必要があります。
ソース・データベースは、RMAN SQL*Net接続を使用して、指定されたパスにバックアップされ、Oracle Exadata Database Service on Cloud@Customerにリストアされます。
NFSを介してオフライン移行を使用して移行を実行する場合、ソースとターゲットの間のSQL*Net接続は必要ありません。
4.7 物理移行パラメータの設定
必要な物理移行レスポンス・ファイル・パラメータを設定します。データベース移行プロシージャのZero Downtime Migrationレスポンス・ファイルの作成に使用するレスポンス・ファイル・テンプレート$ZDM_HOME/rhp/zdm/template/zdm_template.rsp
を取得し、ここで説明するようにファイルを編集します。
ノート:
現在は、DATA_TRANSFER_MEDIUM=DIRECTの場合はオンライン物理移行のみがサポートされています。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 - Oracle Exadata Database Service on Dedicated Infrastructure
-
EXACC - Oracle Exadata Database Service on Cloud@Customer
-
NON_CLOUD - オンプレミスExadata Database Machine
MIGRATION_METHOD
MIGRATION_METHOD
を次のいずれかの値に設定します。
-
ONLINE_PHYSICAL - Oracle Data Guard (オンライン)
-
OFFLINE_PHYSICAL - RMANのバックアップおよびリストア(オフライン)。これは、Oracle Database Standard Edition 2でサポートされている唯一の移行方法です。
DATA_TRANSFER_MEDIUM
DATA_TRANSFER_MEDIUM
では、ソース・データベースのバックアップに使用されるメディアを指定します。
-
OSS
- スタンバイ初期化にObject Storageサービス(OSS)を使用するOracle Data Guard。Oracle Cloud Infrastructure (
VMDB
)、Oracle Exadata Database Service on Dedicated Infrastructure(EXACS
)およびOracle Exadata Database Service on Cloud@Customer (EXACC
)に設定されているPLATFORM_TYPE
でサポートされます。また、移行ログをCloud Object Storageにアップロードする場合は、
ZDM_LOG_OSS_PAR_URL
をCloud Object Storeの事前認証済URLに設定します。事前認証済URLの取得の詳細は、Oracle Cloudのドキュメント(https://docs.oracle.com/en-us/iaas/Content/Object/Tasks/usingpreauthenticatedrequests.htm#usingconsole)を参照してください。Object Storage Serviceを介してバックアップおよびリストア(OFFLINE_PHYSICAL)を使用して移行を実行する場合、ソースとターゲットの間のSQL*Net接続は必要ありません。
OSSの使用の詳細は、「サポートされているデータ転送メディアの使用」を参照してください。
-
ZDLRA
- スタンバイ初期化にZDLRAを使用するOracle Data Guard。Oracle Exadata Database Service on Cloud@Customer (
EXACC
)またはオンプレミスExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPE
でサポートされ、次のパラメータを設定します。-
次のように、
SRC_ZDLRA_WALLET_LOC
をウォレットの場所に設定します。SRC_ZDLRA_WALLET_LOC=/u02/app/oracle/product/12.1.0/dbhome_3/dbs/zdlra
-
TGT_ZDLRA_WALLET_LOC
をウォレット・ロケーションに設定します(たとえば、TGT_ZDLRA_WALLET_LOC=target_database_oracle_home/dbs/zdlra
)。 -
次のように、
ZDLRA_CRED_ALIAS
をウォレットの資格証明別名に設定します。ZDLRA_CRED_ALIAS=zdlra_scan:listener_port/zdlra9:dedicated
ZDLRAの使用の詳細は、「サポートされているデータ転送メディアの使用」を参照してください。
-
-
NFS
- NFSなどのバックアップ場所を使用するOracle Data Guard。Oracle Exadata Database Service on Cloud@Customer (
EXACC
)またはオンプレミスExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPE
でサポートされます。また、
BACKUP_PATH
を設定して、ソースとターゲットの両方のデータベース・サーバーからアクセスできるようになっている実際のNFSパス(NFSマウント・ポイントなど)を指定します。NFSマウント・パスはソースとターゲットの両方のデータベース・サーバーで同じである必要があります。このパスは、Zero Downtime Migrationサービス・ホストにマウントされている必要はありません。次の考慮事項に注意してください。
-
BACKUP_PATH
に設定するパスには、ソース・データベース・ユーザーの場合は'rwx'権限が、ターゲット・データベース・ユーザーの場合は読取り権限以上が必要です。 -
BACKUP_PATH
で指定したパスに、Zero Downtime Migrationバックアップ手順によってディレクトリ$BACKUP_PATH/dbname
が作成され、このディレクトリにバックアップ・ピースが格納されます。
NASデバイス上でNFSと使用する場合のRACデータベースおよびクラスタウェアのOracleファイルのマウント・オプション(ドキュメントID 359515.1)を参照してください。
NFSの使用の詳細は、「サポートされているデータ転送メディアの使用」を参照してください。
-
-
DIRECT
- RMANのアクティブなデータベースの複製またはサービスからのリストアを使用して、データをソースからターゲットに直接転送します。転送方法(サービスからのリストアまたはアクティブな複製)は、デフォルトで
RESTORE_FROM_SERVICE
に設定されているZDM_RMAN_DIRECT_METHOD
で構成されます。ZDMはデフォルト・サービスを使用し、デフォルト・サービス以外のサービスを使用する場合は、
ZDM_SRC_DB_RESTORE_SERVICE_NAME
パラメータを指定します。ノート:
ここで、ソース・データベースはプライマリ・ソース自体です。直接データ転送の詳細は、「直接データ転送の使用」を参照してください。スタンバイから直接データを転送するには、「既存のスタンバイを使用したターゲット・データベースのインスタンス化」を参照してください。
-
EXTBACKUP
- 外部の場所に既存のバックアップがあるOracle Data Guard。Oracle Exadata Database Service on Cloud@Customer (
EXACC
)またはオンプレミスExadata Database Machine (NON_CLOUD)に設定されているPLATFORM_TYPE
でサポートされます詳細は、「データ・ソースとしての既存のRMANバックアップの使用」を参照してください。
追加のOracle Cloud Object Storage設定
DATA_TRANSFER_MEDIUM=OSS
の場合、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ストレージではコンテナとも呼ばれます。
TGT_SSH_TUNNEL_PORT
SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORT
パラメータを設定します。
データおよびREDOの場所
Zero Downtime Migrationでは、指定されたターゲット・データベースからdata
、reco
およびredo
(Exadata以外のシステムの場合)ストレージ・ボリュームの場所が自動的に検出されます。検出された値をオーバーライドする必要がある場合は、適切なパラメータ・セットを使用してターゲット・データベース・データ・ファイルの記憶域(ASMまたはACFS)の場所を指定します。
- ASM:
TGT_DATADG
、TGT_REDODG
およびTGT_RECODG
- ACFS:
TGT_DATAACFS
、TGT_REDOACFS
およびTGT_RECOACFS
SKIP_FALLBACK
任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUE
を設定します。
TGT_SKIP_DATAPATCH
Zero Downtime Migrationは、ターゲット・データベース環境のパッチ・レベルがソース・データベースよりも高い場合(たとえば、ソース・データベースがJan 2020 PSU/BPで、ターゲット・データベースがApril 2020 PSU/BPの場合)、デフォルトでdatapatchユーティリティを移行プロセスの一部として実行します。
このタスクをスキップする場合は、TGT_SKIP_DATAPATCH=FALSE
レスポンス・ファイル・パラメータを設定します。
PHASE_NAME_MONITORING_INTERVAL
Zero Downtime Migrationで、移行中に構成された時間間隔でバックアップおよびリストア操作のステータスをモニターおよびレポートする場合は、PHASE_NAME_MONITORING_INTERVAL=n mins
を設定します。デフォルトの間隔値は10分です。モニタリングを無効にするには、これらの値を0 (ゼロ)に設定します。
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=
ZDM_CLONE_TGT_MONITORING_INTERVAL=
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=
ZDM_BACKUP_RETENTION_WINDOW
移行後にソース・データベースのバックアップを保持する場合は、ZDM_BACKUP_RETENTION_WINDOW=number of days
を設定します。
ZDM_SRC_TNS_ADMIN
カスタムの場所の場合は、ZDM_SRC_TNS_ADMIN=TNS_ADMIN value
を設定します。
ZDM_APPLY_LAG_MONITORING_INTERVAL
スタンバイ・データベースの作成後にREDO適用ラグを監視するには、ZDM_APPLY_LAG_MONITORING_INTERVAL
= {NONE | DAILY | WEEKLY}
と設定します。このフェーズは、現在のREDO適用ラグを問い合せ、REDO適用が完了するまで待機してからジョブを再開します。「ZDM_APPLY_LAG_MONITORING_INTERVAL」を参照してください。
4.8 データ・ソースとしての既存のRMANバックアップの使用
Zero Downtime Migrationでは、既存のレベル0のバックアップを使用して、移行ジョブの全体バックアップ・フェーズをスキップできます。
この方法は、Oracle Exadata Database Service on Cloud@CustomerまたはオンプレミスExadata Database Machineターゲットでサポートされます。
Zero Downtime Migrationでは、オンラインおよびオフラインの両方の物理移行ジョブについて、レベル0およびレベル1のバックアップを即時に取得します。移行ジョブ中、Zero Downtime Migrationでは、全体バックアップを実行するかわりに既存のソース・データベースのバックアップを再利用できます。
DISK、SBT_TAPE、ZDLRAなどのすべてのタイプのバックアップ・デバイスが、この移行方法のデータ転送メディアとしてサポートされています。
このユースケースでは、incremental_level=0
を指定したレベル0のバックアップのみが有効です。
既存のRMANバックアップを使用するには、次のレスポンス・ファイル・パラメータを設定します。
ZDM_USE_EXISTING_BACKUP=TRUE
ZDM_BACKUP_TAG=RMAN backup tag
ノート:
ZDLRAの場合、既存のバックアップを起動する必要があります。ただし、ZDLRAのZDM_USE_EXISTING_BACKUP
パラメータはスキップします。
ZDMCLI database migration -eval
)で実行すると、Zero Downtime Migrationによってバックアップの存在が検証され、そのバックアップが有効かどうかがチェックされ、ジョブ出力でバックアップが使用可能および検証されているかどうかが表示されます。
移行モード(ZDMCLI database migration
)では、Zero Downtime Migrationは評価モードで実行されたものと同じステップを実行してから、全体バックアップをスキップし、増分バックアップや差分バックアップなどの他のバックアップ操作を実行します。
バックアップの作成
移行ソースとして使用する有効なRMANバックアップを取得するには、次のコマンドを実行します。
DISKの場合:
RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE DISK FORMAT 'directory_path/%d_backup_%U';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
DATABASE FORMAT 'directory_path/%d_backup_%U_DBF' SECTION SIZE 4G ;
}
SBT_TAPEの場合:
RUN {
ALLOCATE CHANNEL channel_name DEVICE TYPE SBT FORMAT '%d_%I_%T-%s_%p'
PARMS 'SBT_LIBRARY=path/libopc.so, SBT_PARMS=(OPC_PFILE=path/OPC/mzdm.conf)';
ALTER SYSTEM ARCHIVE LOG CURRENT;
BACKUP AS COMPRESSED BACKUPSET FORCE INCREMENTAL LEVEL 1 FOR RECOVER OF TAG 'backup_tag'
DATABASE FORMAT '%d_%I_%T-%s_%p_DBF' SECTION SIZE 4G ;
}
スタンバイ制御ファイルのバックアップの作成
また、指定したパスにスタンバイ制御ファイルのバックアップを作成し、ターゲット・データベース・ユーザーのバックアップ・ピースに対する読取り権限を付与します。たとえば、
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT 'BACKUP_PATH/lower_case_dbname/standby_ctl_%U';
standby_ctl_%U
は、システム生成の一意のファイル名です。
代替ユース・ケース
ZDM_BACKUP_TAG
値が指定され、ZDM_USE_EXISTING_BACKUP=FALSE
の場合、Zero Downtime Migrationによって、指定されたタグを含む全体バックアップが作成されます。
パスワード認証でのバックアップの使用
バックアップ・パスワード認証で既存のバックアップを使用するには、コマンドmigrate database
で-backuppasswd password
オプションを使用してパスワードを指定できます。
migrate database
コマンドで-backupwallet
を使用して、バックアップ・ウォレット・パスを指定することもできます。
4.9 直接データ転送の使用
Zero Downtime Migrationは、物理移行中の直接データ転送をサポートして、ソース・データベースがObject StorageやNFSなどの中間ストアにバックアップされないようにしています。
アクティブなデータベースの複製
RMANのアクティブなデータベースの複製が、Oracle Database 11g (11.2)以降のリリースでサポートされています。
サービスからのリストア
サービスからのRMANのリストアは、Oracle Database 12g (12.1)以降のリリースでサポートされています。Oracle MAAのベスト・プラクティスは、Oracle Database 11.2でアクティブな複製を使用し、Oracle Database 12.1以降のサービスからリストアを使用することをお薦めしています。
接続はターゲット・データベース・ホストから開始されるため、アクティブな複製とサービスからのリストアの直接転送方法の両方で、ターゲットからソース・データベースへのSQL*Net接続が必要です。
ソースとターゲット間に非対話型のアクセスも設定する必要があります。ウォレットを使用した非対話型のパスワード指定を参照してください。
4.10 既存のスタンバイの使用によるターゲット・データベースのインスタンス化
プライマリ・データベース・システムへの負荷を減らすために、Zero Downtime Migrationでは、物理移行において、既存のスタンバイ・データベースを使用して、ターゲット環境にあるスタンバイをインスタンス化できます。
この移行オプションは、サービスからのRMANでのリストアで直接データ転送を使用している場合のみ使用できます。
Oracle Database 11.2ではサービスからのRMANリストアがサポートされていないため、既存のスタンバイからの移行はサポートされていません。
以前のバージョンのZero Downtime Migrationでは、スタンバイ制御ファイルのバックアップを作成する必要がありました。しかしながら、21.4バージョンのZero Downtime Migration以降では、スタンバイ制御ファイルのバックアップを作成する必要はありません。
スナップショット制御ファイルが共有ストレージ上にあることの確認
Oracle Real Application Clusters (Oracle RAC)環境では、スナップショット制御ファイルの場所が共有ファイル・システム(すべてのOracle RACインスタンスまたはASMがアクセスできるストレージ)上にある必要があります。
RMAN構成のスナップショット制御ファイルの場所は、デフォルトでORACLE_HOME/dbs/ディレクトリの非共有の場所を指します。
プライマリ・データベースからデータが転送される場合、Zero Downtime Migrationではスナップショット・ファイルの場所が構成されますが、スタンバイ・データベースからの直接データ転送の場合、Zero Downtime Migrationでは場所が構成されません。
スタンバイからの直接データ転送用にRMANが正しく構成されていることを確認する必要があります。
次のステップのRMANコマンドの例では、クラスタ・データベースのスナップショット制御ファイルの場所の構成を設定するため、バックアップを実行するすべてのノードでディレクトリの場所が共有されていることを確認します。
-
次の例に示すように、ソース・プライマリ・データベースの1つのノードでスナップショット制御ファイルを構成します。
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/dbhome2_prim/snapcf_dbhome21.f'; new RMAN configuration parameters: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/dbhome2_prim/snapcf_dbhome21.f'; new RMAN configuration parameters are successfully stored RMAN> show SNAPSHOT CONTROLFILE NAME; RMAN configuration parameters for database with db_unique_name DBHOME2_PRIM are: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/dbhome2_prim/snapcf_dbhome21.f';
-
次の例に示すように、ソース・スタンバイ・データベースの1つのノードでスナップショット制御ファイルを構成します。
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/DBHOME2_STBY/snapcf_dbhome21.f'; new RMAN configuration parameters: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/DBHOME2_STBY/snapcf_dbhome21.f'; new RMAN configuration parameters are successfully stored RMAN> show SNAPSHOT CONTROLFILE NAME; RMAN configuration parameters for database with db_unique_name DBHOME2_STBY are: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+ASM_STBM000038VM5/DBHOME2_STBY/snapcf_dbhome21.f';
スタンバイからのターゲット・データベースのインスタンス化の有効化
既存のスタンバイからのターゲット・データベースのインスタンス化をリクエストするには、物理移行のレスポンス・ファイル内で次のパラメータを設定します。
ZDM_USE_EXISTING_STANDBY = TRUE
(デフォルトはFALSE)
ZDM_STANDBY_DB_CONNECT_STRING=既存のスタンバイにアクセスするための接続文字列
(オプション)
ソースとターゲットの同期の維持
ターゲット・データベースはインスタンス化された後、プライマリへの登録、およびプライマリから送られたアーカイブREDOログの適用により、同期が維持されます。
次のパラメータZDM_USE_EXISTING_STANDBY = TRUE (デフォルトはFALSE)およびZDM_STANDBY_DB_CONNECT_STRING= 接続文字列を設定して、既存のスタンバイにアクセスします(オプション)。既存のスタンバイ・オプションを使用する場合は、ソース・データベースのZDM_SRC_DB_RESTORE_SERVICE_NAMEパラメータをスキップします。デフォルトでは、ZDMはData Guard構成からスタンバイ・データベースの接続文字列を推測しようとし、ZDM_STANDBY_DB_CONNECT_STRINGを指定してZDMのスタンバイ・データベースの接続文字列検出をオーバーライドできます。
4.11 自動アプリケーション・スイッチオーバーの準備
データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。
ノート:
物理的な移行では、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のMAAベスト・プラクティス - Oracle Databaseページのクライアント・フェイルオーバーのベスト・プラクティスに関するOracle MAAホワイト・ペーパー。Oracle Database開発ガイドの高可用性
4.12 Oracle Data Guard Brokerのロール・スイッチオーバーの使用
物理移行では、Zero Downtime Migrationで、Oracle Data Guard Brokerを利用してデータベース・ロールのスイッチオーバーを管理できます。
通常は、Zero Downtime Migrationサービスで、データ移行の完了後にデータベース・ロールのスイッチオーバーが管理されます。代案として、ブローカにスイッチオーバーを処理させるオプションを有効にすることもできます。
ノート:
現在、単一インスタンスからのZDMブローカ対応の移行は、ソース環境に既存のData Guardブローカ対応の構成がある場合にのみサポートされます。すべてのOracle RACソースがサポートされます。アクティブなData Guard Broker構成がない単一インスタンス・データベースを移行する場合は、Data Guard Brokerを使用せずにZDMを使用して移行を進めます。前提条件
ブローカで管理されるロール・スイッチオーバーには、双方向のSQL*Net接続が必要です。
ブローカ構成はOracle Database 11.2.0.4ではサポートされていません。
ブローカによるデータベース・ロールのスイッチオーバーの有効化
ブローカ管理ロール・スイッチオーバーのオプションは、ZDM_USE_DG_BROKER
レスポンス・ファイル・パラメータを使用して有効または無効にできます。
ZDM_USE_DG_BROKER = TRUE | FALSE
デフォルトでは、ZDM_USE_DG_BROKER
はFALSE
に設定されています。つまり、ブローカでスイッチオーバーは処理されません。
ブローカ・オプション検証
ブローカ管理スイッチオーバーのオプションが有効になっている場合は、Zero Downtime Migrationにより、ブローカによって管理されていないスタンバイがソース・プライマリ・データベースに存在しないことが確認されます。このチェックが実行されるのは、ブローカ構成はブローカ以外で管理されているスタンバイと共存できないためです。
このブローカ・オプションが有効になっていると、プライマリ(ソース)データベースにスタンバイがない場合や、ブローカによってすでに管理されているスタンバイがある場合に、Zero Downtime Migrationによって、ターゲット(Data Guardスタンバイ)データベースを管理するためのブローカ構成が作成されます。
4.13 断続的なネットワーク障害に対するレジリエンシの構成
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
4.14 移行中の非CDBのCDBへの変換
物理的移行プロセスの一環として、Zero Downtime Migrationは非CDBソース・データベースからクラウド内の同じバージョンのPDBへの変換を処理できます。変換プロセスでは、ソース非CDBをターゲットPDBに変換してから、ターゲットの既存のCDBにプラグインします。
非CDBからCDBへの変換により、停止時間が長くなります。このプロセスはオフラインであり(REDO転送および適用なし)、ロールバックはできません。
ZDM物理移行では、非CDBソースとPDBターゲット間の変換が可能です。ZDM_NONCDBTOPDB_PDB_NAME
レスポンス・ファイル・パラメータを使用して移行を開始する前に、ターゲットPDBの名前を定義します。
ソース非CDBデータベースの前提条件
-
Oracle Database 12c以降のバージョン(マルチテナント・アーキテクチャが使用可能になったため)
-
ターゲットCDBと同じ文字セット
ターゲット・データベースCDBおよびPDBの前提条件
-
Zero Downtime MigrationによってPDBが作成されるため、ターゲットCDBには結果として変換されたPDBと同じ名前のPDBを含めることはできません。
-
ターゲット・データベースは、少なくともソース・データベースと同じメジャー・バージョンである必要があります。
- ターゲットでマイナー・バージョンが異なる場合、ソース・データベースよりも高いマイナー・バージョンである必要があります。
- パッチ・レベルが異なる場合は、レスポンス・ファイル・パラメータ
TGT_SKIP_DATAPATCH=FALSE
を設定する必要があります。
- ターゲットCDBデータベースには、非CDBデータベースの移行およびターゲットCDBデータベースに接続されるPDBへの変換に対応するために、メモリーやCPUなどの十分なリソースがあることを確認します。
透過的データ暗号化の要件
-
ソース資格証明では、
migrate database
コマンドに-tdekeystorepasswd
または-tdekeystorewallet
自動ログイン・オプションを含める必要があります。 -
これらのオプションのいずれかを使用する場合は、
-tgttdekeystorepasswd
または-tgttdekeystorewallet
自動ログイン・オプションを使用してターゲット資格証明も指定する必要があります。
Application Expressの要件
-
ソースにApplication Express (APEX)がインストールされていない場合、追加の要件はありません。
-
APEXがソースに存在し、ソース・データベースが非CDBである場合、次のいずれかのオプションを選択する必要があります。
- ソース非CDBからAPEXを削除します。
- ターゲットCDBのAPEXバージョンがソースのAPEXバージョンと同じであることを確認します。
APEXが同じバージョンでない場合、変換はできません。APEXスキーマはバージョン間で異なり、ターゲットPDBを開くことができません。
ターゲットCDBはプロセスで削除されず、他のPDBの有無は変換およびプラグインの結果に影響しません。
レスポンス・ファイル・パラメータは次のように設定します。
- (必須)
NONCDBTOPDB_CONVERSION
: ソース・データベースを非CDBからPDBに変換する場合はTRUE
に設定します。 - (オプション)
NONCDBTOPDB_SWITCHOVER
: 非CDBからPDBへの変換が有効な移行ジョブ中にスイッチオーバー操作を実行するには、Data Guardスイッチオーバーを使用した物理移行に対してTRUE
に設定します。
TDE資格証明を使用した移行時に非CDBをPDBに変換するためのZDMCLI migrate database
コマンドの使用例を次に示します。
対話的にパスワードを提供する例:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name
-srcroot
-targetnode target_database_server_name
-backupuser Object_store_login_user_name
-rsp response_file_location
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/user/bin/sudo
-tdekeystorepasswd
-tgttdekeystorepasswd
CDBのTDEキーストアに自動ログイン・ウォレットを使用する例:
zdmuser> $ZDM_HOME/bin/zdmcli migrate database
-sourcedb source_db_unique_name_value
-sourcenode source_database_server_name
-srcroot
-targetnode target_database_server_name
-backupuser Object_store_login_user_name
-rsp response_file_location
-tgtauth zdmauth
-tgtarg1 user:target_database_server_login_user_name
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/user/bin/sudo
-tdekeystorepasswd
-tgttdekeystorewallet /scratch/credentials/cdbtde.sso
4.15 オンプレミス・データベースのオンプレミス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でサポートされている任意の値に設定できます。クラウド移行の場合と同様に残りのパラメータを設定します。
4.16 Oracle Cloudネイティブの障害時リカバリ計画の作成
一般的な移行では、ZDMにより、ソース・データベースがターゲット・データベース1つのみ(単一障害点)に移行されます。事業運営に悪影響を及ぼす事象に対応しその事象からリカバリできるように、移行後の作業の間にDR (障害時リカバリ)計画を作成できるようになりました。
この移行の間には2つのターゲット・データベース(ターゲット・プライマリ・データベースとターゲット・スタンバイ・データベース)がインスタンス化されます。その際に、それら両方を別々のリージョンに配置できます(自然災害の影響を軽減するため)。移行後の作業の間に、スイッチオーバーやフェイルオーバーなどのクラウド・ネイティブ操作(Oracle Database Cloud Serviceコンソールを使用)が可能になるように、両方のターゲット・データベースにOracle Data Guard Broker構成がリストアされます。
- 移行プロセスを開始する前に、ターゲット・データベースとターゲット・スタンバイ・データベースの両方をインスタンス化します。これらの環境は、Data Guard (DG) Brokerを使用して構成されると想定されています。
- platform_typeにExaCS/ExaCCを使用する場合は、DGアソシエーションを使用してこれを実行できます(Oracle Database Cloud Serviceコンソールを使用)。
- VMDB platform_typeの場合は、DGMGRL Oracle Data Guard Broker CLIツールを使用してこの構成を実行できます(手動)。
- サポートされている移行方法: オンライン移行のみがサポートされています(Oracle Data Guardが使用されている場合)。
- サポートされているデータ転送方法: OSS、ZDLRA、直接。
- サポートされているプラットフォーム・タイプ: ExaCS、ExaCC、VMDB (ZDLRAはサポートされていません)。
- レスポンス・ファイル内のパラメータを次のように設定します:
必須:
- 移行後にDR計画を構成する必要があることを示すには、TGT_STBY_NODEをターゲット・スタンバイ・データベースのIPアドレスに設定します。
- TGT_STBY_DB_UNIQUE_NAME: ターゲット・スタンバイを、ソース・データベースとターゲット・データベースの両方とは異なるデータベースとして指定できます。
- そのターゲット・スタンバイ・データベースに接続する場合は、TGT_STBY_AUTH=
zdmauth
を設定し、TGT_STBY_SUDO_USER (target_standby_database_server_login_user_name)、TGT_STBY_IDENTITY_FILE (ZDM_installed_user_private_key_file_location)およびTGT_STBY_SUDO_PATH (sudo_path)を構成します。
オプション:
- 移行の間にターゲット・スタンバイ・データベースを同期された状態に保つには、ZDM_TGT_STBY_CASCADINGを
TRUE
(デフォルト値)に設定してターゲット・データベースからのREDOログ転送を許可するか、FALSE
に設定してソース・データベース(プライマリ)からのREDOログ転送を許可します。 - データ転送メディアとしてZDLRAを使用する場合は、TGT_STBY_ZDLRA_WALLET_LOCを設定します。
ノート:
このユースケースは非CDBからPDBへの移行の場合のみサポートされています。CDBからCDBへの移行の場合、変換が必要な移行は、現在はサポートされていません。
通常の移行を使用して非CDBをPDBに移行すると、それがターゲットCDBに接続されます。ターゲットCDBは、それ固有のDR設定を使用するように設定できます(コンソールでOracle Data Guardアソシエーションを使用するなど)。非CDBがターゲットCDBに接続されると、それが、ターゲットCDBを介してレプリケートされるようになります。
ZDMを使用したDR移行の場合、(移行後の)ソース・データベースはOCI Oracle Data Guard Broker構成に追加されないため、OCIコンソールで管理されません。ただし、スイッチオーバー後も、ソース・データベースは引き続きターゲット・データベースからREDOログを受信します。
4.17 CDBデータベースの移行とアップグレード
ZDMにより、CDBデータベースからCDBデータベースへの移行が実行され、後でターゲットCDBデータベースが、ZDM_UPGRADE_TARGET_HOME
パラメータで指定されているバージョンのORACLE_HOME
にアップグレードされます。
ZDMでは、ターゲット環境がVMDB (Oracle Base Database Service)の場合の、dbcli
ユーティリティの使用によるCDBの移行とアップグレードがサポートされています。Oracle Base Database Service、Oracle Exadata Database Service on Dedicated InfrastructureおよびOracle Exadata Database Service on Cloud@Customer以外のその他のターゲット環境の場合、ZDMでは、自動アップグレードを使用してCDBのアップグレードが実行されます。
dbaascli
ユーティリティの使用によるCDBの移行とアップグレードがサポートされています。
ノート:
VMDB/EXACC/EXACSの場合、CDBアップグレードのターゲットの認証プラグインdbuserおよびsudoasuserはサポートされていません。このシナリオでは、サポートされているプラグインはzdmauthのみです。
ノート:
ソース・データベースにTDEが構成されていることを確認し、ウォレットの詳細を指定する必要があります。これにより、移行とアップグレードの後に、Oracle Database 19cターゲット・データベースに必ずTDEが構成されるようになります。アップグレードと移行のシナリオでは、すべてのリリースで、TDEが必須です。これは、Oracle Database 11.2およびOracle Database 12.1を含め、すべてのソース・バージョンで必須です。Oracle Cloudでは、Oracle Database 12.2以上のバージョンの場合に、TDEが必須です。詳細は、「透過的データ暗号化キーストアの設定」を参照してください。ノート:
現在、Oracle Base Database Serviceの場合は、Oracle Database 19cをプロビジョニングすると、プロビジョニングされたGIも、同じバージョンのOracle Database 19cになります。現在は、そのGIをOracle 19cからOracle 23aiにアップグレードすることはできません。そのため事実上、現在は、Oracle Database 19c/GIを使用して最初に作成されたVMDBシステムにはOracle Database 23aiデータベースをインストールできません。したがって、移行とアップグレードのシナリオでは、ソースと同じバージョンでデータベース・バージョンをプロビジョニングし、より上位のバージョンで実行されているデータベース・バージョンを追加提供します。自動アップグレードは、non_cloudターゲットの場合のみ使用されます。Oracle Exadata Database Service on Dedicated Infrastructure、Oracle Exadata Database Service on Cloud@CustomerおよびOracle Base Database Serviceなどのすべてのクラウド・プラットフォームでは、アップグレードにクラウド・ツールを使用します。Oracle Exadata Database Service on Dedicated InfrastructureおよびOracle Exadata Database Service on Cloud@Customerの場合はdbaascli
を使用し、Oracle Base Database Serviceの場合はdbcli
を使用します。
- 次のコマンドを使用して、VMDBでORACLE_HOMEをプロビジョニングします:
/opt/oracle/dcs/bin/dbcli create-dbhome -v <supported db version>
ノート:
非CDBからPDBへの変換を伴わないユースケースの場合は、プロビジョニングされたターゲット・データベースが、ソース・データベースと同じバージョンである必要があります。 - コンソールまたは次のコマンドを使用して、EXACC/EXACSでORACLE_HOMEをプロビジョニングします:
dbaascli dbhome create --version <supported_version>
- 同じバージョンのソースCDBとターゲットCDBを選択します。
- ターゲット・データベースでアップグレードする必要があるバージョンに
ORACLE_HOME
をプロビジョニングします。 ZDM_UPGRADE_TARGET_HOME
パラメータに、プロビジョニングされたORACLE_HOME
のパスを指定します。
4.18 非CDBからPDBデータベースへの移行、アップグレードおよび変換
ZDMでは、単一の移行ジョブで、非CDBデータベースをターゲット環境に移行し、そのデータベースをPDBにアップグレードしてから、アップグレードしたPDBを、指定されたターゲットCDBに接続できます。
ZDMでは、アップグレード前チェック、修正、およびアップグレードと接続の操作を実行するためのautoupgrade.jar
の使用による非CDBソース・データベースから上位バージョンのターゲット・データベースへの移行と接続がサポートされています。たとえば、ソースの非CDBデータベースがバージョンOracle Database 12.1であり、ターゲット・データベースがバージョンOracle Database 19cのCDBであるなどです。
ノート:
非CDBデータベースのOracle Database 11gリリース2 (11.2.0.4)のアップグレードの場合は、catbundle.sql
が必要です。Oracle Database 11gリリース2 (11.2.0.4)データベースのアップグレード・シナリオの場合は、ZDMにより、ターゲット・データベースでcatbundle.sql
の場所が確認されます。
このタイプの移行の場合は、次のことが必要です:
- ソース・データベースが非CDBであり、推定ではターゲットCDBより低いリリース(12.1など)であること。
- 目的のデータベース・バージョン(19cなど)でCDBがターゲット・ホストにあること。
- 現在のソースの非CDBのバージョンと同じメジャー・バージョンのデータベース
ORACLE_HOME
がターゲット・ホストにあること。このホームは、ZDMによって、移行プロセスの間に使用する補助的な非CDBデータベースを作成するために使用されます。
ZDM_PRE_UPGRADE_TARGET_HOME
レスポンス・ファイル・パラメータをこのORACLE_HOME
のパスに設定します。