マルチテナント構成でのPDBスイッチオーバーおよびフェイルオーバー

35 マルチテナント構成でのPDBスイッチオーバーおよびフェイルオーバー

ここで説明するユースケースでは、多数のPDBがあるコンテナ・データベース(CDB)を含むOracle Data Guard構成に対して、単一のプラガブル・データベース(PDB)フェイルオーバーおよびスイッチオーバーを設定する方法を示します。

Oracle Multitenantと、複数のプラガブル・データベース(PDB)をコンテナ・データベース(CDB)に統合する機能により、同様のSLAと計画メンテナンス要件を持つ多数のデータベースを、より少ないシステム・リソースで、運用投資を抑えながら管理できます。Oracle MultitenantとそのCDB/PDBテクノロジをOracleのリソース管理で活用することで、全体的なハードウェア・コストと運用コストを効果的に削減できます。

計画とサイズ設定は、同じCDBに統合するデータベースを決定するための重要な前提条件です。HAおよびDRの保護を必要とするミッション・クリティカルなデータベースの場合、および計画メンテナンスの停止時間を最小限に抑える場合は、次のことが重要です

PDBごとに十分なリソースを確保してレスポンスおよびスループットの期待値内で実行するためのサイズ設定およびリソース管理の活用
同じ計画メンテナンス要件とスケジュールを持つターゲットPDBデータベース
CDB、クラスタまたはサイトの障害など、計画外停止が発生した場合にすべて同じCDBスタンバイにフェイルオーバーできるターゲットPDBデータベース

PDBおよびそれらに関連付けられたアプリケーション・サービスを追加すると、Data Guardのフェイルオーバーおよびスイッチオーバー時間が長くなる可能性があります。Data Guardのスイッチオーバーおよびフェイルオーバーの時間を削減する場合は、Data Guardを使用したミッション・クリティカルなゴールドCDBに対して、CDB当たり25未満のPDBを使用することをお薦めします。

ミッション・クリティカルなデータベースと開発/テスト・データベースを異なるCDBに分割することが重要です。たとえば、スタンバイがあるミッション・クリティカルなゴールドCDBには、同じHA/DR要件を持つPDBが5つのみ存在し、十分なシステム・リソース・ヘッドルームを持つようにサイズ設定できますが、スタンバイを持つ重要なCDBには開発、UATおよびアプリケーションのテストの目的で100個のPDBを含めることができ、コストを削減するために一部のレベルのオーバー・サブスクリプションを設定できます。マルチテナントMAAおよびマルチテナントのベスト・プラクティスの詳細は、「Oracle Multitenantのベスト・プラクティスの概要」を参照してください。

このユースケースでは、CDB Data Guardの完全なスイッチオーバーおよびフェイルオーバー操作が不可能な例外の概要およびステップ・バイ・ステップの手順を示します。PDBのフェイルオーバーおよびスイッチオーバー・ステップでは、1つのPDBへのData Guardロール・トランジションを分離して、リカバリ時間目標(RTO)を5分未満、リカバリ・ポイント目標(RPOまたはデータ損失)をゼロまたはほぼゼロにすることができます。

Oracle RDBMS 19c (19.15)以降では、Data Guard Brokerコマンドライン・インタフェース(DGMGRL)を使用して、PDBをData Guard構成間で移行できます。ブローカを使用すると、同じCDB内の他のPDBに影響を与えることなく、PDB障害時リカバリ(DR)およびスイッチオーバー操作を分離して開始できます。

Data Guard Brokerの移行では、次の主要なユースケースについて説明します。

PDBスイッチオーバーのユースケース - Data Guard CDBの既存のPDBに影響を与えずにPDBスイッチオーバー操作を起動する計画メンテナンスDR検証
PDBフェイルオーバーのユースケース - Data Guard CDB内の既存のPDBに影響を与えずにPDBフェイルオーバーを起動する計画外停止DR

ノート:

CDB内の他のPDBに影響を与えずに、アップグレードが不要な場合に単一のPDBを再配置するには、PDB再配置を使用したアップグレードなしの別のCDBへの単一PDBの移動(ドキュメントID 2771737.1)を参照してください。CDB内の他のPDBに影響を与えずに、アップグレードが必要な単一のPDBを再配置するには、次を参照してください。

PDBスイッチオーバーのユースケース

このPDBスイッチオーバーまたはDRテストのユースケースでは、PDBはOracle Data Guardで保護されたCDBから別のData Guardで保護されたCDBに移行されます。

このユースケースの一部として、ソースCDBのプライマリ・データベースとスタンバイ・データベースの両方のPDBのファイルは、宛先CDBのそれぞれのプライマリ・データベースとスタンバイ・データベースで直接使用されます。

ソースCDBには複数のPDBが含まれていますが、他のPDBは影響を受け入れられないため、1つのPDBに対してのみロール・トランジション・テストを実行します。移行を開始する前に、2番目のCDBを作成し、ソースCDBと同じデータベース・オプションを持つ必要があります。宛先CDBもData Guard構成にありますが、最初はPDBが含まれていません。対応する2つのプライマリ・データベースとスタンバイ・データベースは同じストレージを共有し、データ・ファイルの移動は実行されません。

前提条件

使用している環境が、ユースケースの前提条件を満たしていることを確認します。

Oracle Data Guard Broker CLI (DGMGRL)では、単一のフィジカル・スタンバイ・データベースを使用した構成のメンテナンスがサポートされます。

ここで説明する方法を使用して、移行するPDB (ソース)に対して、プライマリ・データベースとスタンバイ・データベースの両方のデータ・ファイルがソースにある既存のディレクトリ構造に物理的に残り、宛先CDBとそのスタンバイ・データベースによって消費されます。

必要なOracleパッチ/バージョン
- Oracle RDBMS 19c (19.15)以降
- スイッチオーバー・プロセスを管理するブローカ機能を提供するソースおよび宛先のCDB RDBMS Oracleホームにインストールされているパッチ33358233。Oracle RDBMS 19c (19.18)以降にパッチを適用する必要はありません。これにはパッチが含まれています。
- ソースおよび宛先CDB RDBMS Oracleホームにインストールされているパッチ34904997では、PDBフェイルオーバー・ユースケースの実行後にPDBを元の構成に移行する機能が提供されます。
構成
- DB_CREATE_FILE_DEST = ASM_Disk_Group
- DB_FILE_NAME_CONVERT=""
- STANDBY_FILE_MANAGEMENT=AUTO
- ソースと宛先のスタンバイCDBが同じクラスタで実行されている必要があります
- ソースと宛先のプライマリCDBは同じOracleホームから実行する必要があり、ソースと宛先のスタンバイCDBは同じOracleホームから実行する必要があります
- ソースと宛先のプライマリCDBが同じホストで実行されている必要があります
- ソースと宛先のプライマリ・データベースは同じASMディスク・グループを使用し、ソースと宛先のスタンバイ・データベースは同じASMディスク・グループを使用する必要があります
次へのアクセス権が必要です
- 宛先CDB sysdbaユーザーのパスワード
- スタンバイ・サイトのASM sysasmユーザーのパスワード(別名の管理用)
- TDEが有効な場合の宛先CDBの透過的データ暗号化(TDE)キーストアのパスワード

ノート:

PDBスナップショット・クローンおよびPDBスナップショット・クローンの親は、移行またはフェイルオーバーではサポートされていません。

複数のフィジカル・スタンバイ・データベースがある宛先プライマリ・データベースの場合、Data Guard構成のプライマリ・データベースにPDBを接続する場合のソース・スタンバイ・データベース・ファイルの再使用(ドキュメントID 2273829.1)の手動ステップを使用するか、スタンバイ・データベースのENABLED_PDBS_ON_STANDBY初期化パラメータを使用して、このプロセスによって管理されるスタンバイを制限する必要があります。ENABLED_PDBS_ON_STANDBYの使用の詳細は、『Oracle Data Guard概要および管理』のCDBのフィジカル・スタンバイの作成を参照してください。

移行されたソースPDBの既存のASM別名は、移行プロセス中にブローカによって管理されます。ASMではファイルごとに1つの別名のみが許可されるため、別の場所を指す既存の別名を削除し、正しい場所に新しい別名を作成する必要があります。

PDBスイッチオーバーの構成

次のステップで、「DRテスト」のPDBスイッチオーバーのユースケースを構成します。

次のステップに含まれるサンプル・コマンドでは、次のCDB名とPDB名を使用します。

CDB100 (ソースCDB)
- PDB001、PDB002、PDB003を含みます。PDB001はスイッチオーバー用に構成されます
CDB100_STBY (ソース・スタンバイCDB)
CDB200 (宛先CDB)
CDB200_STBY (宛先スタンバイCDB)

ステップ1: ソース・データベースでのPDB Clusterwareマネージド・サービスの抽出

CRSに追加されたソースPDB用に作成されたアプリケーションおよびエンド・ユーザー・サービスを決定します。

データベースに格納されていないデータベース・ロールなどの特定のサービス属性があるため、SRVCTL CONFIG SERVICEを使用して詳細属性をCRSから取得する必要があります。

プライマリPDBからサービス名を取得します(この例ではPDB001)。

PRIMARY_HOST $ sqlplus sys@cdb100 as sysdba
SQL> alter session set container=pdb001;
SQL> select name from dba_services;

返されるサービス名ごとに、DATABASE_ROLEを含む構成を取得します。
```
PRIMARY_HOST $ srvctl config service -db cdb100 -s SERVICE_NAME
```

ステップ2: 空のターゲット・データベースの作成

PDBの宛先となるソースCDB (CDB100)と同じクラスタに、空のCDB (この例ではCDB200)を作成します。

テスト期間中のPDBの使用をサポートするために、このCDBにリソースを割り当てます。

ステップ3: ターゲット・スタンバイ・データベースの作成

ターゲットCDBでOracle Data Guardを有効にして、スタンバイ・データベース(CDB200_STBY)を作成します。

スタンバイ・データベースは、ソース・スタンバイ・データベースと同じクラスタに存在する必要があります。

構成は次の図のようになります。

図multi-pdb-switch-1.pngの説明

ステップ4: PDBの移行

PDB (PDB001)をソースCDB (CDB100)から宛先CDB (CDB200)に移行します。

Oracle Data Guard Brokerコマンドライン(DGMGRL)を使用して、ソース・プライマリ・データベースへの接続を開始します。

このセッションは、ソース・プライマリCDBと宛先プライマリCDBの両方のインスタンスを含むホストで実行する必要があります。セッションはsysdbaユーザーで開始する必要があります。

ブローカCLIは、プライマリCDB環境のコマンドラインから実行し、ソース・プライマリCDBへの接続中に実行する必要があります。TNS別名を使用してソース・プライマリに接続する場合は、ブローカCLIセッションと同じホストで実行されているソース・プライマリ・インスタンスに接続する必要があります。

ブローカCLIを実行する際のホストおよび環境設定では、次のSQL*Net別名にアクセスできる必要があります。
- 宛先プライマリCDB - 作成されるPDB切断マニフェスト・ファイルにプラグイン操作でアクセスできるように、この別名で、ブローカCLIセッション/ソースのプライマリ・データベース・インスタンスと同じホスト上にある宛先プライマリ・インスタンスに接続する必要があります。
- 宛先スタンバイCDB。これはスタンバイ環境の任意のインスタンスに接続できます。
- スタンバイ・サイトのASMインスタンス。これはスタンバイ環境の任意のインスタンスに接続できます。
```
PRIMARY_HOST1 $ dgmgrl sys@cdb100_prim_inst1 as sysdba
```
  このセッションは、ソース・プライマリCDBと宛先プライマリCDBの両方のインスタンスを含み、sysdbaユーザーに接続されているホストで実行する必要があります。SCANではなく特定のホスト/インスタンスの組合せを使用して、目的のインスタンスに接続されるようにします。

DGMGRL MIGRATE PLUGGABLE DATABASEコマンドを実行します。

STANDBY FILESキーワードが必要です。

完全な出力を使用する例は「コマンドの完全な例と出力」を、コマンドライン引数の詳細はMIGRATE PLUGGABLE DATABASEを参照してください。

TDEを使用しないサンプル・コマンドの例:

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB200
 USING ‘/tmp/PDB001.xml’ CONNECT AS sys/password@cdb200_inst1
 STANDBY FILES sys/standby_asm_sys_password@standby_asm_inst1
 SOURCE STANDBY CDB100_STBY DESTINATION STANDBY CDB200_STBY ;

TDEを使用したサンプル・コマンドの例

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB200
 USING ‘/tmp/pdb001.xml’ CONNECT AS sys/password@cdb200_inst1
 SECRET "some_value" KEYSTORE IDENTIFIED BY "destination_TDE_keystore_passwd"
 STANDBY FILES sys/standby_asm_sys_password@standby_asm_inst1
 SOURCE STANDBY cdb100_stby DESTINATION STANDBY cdb200_stby;

コマンドが実行されると、次のようになります。

資格証明および接続文字列が正しいことを確認するために、宛先データベースおよびASMインスタンスに接続します
様々な事前チェックの実行 - 事前チェックが失敗した場合、コマンドは処理を停止してユーザーに制御を戻し、エラーが返され、ターゲットCDBに変更は加えられません
宛先スタンバイCDBにフラッシュバック保証付きリストア・ポイントを作成します。これには、REDO適用の短い停止と開始が必要です
ソース・プライマリのPDBをクローズします
ソース・プライマリのPDBを切断します。TDEが使用中の場合は、切断操作の一部として生成されたマニフェスト・ファイルにキーが含まれます
ソース・プライマリ・データベースのPDBをKEEP DATAFILES句で削除し、ソース・ファイルが削除されないようにします
PDBの削除REDOがソース・スタンバイ・データベースに適用されるのを待機します。ファイルがソース・スタンバイ・データベースによって所有されているため、削除REDOが適用されるまで待機する必要があります

このコマンドは、最大でTIMEOUT分(デフォルトは10)待機します。REDOが適用されていない場合、コマンドは失敗し、手動でプロセスを完了する必要があります。
スタンバイのPDBファイルのASM別名を管理し、既存の別名を削除して、必要に応じて新しい別名を作成します。スタンバイ・ファイルが正しい場所にすでに存在する場合は、PDBのスタンバイ・コピーのすべての別名が削除されます
PDBを宛先のプライマリCDBに接続します。TDEが使用されている場合、キーはプラグインの一部として宛先のプライマリ・キーストアにインポートされます
プラグイン操作のREDOを宛先CDBに送信し適用します。この宛先CDBは、作成された別名を使用して(必要な場合)それらのファイルにアクセスし、それらをスタンバイ・データベースに組み込みます
REDO適用を使用してスタンバイ・ファイルが宛先スタンバイに追加されたことを検証します
宛先プライマリ・データベースでPDBをオープンします
REDO適用を停止します
宛先スタンバイ・データベースからフラッシュバック保証付きリストア・ポイントを削除します
TDEが有効な場合、REDO適用は停止したままになります。TDEが有効になっていない場合、REDO適用は再開されます

ステップ5: 移行後 - オプションのTDE構成ステップおよび適用の再起動

TDEが使用中の場合、新しいTDEキーを管理できるように、宛先スタンバイ(CDB200_STBY)のブローカMIGRATE PLUGGABLE DATABASE操作によってREDO適用が停止されます。宛先プライマリ(CDB200)のキーストアを宛先スタンバイ・キーストアにコピーし、REDO適用を開始します。

SOURCE_HOST $ scp DESTINATION_PRIMARY_WALLET_LOCATION/*>
 DESTINATION_HOST:DESTINATION_STANDBY_WALLET_LOCATION/

$ dgmgrl sys/password@CDB200 as sysdba
DGMGRL> edit database cdb200_stby set state=’APPLY-ON’;

ステップ6: 移行後 - サービスの有効化

PDBのアプリケーション・サービスをCluster Ready Services (CRS)に追加し、PDBに関連付けて宛先CDBでデータベース・ロールを修正し、対応するサービスをソースCDBから削除します。

プライマリ環境とスタンバイ環境の両方のサービスごとに、次を実行します:

PRIMARY_HOST $ srvctl add service -db cdb200 -s SERVICE_NAME
 -pdb pdb001 -role [PRIMARY|PHYSICAL_STANDBY]….
STANDBY_HOST $ srvctl add service -db cdb200_stby -s SERVICE_NAME
 -pdb pdb001 -role [PRIMARY|PHYSICAL_STANDBY]….

PRIMARY_HOST $ srvctl remove service -db cdb100 -s SERVICE_NAME
STANDBY_HOST $ srvctl remove service -db cdb100_stby -s SERVICE_NAME

適切なデータベース・ロールに必要なサービスを開始します。
1. 各PRIMARYロールのデータベース・サービスを開始します
```
PRIMARY_HOST $ srvctl start service -db cdb200 -s SERVICE_NAME
```
2. 各PHYSICAL_STANDBYロールのデータベース・サービスを開始します。
```
STANDBY_HOST $ srvctl start service -db cdb200_stby -s SERVICE_NAME
```

ステップ7: PDBロール・トランジション・テストの実行

移行の完了後、宛先CDB (CDB200)のPDBで必要なOracle Data Guardロール・トランジションまたはDRテストを実行できるようになります。ソースCDB (CDB100)内の他のPDBは影響を受けません。

また、ソースCDBと宛先CDBの両方に対するData Guardの利点(DR準備状況、データ破損用の自動ブロック・メディア・リカバリ、バインドされたリカバリ時間へのファスト・スタート・フェイルオーバー、論理破損に対する書込みの欠落検出、スタンバイへの読取りのオフロードによるスケーリングの削減、プライマリの影響の削減など)を維持します。

DGMGRLを使用して宛先CDBに接続し、スイッチオーバーを実行します。
```
$ dgmgrl sys@cdb200 as sysdba
DGMGRL> switchover to CDB200_STBY;
```

PDBのDRテストを引き続き実行できます。

PDBのDRテストが完了したら、元に戻してPDBを元のソースCDBに戻すことができます。

DGMGRLを使用して宛先CDB (CDB200)に接続し、スイッチバック操作を実行します。
```
$ dgmgrl sys@cdb200 as sysdba
DGMGRL> switchover to CDB200;
```

ステップ8: PDBを元のCDBに戻す

移行およびロール・トランジション・テスト後に、このCDBの元の構成に戻し、PDBを元のData Guard構成に戻し、スタンバイ・データベース・ファイルを再度自動的にメンテナンスします。Data Guard Brokerの移行では、移行プロセスの一部として削除または作成する必要がある別名が処理されます。

完全な出力の例については、「コマンドの完全な例と出力」を参照してください。

Data Guard Brokerコマンドライン(DGMGRL)を使用して、ソース・プライマリへの接続を開始します

$ dgmgrl 
DGMGRL> connect sys/@cdb200_inst1 as sysdba

TDEを使用しないコマンド

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB100
 USING ‘/tmp/PDB001_back.xml’ CONNECT AS sys/password@cdb100_inst1
 STANDBY FILES sys/standby_asm_sys_password@standby_asm_inst
 SOURCE STANDBY CDB200_STBY DESTINATION STANDBY CDB100_STBY ;

TDEを使用したコマンド

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB100
 USING ‘/tmp/PDB001_back.xml’ CONNECT AS sys/password@cdb100_inst1
  SECRET "some_value" KEYSTORE
 IDENTIFIED BY "destination_TDE_keystore_passwd"
 STANDBY FILES sys/standby_asm_sys_password@standby_asm_inst
 SOURCE STANDBY CDB200_STBY DESTINATION STANDBY CDB100_STBY ;

ステップ9: 移行後 - サービスの有効化

PDBのアプリケーション・サービスをCluster Ready Services (CRS)に追加し、PDBに関連付けて宛先CDB (CDB100)でデータベース・ロールを修正し、対応するサービスをソースCDB (CDB200)から削除します。

プライマリ環境とスタンバイ環境の両方のサービスごとに、次を実行します:

PRIMARY_HOST $ srvctl add service -db cdb100 -s SERVICE_NAME
 -pdb pdb001 -role [PRIMARY|PHYSICAL_STANDBY]….
STANDBY_HOST $ srvctl add service -db cdb100_stby -s SERVICE_NAME
 -pdb pdb001 -role [PRIMARY|PHYSICAL_STANDBY]….

<PRIMARY_HOST>PRIMARY_HOST $ srvctl remove service -db cdb200 -s SERVICE_NAME
STANDBY_HOST $ srvctl remove service -db cdb200_stby -s SERVICE_NAME

適切なデータベース・ロールに必要なサービスを開始します。
1. 各PRIMARYロールのデータベース・サービスを開始します。
```
PRIMARY_HOST $ srvctl start service -db cdb100 -s SERVICE_NAME
```
2. 各PHYSICAL_STANDBYロールのデータベース・サービスを開始します。
```
STANDBY_HOST $ srvctl start service -db cdb100_stby -s SERVICE_NAME
```

PDBフェイルオーバーのユースケース

CDB、クラスタまたはサイト障害を含む実際の障害では、常に完全なCDB Data Guardフェイルオーバー操作を利用して停止時間をバインドし、潜在的なデータ損失を減らし、管理ステップを削減する必要があるため、これは非常にまれなユースケースです。

論理的またはデータの破損が広範囲に及ぶ場合や、データベースのハングが拡大しても、CDB Data Guardロール・トランジション操作を発行する方が効率的です。ソース環境が疑わしい場合があり、根本原因の分析に時間がかかる可能性があるためです。

PDBのフェイルオーバー操作が有用なのはいつですか。アプリケーションでデータの整合性などの致命的なエラーや破損エラーが発生した場合、または単に(システム・リソースによるものではなく)適切に実行されていない場合に、PDBフェイルオーバーが有用である場合があります。ソースCDBおよび対応するPDBがまだ正常に実行されていて、スタンバイが障害の発生したターゲットPDBのエラーを受信しなかった場合、ソース・プライマリCDBの他のPDBに影響を与えることなく、障害の発生したターゲットPDBのみをスタンバイからフェイルオーバーできます。

次のプロセスでは、スタンバイの正常なPDBをソースCDBスタンバイ(CDB100_STBY)から空の宛先CDB(CDB200)に移行する障害の発生したPDBのPDBフェイルオーバーを設定する方法について説明します。移行を開始する前に、宛先CDBを作成し、ソース・スタンバイCDBと同じデータベース・オプションを持つ必要があります。宛先CDBにはPDBが含まれていません。ソースCDBと宛先CDBは同じストレージを共有し、データ・ファイルの移動は実行されません。

前提条件

使用している環境が、ユースケースの前提条件を満たしていることを確認します。

前述のPDBスイッチオーバーのユースケースにリストされている前提条件に加えて、フェイルオーバーのための次の前提条件が存在します。

Oracleでは、移行プロセスを開始する前に、PDBにアクセスしているプライマリとスタンバイの両方のサービスを停止することをお薦めします。

DGMGRL MIGRATE PLUGGABLE DATABASEコマンドを実行する前にPDBがプライマリでクローズされていない場合、データが失われることを示すエラーが返されます。プライマリでPDBをクローズすると、この問題が解決されます。PDBへの既存のすべての接続は、移行の一部として終了します。

宛先CDBがすでに存在し、スタンバイ・サイトで正しくパッチが適用されている場合、PDBを移動するプロセス全体を15分未満で完了できます。

追加の考慮事項

次のステップでは、ソースCDBデータベース(移行の場合はプライマリ、フェイルオーバーの場合はスタンバイ)と宛先CDBデータベースが同じストレージにアクセスできることを前提としているため、データ・ファイルのコピーは不要です。

フェイルオーバー操作には、ソースCDBスタンバイにOracle Active Data Guardが必要です。
ソースCDBと同じクラスタ上のPDBの宛先となる空のCDBを作成します。
移行を実行する前に、PDBのTEMPファイルがソースCDBスタンバイにすでに作成されていることを確認します。
宛先CDBが新しいOracleリリースである場合、PDBは接続されますが、移行後のタスクとして手動アップグレードを実行できるようにクローズされたままになります。
処理が完了したら、ソース・データベースから残りのデータベース・ファイルをクリーンアップすることが必要になる場合があります。
宛先CDBでの接続操作はSTANDBYS=NONEで実行されるため、移行の完了時に任意のスタンバイ・データベースでリカバリを手動で有効にする必要があります。PDBのリカバリを有効化するステップは、Oracle Multitenantでの遅延PDBリカバリおよびSTANDBYS=NONE機能の使用(ドキュメントID 1916648.1)を参照してください。

PDBフェイルオーバーの構成

DR PDBフェイルオーバーのユースケースは、次のステップで構成します。

このユースケースでは、トポロジの例に3つのPDB (PDB001、PDB002、PDB003)を持つソース・プライマリCDB100があります。CDB100には、Data Guardフィジカル・スタンバイ(CDB100_STBY)もあります。

スタンバイCDBと同じ環境で、ソースPDBのうちのいずれかの新しいホストになる読取り/書込みデータベースである新しいCDB (CDB200)を作成します。

ステップ1: ソース・データベースでのPDB Clusterwareマネージド・サービスの抽出

CRSに追加されたソースPDB用に作成されたアプリケーションおよびエンド・ユーザー・サービスを決定します。

プライマリPDBからサービス名を取得します(この例ではPDB002)。

PRIMARY_HOST $ sqlplus sys@cdb100 as sysdba
SQL> alter session set container=pdb002;
SQL> select name from dba_services;

返されるサービス名ごとに、DATABASE_ROLEを含む構成を取得します。
```
PRIMARY_HOST $ srvctl config service -db cdb100 -s SERVICE_NAME
```

ステップ2: 空のターゲット・データベースの作成

ソース・スタンバイCDB (CDB100_STBY)と同じクラスタに、PDB (PDB002)の宛先となる空のCDB (この例ではCDB200)を作成します。

このCDBにリソースを割り当てて、PDBがこのCDBに残っている間はPDBの使用をサポートします。

ステップ3: 空のターゲット・データベースのOracle Data Guard構成の作成

Data Guard Brokerが新しいCDB (CDB200)にアクセスできるようにするには、Data Guard構成の一部である必要があります。この構成は、プライマリ・データベースのみで構成できます。

ブローカ用にデータベースを構成します。

STANDBY_HOST $ sqlplus sys@cdb200 as sysdba
SQL> alter system set dg_broker_config_file1='+DATAC1/cdb200/dg_broker_1.dat';
SQL> alter system set dg_broker_config_file2='+DATAC1/cdb200/dg_broker_2.dat';
SQL> alter system set dg_broker_start=TRUE;

構成を作成し、データベースをプライマリとして追加します。

STANDBY_HOST $ dgmgrl 
DGMGRL> connect sys@cdb200 as sysdba
DGMGRL> create configuration failover_dest as primary database is cdb200
 connect identifier is 'cdb200';
DGMGRL> enable configuration;

構成は次の図のようになります。

図multi-pdb-fail-1.pngの説明

この図では、ソース・プライマリCDB (CDB100)およびすべてのPDBが正常に実行されています。ソース・スタンバイCDB (CDB100_STBY)をActive Data Guardモードで実行して、他のPDBに影響を与えずに切断操作を正常に実行できるようにする必要があります。宛先CDB (CDB200)は現在空です。

次の図に示すように、ソースのプライマリPDB (PDB002)の1つで障害が発生し、長いリカバリ期間が必要であるが、障害は他のPDB (PDB001およびPDB003)には影響せず、ソースCDBのスタンバイはエラーなしでREDOを引き続き適用するとします。

図multi-pdb-fail-failure.pngの説明

この構成では、スタンバイ・サイト(CDB100_STBY)のPDB002のファイルを使用して宛先CDB (CDB200)に接続し、読取り/書込みアプリケーション・アクセスをリストアしてから、ソース・プライマリCDB (CDB100)から障害のあるPDB (PDB002)を削除します。ネイティブの切断には読取り/書込みCDBが必要であり、このシナリオではスタンバイから抽出しているため、これはネイティブの切断操作ではありません。

ステップ4: 失敗したPDBのサービスの停止

必須ではありませんが、移行するPDB (PDB002)に関連するソース・プライマリ・データベースとスタンバイ・データベースの両方ですべてのサービスを停止します。

次のコマンドは、CRSで定義されているすべてのサービスを停止しますが、PDBはクローズしません。

SOURCE_PRIMARY $ srvctl stop service -d CDB100 -pdb PDB002
SOURCE_PRIMARY $ srvctl stop service -d CDB100_STBY -pdb PDB002

ステップ5: スタンバイからのPDBのフェイルオーバー

スタンバイCDB (CDB100_STBY)から宛先CDB (CDB200)に、障害のあるPDB (PDB002)をフェイルオーバーします。

ソース構成スタンバイ・データベース(CDB100_STBY)に接続するDGMGRLセッションを開始します。

次のようなものを使用して、ソース・スタンバイ・データベースにSYSDBAとして接続する必要があります。
```
$ dgmgrl
DGMGRL> connect sys@cdb100_stby_inst1 as sysdba 
```
DGMGRL MIGRATE PLUGGABLE DATABASEコマンドを実行してフェイルオーバーを実行します。

ノート:
DGMGRL FAILOVERコマンドの形式は、MIGRATE PLUGGABLE DATABASEコマンドと同じです。
フェイルオーバー操作にはSTANDBY FILESキーワードを使用しないでください。

データ損失が検出され(最初のSYSTEM表領域スタンバイ・データ・ファイルのヘッダーのSCNがプライマリ内のファイルの対応するSCNより小さい)、IMMEDIATEが指定されていない場合、MIGRATE PLUGGABLE DATABASEコマンドは失敗します。最も一般的な理由は、プライマリCDBのPDBがまだオープンしており、フェイルオーバーを試行する前にプライマリのPDBをクローズする必要があるためです。

SCNの相違を解決するか、IMMEDIATE句でデータ損失を受け入れる必要があります。
PDBをフェイルオーバーします

完全な出力の例については、「コマンドの完全な例と出力」を参照してください。

CONNECT別名は、ブローカCLIセッション/ソース・スタンバイ・データベース・インスタンスと同じホスト上にある宛先プライマリ・インスタンスに接続し、作成されるPDB切断マニフェスト・ファイルに接続操作でアクセスできるようにする必要があります。

ノート:
次の例では、ブローカがCDB200_INST1インスタンスに接続しようとすると、宛先CDB (CDB200)のSYSDBAパスワードの入力を求められます。
- TDE対応でない環境の場合:
```
DGMGRL> migrate pluggable database PDB002 to container CDB200
 using '/tmp/PDB002.xml>' connect as sys@”CDB200_INST1”; 
```
- TDE対応の環境の場合:
```
DGMGRL> migrate pluggable database PDB002 to container CDB200
 using '/tmp/PDB002.xml>' connect as sys@”CDB200_INST1”
 secret “some_value”
 keystore identified by “destination_keystore_password”
 keyfile ‘/tmp/pdb002_key.dat’
 source keystore identified by “source_keystore_password”;
```
  ノート:
  TDE環境では、SECRET、KEYSTORE、KEYFILEまたはSOURCE KEYSTOREがコマンドラインで指定されていない場合、MIGRATE PLUGGABLE DATABASEコマンドは失敗します。

宛先への接続が確立されると、コマンドは次のようになります。

フェイルオーバー操作に必要なすべての検証を実行します
TDEが有効な場合、ソース・スタンバイ・キーストアからPDBのTDEキーをエクスポートします
ソース・スタンバイで実行中のREDO適用を停止します
DBMS_PDB.DESCRIBEコマンドを使用して、コマンドで指定された場所のスタンバイにマニフェストを作成します
ソース・スタンバイでPDBのリカバリを無効にします
TDEが有効な場合は、TDEキーを宛先CDBキーストアにインポートして、プラグインを正常に実行できるようにします
スタンバイのデータ・ファイル(NOCOPY句)およびSTANDBYS=NONEを使用して、宛先データベースにPDBを接続します。
宛先プライマリ・データベースのすべてのインスタンスでPDBをオープンします
TDEが有効な場合は、PDBのコンテキストでADMINISTER KEY MANAGEMENT USE KEYを発行して、インポートされたキーとPDBを関連付けます。
ソース・プライマリからPDBを切断します。切断でエラーが発生した場合、手動でクリーンアップを実行するようにメッセージが提示されます
切断が成功した場合は、KEEP DATAFILES句を使用してソース・プライマリからPDBを削除します。これにより、すべてのソース・スタンバイ・データベースのPDBも削除されます。

ステップ6: 移行後 - サービスの有効化

プライマリ環境とスタンバイ環境の両方のサービスごとに、次を実行します:

DESTINATION_PRIMARY_HOST $ srvctl add service -db cdb200 -s SERVICE_NAME
 -pdb pdb002 -role [PRIMARY|PHYSICAL_STANDBY]….

SOURCE_PRIMARY_HOST $ srvctl remove service -db cdb100 -s SERVICE_NAME
SOURCE_STANDBY_HOST $ srvctl remove service -db cdb100_stby -s SERVICE_NAME

適切なデータベース・ロールに必要なサービスを開始します。

各PRIMARYロールのデータベース・サービスを開始します
```
DESTINATION_PRIMARY_HOST $ srvctl start service -db cdb200 -s SERVICE_NAME
```

ステップ7: PDBのバックアップ

将来リカバリできるように、宛先CDB (CDB200)のPDBをバックアップします。

DESTINATION_PRIMARY_HOST $ rman
RMAN> connect target sys@cdb200
RMAN> backup pluggable database pdb002;

ステップ8: PDBのリカバリのオプションでの有効化

Oracle Multitenantでの遅延PDBリカバリおよびSTANDBYS=NONE機能の使用(ドキュメントID 1916648.1)のステップに従って、スタンバイ・データベースでのPDBのリカバリを有効にし、可用性および障害時リカバリの要件を確立します。

ステップ9: オプションでの移行

「PDBスイッチオーバーの構成」の移行ステップを参照してください。

エラーの解決

宛先プライマリCDBへの接続が成功したが、宛先スタンバイでファイルが見つからないなどの問題がある場合、宛先CDBスタンバイ・データベースで作成されたGRPを使用して解決に役立てることができます。

ブローカは、GRPを削除せずに実行を終了するスタンバイでエラーを検出した場合、エラーの解決に使用できます。GRP名は、CLIコマンド実行の出力に表示されます。

この方法を使用する前に、前提条件セクションのすべてのパッチが適用されていることを確認します。

自動的に起動しないように、Data Guard BrokerでのREDO適用をオフにします

DGMGRL> edit database CDB200_STBY set state='APPLY-OFF';
宛先CDBスタンバイをマウント・モードで再起動し、RAC環境で1つのインスタンスのみが実行されていることを確認します。
- Oracle RACの場合
  $ srvctl stop database –d cdb200_stby –o immediate
  
  $ srvctl start instance –d cdb200_stby –i cdb200s1 –o mount
- SIDBの場合
  SQL> shutdown immediate
  
  SQL> startup mount
宛先CDBスタンバイ・データベースのPDBに接続し、PDBのリカバリを無効にします。

SQL> alter session set container=pdb001;

SQL> alter pluggable database disable recovery;
宛先CDBスタンバイ・データベースのCDB$rootに接続し、スタンバイ・データベースをフラッシュバックします。
SQL> alter session set container=cdb$root;

SQL> flashback database to restore point <GRP from execution>;
REDO適用の失敗の原因となった問題を修復します(ASM別名がないなど)。
CDBスタンバイでマウント・モードのままにして、REDO適用を開始します。

SQL> recover managed standby database disconnect;

REDO適用では、新しく接続されたPDBのすべてのファイルの再スキャンを含め、GRPからのすべてのREDOの適用が開始されます。フラッシュバックGRPは、宛先CDBスタンバイを、PDBがスタンバイに認識されていないポイントにロールバックするため、PDBのリカバリの無効化もバックアウトされます。

ステップ1から6は、すべてのファイルがスタンバイに追加され、追加のREDOが適用されるまで、必要な回数繰り返すことができます。この時点で、次のようになります。

リカバリを停止します

DGMGRL> edit database CDB200_STBY set state='APPLY-OFF';
宛先CDBスタンバイ・データベースのCDB$rootに接続し、宛先スタンバイ・データベースからGRPを削除します。

SQL> drop restore point <GRP from execution>;
REDO適用を再開します

DGMGRL> edit database CDB200_STBY set state='APPLY-ON';

問題が続いており、問題解決中にCDBスタンバイ・データベースがスタンバイ内の追加PDBの保護を維持する必要がある場合:

前述のようにPDBのリカバリを無効にします
CDBスタンバイ内の他のPDBを保護するためにREDO適用を再開します
Oracle Multitenantでの遅延PDBリカバリおよびSTANDBYS=NONE機能の使用(ドキュメントID 1916648.1)のリカバリの有効化のステップに従って、失敗したPDBのリカバリを有効にします。
宛先CDBスタンバイからGRPを削除します。

テスト中に、解決できないスタンバイで繰返しエラーが発生した場合:

スタンバイでのREDO適用のためのPDB操作のデバッグを有効にします。

SQL> alter system set "_pluggable_database_debug"=256 comment='set to help debug PDB plugin issues for PDB100, reset when done' scope=both;
前述のステップに従って、宛先CDBスタンバイ・データベースをフラッシュバックします。
REDO適用を再開します。

新しい障害の後、REDO適用を実行していたスタンバイ・ホストからREDO適用トレース・ファイル(..../trace/<SID>_pr*.trc)を収集し、バグをオープンします。

デバッグが完了すると、次のようになります。

パラメータをリセットしてデバッグをオフにします。

SQL> alter system reset "_pluggable_database_debug" scope=spfile;
CDBスタンバイ・データベースをバウンスします。

リファレンス

次の例では、DGMGRL MIGRATEコマンドの一部として、コマンドを実行する際に表示されるものとは異なる出力が生成される場合があることに注意してください。これは、お使いの環境でDGMGRLが事前チェックを実行して検出したPDBやアイテムの状態が異なることによりますまた、Oracleはバグ修正を含むメッセージ・ファイルを送信しないため、完全なメッセージを表示するかわりに、次のようなメッセージを受信する可能性があります。

Message 17241 not found; product=rdbms; facility=DGM

これは、エラーや問題ではなく、表示するテキストがメッセージ・ファイルにないことを意味します。すべてのメッセージが、すべての修正を含む最初のリリースで完全に表示されます。

コマンドの完全な例と出力

次に、コマンドの例と出力を示します。

例35-1 TDEを使用しない移行

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB200
 USING ‘/tmp/PDB001.xml’ CONNECT AS sys/password@cdb200_inst1
 STANDBY  FILES sys/standby_asm_sys_passwd@standby_asm_inst1
 SOURCE STANDBY CDB100_STBY DESTINATION STANDBY CDB200_STBY ;

Beginning migration of pluggable database PDB001.
Source multitenant container database is CDB100.
Destination multitenant container database is CDB200.
Connecting to "+ASM1".
Connected as SYSASM.
Stopping Redo Apply services on multitenant container database cdb200_stby.
The guaranteed restore point "<GRP name>" was created for multitenant container database "cdb2001_stby".
Restarting redo apply services on multitenant container database cdb200_stby.
Closing pluggable database PDB001 on all instances of multitenant container database CDB100.
Unplugging pluggable database PDB001 from multitenant container database cdb100.
Pluggable database description will be written to /tmp/pdb001.xml
Dropping pluggable database PDB001 from multitenant container database CDB100.
Waiting for the pluggable database PDB001 to be dropped from standby multitenant container database cdb100_stby.
Creating pluggable database PDB100 on multitenant container database CDB200.
Checking whether standby multitenant container database cdb200_stby has added all data files for pluggable database PDB001.
Opening pluggable database PDB001 on all instances of multitenant container database CDB200.
The guaranteed restore point "<GRP_name>" was dropped for multitenant container database "cdb200_stby".
Migration of pluggable database PDB001 completed.

Succeeded.

例35-2 TDEを使用した移行

DGMGRL> MIGRATE PLUGGABLE DATABASE PDB001 TO CONTAINER CDB200 USING ‘/tmp/pdb001.xml’
 CONNECT AS sys/password@cdb200_inst1 SECRET "some_value"
 KEYSTORE IDENTIFIED BY "destination_TDE_keystore_passwd"
 STANDBY FILES sys/standby_ASM_sys_passwd@standby_asm_inst1
 SOURCE STANDBY cdb100_stby DESTINATION STANDBY cdb200_stby;

Master keys of the pluggable database PDB001 to need to be migrated.
Keystore of pluggable database PDB001 is open.
Beginning migration of pluggable database PDB001.
Source multitenant container database is cdb100.
Destination multitenant container database is cdb200.
Connecting to "+ASM1".
Connected as SYSASM.
Stopping Redo Apply services on multitenant container database cdb200_stby.
The guaranteed restore point "..." was created for multitenant container database "cdb200_stby".
Restarting redo apply services on multitenant container database cdb200_stby.
Closing pluggable database PDB001 on all instances of multitenant container database cdb100.
Unplugging pluggable database PDB001 from multitenant container database cdb100.
Pluggable database description will be written to /tmp/pdb001.xml
Dropping pluggable database PDBT001 from multitenant container database cdb100.
Waiting for the pluggable database PDB001 to be dropped from standby multitenant container
database cdb100_stby.
Creating pluggable database PDB1001 on multitenant container database cdb200.
Checking whether standby multitenant container database cdb200_stby has added all data files for pluggable database PDB001.
Stopping Redo Apply services on multitenant container database cdb200_stby.
Opening pluggable database PDB001 on all instances of multitenant container database cdb400.
The guaranteed restore point "..." was dropped for multitenant container database "cdb200_stby".

Please complete the following steps to finish the operation:
1. Copy keystore located in <cdb200 primary keystore location> for migration destination primary database to <cdb200 standby keystore location> for migration destination standby database.
2. Start DGMGRL, connect to multitenant container database cdb200_stby, and issue command "EDIT DATABASE cdb200_stby SET STATE=APPLY-ON".
3. If the clusterware is configured on multitenant container databases cdb200 or cdb200_stby, add all non-default services for the migrated pluggable database in cluster ready services.
Migration of pluggable database PDB001 completed.

Succeeded.

例35-3 TDEを使用しないフェイルオーバー

DGMGRL> migrate pluggable database PDB002 immediate to container CDB200
 using '/tmp/<pdb002.xml>';
Username: USERNAME@cdb200
Password:
Connected to "cdb200"
Connected as SYSDBA.

Beginning migration of pluggable database pdb002.
Source multitenant container database is cdb100_stby.
Destination multitenant container database is cdb200.

Connected to "cdb100"
Closing pluggable database pdb002 on all instances of multitenant container database cdb100.
Continuing with migration of pluggable database pdb002 to multitenant container database cdb200.
Stopping Redo Apply services on source multitenant container database cdb100_stby.
Succeeded.
Pluggable database description will be written to /tmp/pdb002.xml.
Closing pluggable database pdb002 on all instances of multitenant container database cdb100_stby.
Disabling media recovery for pluggable database pdb002.
Restarting redo apply services on source multitenant container database cdb100_stby.
Succeeded.
Creating pluggable database pdb002 on multitenant container database cdb200.
Opening pluggable database pdb002 on all instances of multitenant container database cdb200.
Unplugging pluggable database pdb002 from multitenant container database cdb100.
Pluggable database description will be written to /tmp/pdb002_temp.xml.
Dropping pluggable database pdb002 from multitenant container database cdb100.
Unresolved plug in violations found while migrating pluggable database pdb002 to multitenant container database cdb200.
Please examine the PDB_PLUG_IN_VIOLATIONS view to see the violations that need to be resolved.
Migration of pluggable database pdb002 completed.
Succeeded.

例35-4 TDEを使用したフェイルオーバー

ノート: 出力内のORA-46655エラーは無視できます。

DGMGRL> migrate pluggable database PDB002 to container CDB200
 using '/tmp/PDB002.xml>' connect as sys@”CDB200” secret “some_value”
 keystore identified by “destination_keystore_password” keyfile ‘/tmp/pdb002_key.dat’
 source keystore identified by “source_keystore_password”;
Connected to "cdb200"
Connected as SYSDBA.
Master keys of the pluggable database PDB002 need to be migrated.
Keystore of pluggable database PDB002 is open.

Beginning migration of pluggable database PDB002.
Source multitenant container database is adg.
Destination multitenant container database is cdb200.

Connected to "cdb1001"
Exporting master keys of pluggable database PDB002.
Continuing with migration of pluggable database PDB002 to multitenant container database cdb200.
Stopping Redo Apply services on multitenant container database adg.
Pluggable database description will be written to /tmp/PDB002.xml.
Closing pluggable database PDB002 on all instances of multitenant container database adg.
Disabling media recovery for pluggable database PDB002.
Restarting redo apply services on multitenant container database adg.
Unplugging pluggable database PDB002 from multitenant container database cdb100.
Pluggable database description will be written to /tmp/ora_tfilSxnmva.xml.
Dropping pluggable database PDB002 from multitenant container database cdb100.
Importing master keys of pluggable database PDB002 to multitenant container database cdb200.
Creating pluggable database PDB002 on multitenant container database cdb200.
Opening pluggable database PDB002 on all instances of multitenant container database cdb200.
ORA-46655: no valid keys in the file from which keys are to be imported

Closing pluggable database PDB002 on all instances of multitenant container database cdb200.
Opening pluggable database PDB002 on all instances of multitenant container database cdb200.

Please complete the following steps to finish the operation:
If the Oracle Clusterware is configured on multitenant container database CDB200, add all non-default services for the migted pluggable database in Cluster Ready Services.

Migration of pluggable database PDB002 completed.
Succeeded.

キーワード定義

DGMGRL MIGRATEコマンドのキーワードを次に説明します。

構文

DGMGRL> MIGRATE PLUGGABLE DATABASE pdb-name
TO CONTAINER dest-cdb-name
USING XML-description-file
CONNECT AS { /@dest-cdb-connect-identifer |
 dest-cdb-user/dest-cdb-password@dest-cdb-connect-identifier}
[SECRET “secret” KEYSTORE IDENTIFIED BY ( EXTERNAL STORE | wallet-password) ;]
STANDBY FILES { /@asm-instance-connect-identifer |
 sysasm-user/sysasm-password@asm-instance-connect-identifier}
SOURCE STANDBY source-standby-cdb-name
DESTINATION STANDBY dest-standby-cdb-name
[TIMEOUT timeout]

これらは、PDBの移行コマンドで使用されるキーワード定義です

pdb-name - 移行対象のPDBの名前。
dest-cdb-name - 移行対象のPDBを受け入れるCDBの一意のデータベース名。
XML-description-file - 移行対象のPDBの説明が含まれているXMLファイル。このファイルは、MIGRATE PLUGGABLE DATABASEコマンドで実行されたSQL文によって自動的に作成されます。このファイルの場所には、ソースと宛先の両方のプライマリ・データベース・インスタンスで直接アクセスできる必要があります。コマンドの実行前に存在することはできません。
dest-cdb-user - 宛先CDBへのSYSDBAアクセス権があるユーザーの名前。
dest-cdb-password - dest-cdb-userに指定されているユーザー名に関連付けられたパスワード。
dest-cdb-connect-identifier - 宛先CDBへの接続に使用するOracle Net接続識別子。
secret - ソースPDBのエクスポートされた暗号化キーを含むエクスポート・ファイルを暗号化するために使用される単語。この句は、TDE対応環境でのみ必要です。
keyfile - ソースPDBのエクスポートされた暗号化キーを含むデータ・ファイル。このファイルは、フェイルオーバー・ユースケースにおいてMIGRATE PLUGGABLE DATABASEコマンドで実行されたSQL文によって作成されます。このファイルの場所には、ソース・スタンバイ・インスタンスおよび宛先プライマリ・インスタンスによって直接アクセスできる必要があります。
wallet-password - 暗号化キーを含む宛先CDBキーストアのパスワード。これは、ソースPDBがTDE対応環境でパスワード・キーストアを使用して暗号化された場合に必要です。
asm-instance-connect-identifier - ソース・スタンバイ・データベース・ファイルがあるASMインスタンスへの接続識別子。
sysasm-user - ASMインスタンスに対するSYSASM権限があるユーザー。
sysasm-password - sysasm-userのパスワード。
source-standby-cdb-name - 移行ソースCDBのスタンバイ・データベースのDB_UNIQUE_NAME。
dest-standby-cdb-name - 移行先CDBのスタンバイ・データベースのDB_UNIQUE_NAME。
timeout - 移行中に宛先スタンバイ・データベースでデータ・ファイルが取得されるまでの待機時間のタイムアウト値(秒)。これはオプションです。TIMEOUT句を省略した場合のデフォルトは5分です。

メッセージ

次に、DGMGRL MIGRATE関数によって生成される可能性があるメッセージのリストを示します。

一般的な処理の場合

17180 - 「移行操作を開始する前に、プラガブル・データベース%sをオープンする必要があります。」

17217 - 「ソース・マルチテナント・コンテナ・データベース(%(1)s)が、%(2)s以外のバージョンのOracleを実行する物理スタンバイである場合、移行を実行できません。」

17235 - 「プラガブル・データベース%sを切断できなかった理由を調査してください。」

17236 - 「問題を解決し、データベース%sからプラガブル・データベースを手動で切断して削除してください。」

17237 - 「プラガブル・データベース%sの移行が完了しました。」

17238 - 「プラガブル・データベース%sの移行が警告付きで完了しました。」

17239 - 「プラガブル・データベース%sの移行に失敗しました。」

17240 - 「プラガブル・データベース%(1)s (マルチテナント・コンテナ・データベース%(2)s)のメディア・リカバリが無効化されています。」

17241 - 「警告: ソースまたは宛先のマルチテナント・コンテナ・データベースで、ローカルUNDOが有効化されていません。」

17242 - 「スナップショットの子または親であるため、プラガブル・データベース%sからの移行はできません。」

17243 - 「より高いバージョンのOracleが稼働しているデータベースに移行されたため、プラガブル・データベース%sをオープンできませんでした。」

17244 - 「プラガブル・データベースをオープンする前に適切なアップグレード手順を実行してください。」

17245 - 「指定されたファイルの場所(%s)はアクセスできません。」

17246 - 「ファイル名が指定されていませんでした。」

17247 - 「無効なファイル名(%s)が指定されました。」

17248 - 「ラグの解消後にコマンドを再試行するか、IMMEDIATEオプションを使用してデータ損失を無視します。」

17249 - 「プラガブル・データベース%(1)s (マルチテナント・コンテナ・データベース%(2)s)のメディア・リカバリが無効化されています。」

17250 - 「警告: ソースまたは宛先のマルチテナント・コンテナ・データベースで、ローカルUNDOが有効化されていません。」

17251 - 「スナップショットの子または親であるため、プラガブル・データベース%sからの移行はできません。」

TDEサポートの追加の場合

17413 - 「プラガブル・データベース%sのキーストアのオープンに失敗しました。」

17414 - 「プラガブル・データベース%sのキーストアがオープンしていません。」

17415 - 「プラガブル・データベース%sのキーストア・パスワードは必須です。」

17416 - 「マルチテナント・コンテナ・データベース%sのキーストア・パスワードは必須です。」

17427 - 「プラガブル・データベース%sのキーストア・ステータスをフェッチできません。」

17428 - 「プラガブル・データベース%sのキーストアがオープンしています。」

17429 - 「プラガブル・データベース%sのキーストア・パスワードが正しくありません。」

17430 - 「マルチテナント・コンテナ・データベース%sのキーストア・パスワードが正しくありません。」

スタンバイ・ファイルのサポートの場合

17510 - 「スタンバイ・データベース\"%s\"は、ASMインスタンスを使用していないか、それに接続されていません。」

17511 - 「ソース・マルチテナント・コンテナ・データベースのスタンバイ・データベースは、宛先マルチテナント・コンテナ・データベースとは異なるASMディスク・グループを使用しています。」

17512 - 「移行宛先のスタンバイ・データベースの初期化パラメータDB_FILE_NAME_CONVERTがNULLではありません。」

17513 - 「移行ソースのスタンバイ・データベースの初期化パラメータSTANDBY_FILE_MANAGEMENTがAUTOではありません。」

17514 - 「マルチテナント・コンテナ・データベース%sは、フィジカル・スタンバイ・データベースではありません。」

17515 - 「データ・ファイル%sのASM別名が予期された場所にありません。」

17516 - 「Data Guard Broker構成のマルチテナント・コンテナ・スタンバイ・データベースを指定する必要があります。」

17517 - 「ソース・マルチテナント・コンテナ・データベースがスタンバイ・データベースの場合、データ・ファイルを再利用できません。」

17518 - 「ASM別名%sは、予期された場所にないASMファイルを参照しています。」

17519 - 「保証付きリストア・ポイント\"%(1)s\"は、マルチテナント・コンテナ・データベース\"%(2)s\"で作成されました。」

17520 - 「保証付きリストア・ポイント\"%(1)s\"は、マルチテナント・コンテナ・データベース\"%(2)s\"で削除されました。」

17521 - 「SYSASMとして接続しました。」

17522 - 「マルチテナント・コンテナ・データベース\"%(1)s\"は、データ・ファイル\"%(2)s\"の検出に失敗しました。」

17523 - 「マルチテナント・コンテナ・データベース\"%s\"は、不安定な状態です。」

17524 - 「マルチテナント・コンテナ・データベース\"%(1)s\"は、リストア・ポイント\"%(2)s\"を使用してリストアできます。」

17525 - 「REDO適用がマルチテナント・コンテナ・データベース\"%s\"で停止または失敗しました。」

17530 - 「スタンバイ・マルチテナント・コンテナ・データベース%(1)sは、プラガブル・データベース%(2)sのすべてのデータ・ファイルの追加に失敗しました。」

17532 - 「プラガブル・データベース%(1)sのスタンバイ・マルチテナント・コンテナ・データベース%(2)sからの削除に失敗しました。」

17533 - 「指定されたファイル(%s)は存在していない必要があります。」

17534 - 「パスが指定されませんでした。」

17536 - 「プラガブル・データベース%sのキーストア・モードをフェッチできません。」

17537 - 「KEYFILEおよびSOURCE IDENTIFIED BY句が必要です。」

17539 - 「プラガブル・データベース%(1)sのマスター・キーをマルチテナント・コンテナ・データベース%(2)sにインポートしています。」

サンプルOracle Database Net Services接続別名

ブローカ・セッションの開始時に、DGMGRLから次のNet Services接続別名にアクセスできる必要があります。これは、デフォルトのtnsnames.oraの場所を使用するか、DGMGRLを起動する前に環境でTNS_ADMINを設定することで可能です。

PDBスイッチオーバー

次の例のホスト名は、Oracle単一クライアント・アクセス名(SCAN)のホスト名を参照します。ソース・データベースと宛先データベースは同じホストに存在する必要があるため、ホスト名に重複があります。いずれの場合も、接続文字列はデータベースのcdb$rootに接続する必要があります。

ソース・プライマリ・データベース

CDB100 =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-primary-scan-name>)
                (PORT = <source-primary-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <source-primary-service-name>)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
             )
          )

ソース・プライマリ・データベースのローカル・インスタンス

CDB100_INST1 =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-primary-scan-name>)
                (PORT = <source-primary-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <source-primary-cdb$root-service-name>)
              (INSTANCE_NAME = <source-primary-local-instance-name>)
            )
          )

宛先プライマリ・データベース

CDB200=
    (DESCRIPTION=
      (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= <source-primary-scan-name>)
        (PORT= <source-primary-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= <destination-primary-cdb$root-service-name>)))

宛先プライマリ・ローカル・インスタンス

これは、dgmgrlが実行されている同じホスト上のインスタンスに接続する必要があります

CDB200_INST1=
    (DESCRIPTION=
      (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= <source-primary-scan-name>)
        (PORT= <source-primary-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= <destination-primary-cdb$root-service-name>)
        (INSTANCE_NAME = <destination-primary-local-instance-name>)
      )
    )

ソース・スタンバイ・データベース

CDB100_STBY =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-standby-scan-name)
                (PORT = <source-standby-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <source-standby-cdb$root-service-name>)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
             )
          )

宛先スタンバイ・データベース

CDB200_STBY =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-standby-scan-name>)
                (PORT = <source-standby-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <destination-standby=cdb$root-service-name>)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
             )
          )

スタンバイ環境ASM

これは、ソース・スタンバイおよび宛先スタンバイのそれぞれ1つのインスタンスと同じホストで実行されているASMインスタンスに接続する必要があります

STANDBY_ASM_INST1=
    (DESCRIPTION=
      (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST = <source-standby-scan-name>)
        (PORT= <source-standby-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= +ASM)
        (INSTANCE_NAME=<ASM_instance_name>)
      )
    )

PDBフェイルオーバー

ソース・プライマリ・データベース

CDB100 =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-primary-scan-name>)
                (PORT = <source-primary-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <source-primary-cdb$root-service-name>)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
             )
          )

ソース・スタンバイ・データベース

CDB100_STBY =
          (DESCRIPTION =
            (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
            (ADDRESS =
                (PROTOCOL = TCP)
                (HOST = <source-standby-scan-name>)
                (PORT = <source-standby-listener-port>)
            )
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = <source-standby-cdb$root-service-name>)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
             )
          )

ソース・スタンバイ・データベースのローカル・インスタンス

これは、dgmgrlが実行されている同じホスト上のインスタンスに接続する必要があります

CDB100_STBY_INST1=
    (DESCRIPTION=
      (CONNECT_TIMEOUT=120)(TRANSPORT_CONNECT_TIMEOUT=90)(RETRY_COUNT=3)
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= <source-standby-scan-name>)
        (PORT= <source-standby-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= <source-standby-cdb$root-service-name>)
        (INSTANCE_NAME = <source-standby-local-instance-name>)
      )
    )

宛先プライマリ・データベース

CDB200=
    (DESCRIPTION=
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= <source-standby-scan-name>)
        (PORT= <source-standby-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= <destination-primary-cdb$root-service-name>)))

宛先プライマリ・ローカル・インスタンス

これは、dgmgrlが実行されている同じホスト上のインスタンスに接続する必要があります

CDB200_INST1=
    (DESCRIPTION=
      (ADDRESS=
        (PROTOCOL= TCP)
        (HOST= <source-standby-scan-name>)
        (PORT= <source-standby-listener-port>))
      (CONNECT_DATA=
        (SERVER= DEDICATED)
        (SERVICE_NAME= <destination-primary-cdb$root-service-name>)
        (INSTANCE_NAME = <destination-primary-local-instance-name>)
      )
    )