3 フィジカル・スタンバイ・データベースの作成

非同期REDO転送、リアルタイム適用、デフォルトのOracle Data Guard構成を使用して、最大パフォーマンス・モードのフィジカル・スタンバイ・データベースを手動で作成できます。

注意:

マルチテナント・コンテナ・データベースが、Oracle Database 20cでサポートされる唯一のアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じてCDBまたはPDBを指しています。アップグレードなどのコンテキストでは、「非CDB」が以前のリリースの非CDBを指す場合もあります。

次のメイン・トピックを参照してください。

• スタンバイ・データベースを作成するためのプライマリ・データベースの準備

• フィジカル・スタンバイ・データベースの作成ステップ

• 作成後のステップ

• DBCAを使用したData Guardスタンバイの作成

• CDBのフィジカル・スタンバイの作成

• プライマリ・データベースでのPDBの作成

関連項目:

• サーバーのパラメータ・ファイルの作成と使用の詳細は、『Oracle Database管理者ガイド』を参照してください。

• Oracle Data Guard Brokerグラフィカル・ユーザー・インタフェース(GUI)を使用したフィジカル・スタンバイ・データベースの自動作成の詳細は、Enterprise Managerオンライン・ヘルプ・システムを参照してください。

• Oracle Recovery Manager (RMAN)およびバックアップ・ベースの重複またはネットワークを介したアクティブな重複のいずれかを使用して、プロセスの多くを自動化するフィジカル・スタンバイ・データベースを作成する別の方法については、「Recovery Managerを使用したスタンバイ・データベースの作成」を参照してください。

• Oracle Data Guard Brokerによって管理できるようにデータベースを構成する方法の詳細は、『Oracle Data Guard Broker』を参照してください。

注意:

マルチテナント・コンテナ・データベース(CDB)環境で作業している場合、非CDB環境との動作の違いの詳細は、「CDBのフィジカル・スタンバイの作成」を参照してください。たとえば、CDB環境では、DBAビューの多くに代替として使用する必要のある類似のCDBビューがあります。

3.1 スタンバイ・データベースを作成するためのプライマリ・データベースの準備

スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。

フィジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースで次の準備作業を実行します。

• 適切なロギング・モードの有効化

• REDO転送の認証の構成

• REDOデータを受信するためのプライマリ・データベースの構成

• プライマリ・データベースの初期化パラメータの設定

• アーカイブの有効化

注意:

これらの準備のためのタスクは、1回のみ実行してください。これらのステップを完了すると、データベースは、1つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。

3.1.1 適切なロギング・モードの有効化

スタンバイ・データベースを作成するためのプライマリ・データベースの準備の一部として、Data Guard構成の使用方法に適したロギング・モードを有効化する必要があります。

Data Guard構成に含まれないデータベースのデフォルトのロギング・モードでは、特定のデータ・ロード操作をログに記録されない方法で実行できます。このデフォルト・モードは、ロードされたデータがスタンバイから欠落することになり、修正には手動操作が必要になるため、スタンバイがあるデータベースには適していません。デフォルトのロギング・モードに加えて、プライマリ・データベースに適したモードが他に3つあります。

• FORCE LOGGINGモードでは、ログに記録されない方法でロード操作が実行されることを防止できます。この場合、ロードされたデータをREDOログにコピーする必要があるため、ロード・プロセスの速度が低下する可能性があります。FORCE LOGGINGモードを有効化するには、次のコマンドを使用します。

  SQL> ALTER DATABASE FORCE LOGGING;

• STANDBY NOLOGGING FOR DATA AVAILABILITYモードでロード操作を実行すると、ロードされたデータがスタンバイ固有の接続を介して各スタンバイに送信されます。コミットは、すべてのスタンバイがActive Data Guard環境内の管理リカバリ実行の一部としてデータを適用するまで遅延されます。これは、次のコマンドを使用して有効化されます。

  SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY;

• STANDBY NOLOGGING FOR LOAD PERFORMANCEは、前述のモードに似ていますが、プライマリにデータをロードする際のネットワーク速度を維持できない場合に、ロード・プロセスによるスタンバイへのデータ送信を停止できる点が異なります。このモードでは、スタンバイからデータが欠落する可能性がありますが、各スタンバイはActive Data Guard環境内の管理リカバリ実行の通常の一部として、プライマリ・データベースのデータを自動的にフェッチします。これは、次のコマンドを使用して有効化されます。

  SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;
  
  

これらの文のいずれかを発行する場合は、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。

注意:

プライマリ・データベースでSTANDBY NOLOGGING FOR DATA AVAILABILITYまたはSTANDBY NOLOGGING FOR LOAD PERFORMANCEを有効にすると、複数インスタンスのREDO Apply機能を使用しているすべてのスタンバイはREDOの適用を停止し、エラーORA-10892が発生します。まず、REDO Applyを再開し、影響を受けたスタンバイがNOLOGGING操作期間を超えて進行できるようにしてから、複数インスタンスのREDO Applyを有効化する必要があります。

関連項目:

• FORCE LOGGINGモード指定の影響の詳細は、『Oracle Database管理者ガイド』を参照してください。

3.1.2 REDO転送の認証の構成

Oracle Data Guardでは、Oracle Netセッションを使用してOracle Data Guard構成のメンバー間でREDOデータを転送し、メッセージを制御します。

これらのREDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。

SSLは、次の場合に2つのデータベース間のREDO転送セッションの認証に使用されます。

• データベースが同じOracle Internet Directory(OID)エンタープライズ・ドメインのメンバーであり、現行ユーザーのデータベース・リンクの使用を許可する場合

• データベースに対応するLOG_ARCHIVE_DEST_nおよびFAL_SERVERの各データベース初期化パラメータで、SSL用に構成されたOracle Net接続記述子を使用する場合

• 各データベースに、データベースのOIDエントリの識別名(DN)と一致するDNが付けられたユーザー証明書を格納するOracleウォレットまたはサポートされるハードウェア・セキュリティ・モジュールがある場合

SSL認証の要件が満たされない場合は、リモート・ログイン・パスワード・ファイルを使用するようにOracle Data Guard構成の各メンバーを構成する必要があります。また、構成内のすべてのフィジカル・スタンバイ・データベースには、プライマリ・データベースのパスワード・ファイルの最新コピーが必要です。

注意:

Oracle Database 12cリリース2 (12.2.0.1)以降、プライマリ・データベースで行われたパスワード・ファイルの変更は、スタンバイ・データベースに自動的に伝搬されます。唯一の例外は、遠隔同期インスタンスです。遠隔同期インスタンスはREDOを受け取りますが、適用しないため、更新したパスワード・ファイルを引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスでパスワード・ファイルが更新されると、REDOは遠隔同期インスタンスからREDOログを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。

関連項目:

• リモート・ログイン・パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』および『Oracle Databaseリファレンス』を参照してください。

• SSLの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

• Oracle Net Servicesの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

3.1.3 REDOデータを受信するためのプライマリ・データベースの構成

スタンバイ・データベースが最初に構成に追加されるときに、REDOを受信するようにプライマリ・データベースを構成することがベスト・プラクティスです。

これで、プライマリ・データベースは、スタンバイ・ロールに速やかに推移してREDOデータの受信を開始できるようになります。

スタンバイREDOログを作成するには、SQL ALTER DATABASE ADD STANDBY LOGFILE文を使用します。次に例を示します。

SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;
 
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;

各ログ・ファイルのサイズとログ・グループの数を決定する方法と、スタンバイREDOログの管理に関するその他の背景情報については、「REDOデータを受信するためのOracleデータベースの構成」を参照してください。

3.1.4 プライマリ・データベースの初期化パラメータの設定

プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間のREDO転送サービスを制御する初期化パラメータを定義します。

また、プライマリ・データベースがスタンバイ・ロールに推移したときにREDOデータの受信と適用サービスを制御するパラメータを追加する必要があります。

次の例は、プライマリ・データベースでメンテナンスする、プライマリ・ロールの初期化パラメータを示しています。この例は、シカゴにプライマリ・データベースがあり、ボストンにフィジカル・スタンバイ・データベースが1つあるOracle Data Guard構成を示しています。次の例に示すパラメータは、シカゴのデータベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで稼働している場合に有効です。この構成例では、次の表に示す名前を使用しています。

データベース	DB_UNIQUE_NAME	Oracle Netサービス名
プライマリ	chicago	chicago
フィジカル・スタンバイ	boston	boston

DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
 'LOCATION=USE_DB_RECOVERY_FILE_DEST 
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
 'SERVICE=boston ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  DB_UNIQUE_NAME=boston'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

これらのパラメータは、REDO転送サービスがREDOデータをスタンバイ・システムに転送する方法と、ローカル・ファイル・システムでのREDOデータのアーカイブ処理を制御します。例では、LOG_ARCHIVE_DEST_2初期化パラメータにREDOデータを転送する非同期(ASYNC)ネットワーク転送を指定します。これらは推奨設定であり、スタンバイREDOログ・ファイルが必要です(「REDOデータを受信するためのプライマリ・データベースの構成」を参照)。

次の例は、プライマリ・データベース上のその他のスタンバイ・ロールの初期化パラメータを示しています。これらのパラメータは、プライマリ・データベースがスタンバイ・ロールに推移すると有効になります。

FAL_SERVER=boston
DB_FILE_NAME_CONVERT='/boston/','/chicago/'
LOG_FILE_NAME_CONVERT='/boston/','/chicago/' 
STANDBY_FILE_MANAGEMENT=AUTO

前述の初期化パラメータを指定すると、プライマリ・データベースがギャップを解決するよう設定され、新しいプライマリ・データベースからの新規データファイルとログ・ファイルのパス名を変換して、このデータベースがスタンバイ・ロールで動作しているときの着信REDOデータがアーカイブされます。説明に従ってプライマリおよびスタンバイ・ロールについて初期化パラメータを設定した場合、ロールの推移後に変更が必要なパラメータはありません。

次の表に、前の2つの例に示した各パラメータ設定に関する簡単な説明を示します。

パラメータ	お薦めする設定
DB_NAME	プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースのDB_NAMEを使用します。
DB_UNIQUE_NAME	各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。
LOG_ARCHIVE_CONFIG	Oracle Data Guardの機能を完全に有効にするには、このパラメータのDG_CONFIG属性をOracle Data Guard構成のデータベースごとに明示的に設定する必要があります。構成内の各データベース名のDB_UNIQUE_NAMEを含み、各名前がカンマで区切られたテキスト文字列にDG_CONFIGを設定します。
CONTROL_FILES	プライマリ・データベースの制御ファイルのパス名を指定します。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。
LOG_ARCHIVE_DEST_n	REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。 LOG_ARCHIVE_DEST_1と指定すると、プライマリ・データベースにより生成されたREDOデータは、ローカルのオンラインREDOログ・ファイルから/arch1/chicago/にあるローカルのアーカイブREDOログ・ファイルにアーカイブされます。 LOG_ARCHIVE_DEST_2は、プライマリ・ロールにのみ有効です。この宛先を指定すると、REDOデータはリモート・フィジカル・スタンバイ宛先bostonに転送されます。 注意: 高速リカバリ領域を(DB_RECOVERY_FILE_DEST初期化パラメータを使用して)構成しており、LOCATION属性でローカル・アーカイブ先を明示的に構成していない場合は、デフォルトのローカル・アーカイブ先としてLOG_ARCHIVE_DEST_1初期化パラメータ(まだ設定されていない場合)が自動的に使用されます。LOG_ARCHIVE_DEST_nの完全な情報については、「LOG_ARCHIVE_DEST_nパラメータの属性」も参照してください。
REMOTE_LOGIN_PASSWORDFILE	リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータをEXCLUSIVEまたはSHAREDに設定する必要があります。
LOG_ARCHIVE_FORMAT	スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。
FAL_SERVER	FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。
DB_FILE_NAME_CONVERT	スタンバイ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されます。このパラメータにより、複数のペアのパスを指定できます。
LOG_FILE_NAME_CONVERT	スタンバイ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。このパラメータにより、複数のペアのパスを指定できます。
STANDBY_FILE_MANAGEMENT	データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、AUTOに設定します。

注意:

変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。

3.1.5 アーカイブの有効化

アーカイブが有効になっていない場合は、プライマリ・データベースをARCHIVELOGモードにし、自動アーカイブを有効にする必要があります。

次のSQL文を発行します。

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;

注意:

スタンバイREDOログ・アーカイブを実行するには、スタンバイ・データベースがARCHIVELOGモードである必要があります。

アーカイブの詳細は、『Oracle Database管理者ガイド』を参照してください。

3.2 フィジカル・スタンバイ・データベースの作成ステップ

フィジカル・スタンバイ・データベースの作成で実行するタスクを次に示します。

次のトピックを十分に理解していることが求められます。

• データベース管理者の認証

• データベース初期化パラメータ

• REDOログ、データファイルおよび制御ファイルの管理

• アーカイブREDOログの管理

• 高速リカバリ領域

• Oracle Net構成

表3-1は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。

表3-1 フィジカル・スタンバイ・データベースの作成

タスク	データベース
プライマリ・データベース・データファイルのバックアップ・コピーの作成	プライマリ
スタンバイ・データベース用の制御ファイルの作成	プライマリ
スタンバイ・データベース用のパラメータ・ファイルの作成	プライマリ
プライマリ・システムからスタンバイ・システムへのファイルのコピー	プライマリ
スタンバイ・データベースをサポートする環境の設定	スタンバイ
フィジカル・スタンバイ・データベースの起動	スタンバイ
フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認	スタンバイ

3.2.1 フィジカル・スタンバイの作成 タスク1: プライマリ・データベース・データファイルのバックアップ・コピーの作成

データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。

データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager(RMAN)ユーティリティを使用することをお薦めします。

データベース・バックアップ操作の実行の詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

3.2.2 フィジカル・スタンバイの作成 タスク2: スタンバイ・データベース用の制御ファイルの作成

スタンバイ・データベース用の制御ファイルを作成します(プライマリ・データベースは開いている必要はありませんが、マウントされている必要があります)。

次に、スタンバイ・データベースの制御ファイルを作成する例を示します。

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';

ALTER DATABASEコマンドはスタンバイ・ロールで動作するデータベースを指定します。この場合、bostonという名前のデータベースです。

プライマリ・データベースとスタンバイ・データベースの両方に単一の制御ファイルを使用することはできません。それぞれに独自のファイルが必要です。

注意:

制御ファイル・バックアップがプライマリで作成され、スタンバイでリストアされる(またはその逆)場合、リストアされたシステム上のスナップショット制御ファイルの場所は、デフォルトになるように構成されます。(スナップショット制御ファイル名のデフォルト値はプラットフォーム固有であり、Oracleホームに依存します。)RMANのCONFIGURE SNAPSHOT CONTROLFILEコマンドを使用して、手動で正しい値に再構成します。

3.2.3 フィジカル・スタンバイの作成 タスク3: スタンバイ・データベース用のパラメータ・ファイルの作成

プライマリ・データベースで使用されるサーバー・パラメータ・ファイル(SPFILE)からパラメータ・ファイル(PFILE)を作成します。

次のステップを実行します。

1. 次のようなSQL文を発行します。

   SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
   

   スタンバイ・データベースをサポートする環境の設定では、このパラメータ・ファイルをフィジカル・スタンバイ・データベースでの使用に適したパラメータ値が含まれるように変更した後で、このファイルからサーバー・パラメータ・ファイルを作成します。

2. 前のステップで作成したパラメータ・ファイルのパラメータ値を変更します。

   パラメータ・ファイル内の初期化パラメータ設定の大部分はフィジカル・スタンバイ・データベースにも適していますが、一部変更が必要なものがあります。

   例3-1では、プライマリで前に作成されたパラメータで、変更する必要のあるものが太字で示されています。

例3-1 フィジカル・スタンバイ・データベース用の初期化パラメータの変更

.
.
.
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
DB_FILE_NAME_CONVERT='/chicago/','/boston/'
LOG_FILE_NAME_CONVERT='/chicago/','/boston/'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
 'LOCATION=USE_DB_RECOVERY_FILE_DEST
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 
  DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
 'SERVICE=chicago ASYNC
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
  DB_UNIQUE_NAME=chicago'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
.
.
.

プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。

SHOW PARAMETERSコマンドを使用して、他に変更を必要とするパラメータがないかどうかを確認することをお薦めします。

次の表に、例3-1に示したパラメータ設定のうち、プライマリ・データベースとは異なる設定に関する簡単な説明を示します。

パラメータ	お薦めする設定
DB_UNIQUE_NAME	このデータベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。
CONTROL_FILES	スタンバイ・データベースの制御ファイルのパス名を指定します。例3-1は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。
DB_FILE_NAME_CONVERT	プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。
LOG_FILE_NAME_CONVERT	プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。
LOG_ARCHIVE_DEST_n	REDOデータのアーカイブ先を指定します。例3-1では、次のようになっています。 LOG_ARCHIVE_DEST_1を指定すると、プライマリ・データから受信したREDOデータは/arch1/boston/のアーカイブREDOログ・ファイルにアーカイブされます。 LOG_ARCHIVE_DEST_2はプライマリ・ロールのみに有効であるため、この宛先は現在は無視されます。スイッチオーバーが発生して、このインスタンスがプライマリ・データベースになる場合は、REDOデータがリモートのシカゴの宛先に転送されます。 注意: 高速リカバリ領域を(DB_RECOVERY_FILE_DEST初期化パラメータを使用して)構成しており、LOCATION属性でローカル・アーカイブ先を明示的に構成していない場合は、デフォルトのローカル・アーカイブ先としてLOG_ARCHIVE_DEST_1初期化パラメータ(まだ設定されていない場合)が自動的に使用されます。LOG_ARCHIVE_DEST_nの完全な情報については、「LOG_ARCHIVE_DEST_nパラメータの属性」も参照してください。
FAL_SERVER	FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、シカゴのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。

注意:

変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。

3.2.4 フィジカル・スタンバイの作成 タスク4: プライマリ・システムからスタンバイ・システムへのファイルのコピー

必要なディレクトリがすべて作成されていることを確認します。オペレーティング・システムのコピー・ユーティリティを使用して、プライマリ・システムのバイナリ・ファイルをスタンバイ・システムの正しい場所にコピーします。

コピーするバイナリ・ファイルは次のとおりです。

• 「プライマリ・データベース・データファイルのバックアップ・コピーの作成」で作成されたデータベース・バックアップ

• 「スタンバイ・データベース用の制御ファイルの作成」で作成されたスタンバイ制御ファイル

• 「スタンバイ・データベース用のパラメータ・ファイルの作成」で作成された初期化パラメータ・ファイル

3.2.5 フィジカル・スタンバイの作成 タスク5: スタンバイ・データベースをサポートする環境の設定

環境設定として、Windowsベース・サービス、パスワード・ファイルおよびSPFILEを作成し、Oracle Net環境を設定します。

次のステップを実行します。

1. スタンバイ・データベースのホストがWindowsシステムである場合、ORADIMユーティリティを使用してWindowsサービスを作成します。次に例を示します。

   oradim –NEW –SID boston –STARTMODE manual
   

   ORADIMユーティリティは、このサービスを作成する必要のあるユーザー名を自動的に決定し、そのユーザー名のパスワードを求めます(そのユーザー名がパスワードを必要とする場合)。ORADIMユーティリティの使用の詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。

2. リモート・ログイン・パスワード・ファイルをプライマリ・データベース・システムからスタンバイ・データベース・システムにコピーします。

   このステップは、オペレーティング・システムの認証を管理ユーザーに使用する場合およびSSLをREDO転送の認証に使用する場合はオプションです。いずれの場合でもない場合は、リモート・ログイン・パスワード・ファイルをプライマリ・データベースからフィジカル・スタンバイ・データベース・システムの適切なディレクトリにコピーします。

   プライマリでのパスワード・ファイルへのその後の変更は、スタンバイに自動的に伝播されます。管理権限(SYSDG、SYSOPER、SYSDBAなど)が付与または解除されたとき、および管理権限を持つユーザーのパスワードが変更されたときのパスワード・ファイルの変更が含まれます。遠隔同期インスタンスはREDOを受け取りますが、適用しないため、更新したパスワード・ファイルを引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスでパスワード・ファイルが更新されると、プライマリでのパスワードの更新を含むREDOは、遠隔同期インスタンスからREDOログを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。

3. 構成されていない場合、スタンバイ・システムにリスナーを構成して、開始します。

   『Oracle Database Net Services管理者ガイド』を参照してください。

4. Oracle Netサービス名を作成します。

   プライマリ・システムとスタンバイ・システムの両方で、Oracle Net Managerを使用して、プライマリ・データベースとスタンバイ・データベースのネットワーク・サービス名を作成します。ネットワーク・サービス名はREDO転送サービスで使用されます。この例のNetサービス名は、chicagoとbostonです。

   Oracle Netネット・サービス名は、プライマリ・データベースとスタンバイ・データベースに対するリスナーの構成時に指定したものと同じプロトコル、ホスト・アドレス、ポートおよびサービスを使用する接続記述子に解決される必要があります。この接続記述子は、専用サーバーが使用されるように指定する必要もあります。

   サービス名の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

5. アイドル状態のスタンバイ・データベースで、SQL CREATE文を使用して、タスク3で編集したテキストの初期化パラメータ・ファイルから、スタンバイ・データベース用のサーバー・パラメータ・ファイルを作成します。次に例を示します。

   SQL> CREATE SPFILE FROM PFILE='initboston.ora';
   

6. プライマリ・データベースにデータベース暗号化ウォレットがある場合は、スタンバイ・データベース・システムにコピーし、そのウォレットを使用するようにスタンバイ・データベースを構成します。

   注意:

   データベース暗号化ウォレットは、マスター暗号化キーが更新されるたびに、プライマリ・データベース・システムから各スタンバイ・データベース・システムにコピーする必要があります。

   スタンバイ・データベースの暗号化されたデータには、プライマリ・データベースの現行のマスター暗号化キーを格納するデータベース暗号化ウォレットまたはハードウェア・セキュリティ・モジュールを指すように、スタンバイ・データベースが構成されるまでアクセスできません。

3.2.6 フィジカル・スタンバイの作成 タスク6: フィジカル・スタンバイ・データベースの起動

フィジカル・スタンバイ・データベースおよびREDO Applyを起動するステップを次に示します。

1. スタンバイ・データベースで、次のSQL文を発行してデータベースを起動およびマウントします。

   SQL> STARTUP MOUNT;
   

2. 「プライマリ・データベース・データファイルのバックアップ・コピーの作成」で取得し、「プライマリ・システムからスタンバイ・システムへのファイルのコピー」でスタンバイ・システムにコピーしたデータファイルのバックアップをリストアします。
3. スタンバイ・データベースで、次のコマンドを発行してREDO Applyを開始します。

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - 
   > DISCONNECT FROM SESSION;
   

   この文にはDISCONNECT FROM SESSIONオプションが指定されているため、REDO Applyはバックグラウンド・セッションで実行されます。

3.2.7 フィジカル・スタンバイの作成 タスク7: フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認

フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。

スタンバイ・データベースで、V$DATAGUARD_PROCESSビューを問い合せて、REDOがプライマリ・データベースから送信され、スタンバイ・データベースに適用されていることを確認します。

SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;


ROLE                        THREAD#  SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
RFS ping                          1          9 IDLE
recovery apply slave              0          0 IDLE
recovery apply slave              0          0 IDLE
managed recovery                  0          0 IDLE
recovery logmerger                1          9 APPLYING_LOG
RFS archive                       0          0 IDLE
RFS async                         1          9 IDLE

recovery logmergerロールは、REDOがスタンバイに適用されていることを示しています。

注意:

V$MANAGED_STANDBYビューはOracle Database 12cリリース2 (12.2.0.1)から非推奨となっており、将来のリリースでサポートされなくなる可能性があるため、かわりにV$DATAGUARD_PROCESSビューを使用することをお薦めします。

3.3 フィジカル・スタンバイの作成: 作成後のステップ

フィジカル・スタンバイ・データベースの実行後、データ保護モードをアップグレードできます。また、フラッシュバック・データベースを有効化できます。

• データ保護モードのアップグレード

  各種データ保護モードの構成の詳細は、「Oracle Data Guardの保護モード」を参照してください。

• フラッシュバック・データベースの有効化

  フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。

関連項目:

• Oracle Data Guard環境でのフラッシュバック・データベースの使用例は、「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」および「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。

• データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

3.4 DBCAを使用したData Guardスタンバイの作成

Database Configuration Assistant (DBCA)も、簡単なコマンドラインによる方法としてOracle Data Guardのフィジカル・スタンバイ・データベースを作成するために使用できます。

フィジカル・スタンバイ・データベースの作成に使用されたDBCAコマンド・クオリファイアは、createDuplicateDBです。

DBCAは、非マルチテナントのプライマリ・データベースに対するスタンバイ・データベースを作成するためにのみ使用できます。さらに、この機能は単一インスタンスのスタンバイ・データベースのみを作成し、Oracle Real Application Clusters (Oracle RAC)データベースは作成しません。必要であれば、スタンバイは手動またはOracle Enterprise Manager Cloud Controlのいずれかを使用してOracle RACスタンバイ・データベースに変換できます。

基本のcreateDuplicateDBコマンドの構文は次のとおりです。

dbca -createDuplicateDB 
    -gdbName global_database_name 
    -primaryDBConnectionString easy_connect_string_to_primary
    -sid database_system_identifier
    [-createAsStandby 
        [-dbUniqueName db_unique_name_for_standby]]
    [-customScripts scripts_list]

createDuplicateDBオプションの詳細は、カスタム・スクリプトの使用を含めて、Oracle Database管理者ガイドを参照してください。

次の2つの例では、プライマリ・データベースはchicagoでプライマリ・システムmyprimary.domain上にあります。それぞれの例では、コマンドが実行されるシステムにフィジカル・スタンバイbostonが作成されます。initParamsパラメータは、例の中では、他のDBCAパラメータをスタンバイ作成コマンドでどのように使用できるかを示すために使用されています。これらの例では、initParamsはスタンバイのINSTANCE_NAMEをDB_UNIQUE_NAMEと一致するように明示的にbostonに設定するために使用されています。

この最初の例では、後で実行されるカスタム・スクリプトなしでスタンバイ・スクリプトが作成されます。

dbca –silent -createDuplicateDB -primaryDBConnectionString  myprimary.domain:1523/chicago.domain 
-gdbName chicago.domain -sid boston -initParams instance_name=boston –createAsStandby

Enter SYS user password:
Listener config step
33% complete
Auxiliary instance creation
66% complete
RMAN duplicate
100% complete
Look at the log file " /u01/app/oracle/product/12.2.0/dbhome_1/cfgtoollogs/dbca/chicago/chicago.log" for further details.

次の例は、/tmp/test.sqlという名前のSQLスクリプトを実行する点を除いて、前の例とまったく同じです。このスクリプトは作成後の操作を実行するために使用できます。

dbca -silent -createDuplicateDB -primaryDBConnectionString  myprimary.domain:1523/chicago.domain
-gdbName chicago.domain -sid boston -initParams instance_name=boston -createAsStandby  -customScripts /tmp/test.sql

Enter SYS user password:

Listener config step
25% complete
Auxiliary instance creation
50% complete
RMAN duplicate
75% complete
Running Custom Scripts
100% complete
Look at the log file " /u01/app/oracle/product/12.2.0/dbhome_1/cfgtoollogs/dbca/chicago/chicago.log" for further details.

注意:

フィジカル・スタンバイ・システム上で稼働するリスナーが必要な場合でも、どちらのシステムにもこれらのコマンドを実行するためにデータベースのOracle Netサービス名を構成する必要はありません。これらの例では、プライマリ・データベースChicagoへの接続を作成するためと、スタンバイBostonの作成を完了するためにEasy Connectネーミング・メソッドが使用されました。新しいスタンバイをData Guard構成に追加する前に、フィジカル・スタンバイの作成 タスク5: スタンバイ・データベースをサポートする環境の設定のステップ4に説明されているように、最初にOracle Netサービス名ディスクリプタを両方のシステムに構成します。

これらのコマンドがエラーなしで完了すると、フィジカル・スタンバイBostonはData Guard構成に追加する準備ができています。追加の一部として、フィジカル・スタンバイ タスク3: スタンバイ・データベース用のパラメータ・ファイルの作成に示されているようにData GuardパラメータをChicagoおよびBostonに定義する必要があります。オプションで、Oracle Data Guard Broker構成がある場合は、ブローカのADD DATABASEコマンドを使用して新しいスタンバイを構成に追加できます(Oracle Data Guard Brokerを参照)。

3.5 CDBのフィジカル・スタンバイの作成

通常のプライマリ・データベースのフィジカル・スタンバイを作成できるように、マルチテナント・コンテナ・データベース(CDB)のフィジカル・スタンバイを作成できます。

CDBのフィジカル・スタンバイの作成および使用時に注意する動作の違いの一部を次に示します。

• スイッチオーバー操作またはフェイルオーバー操作を実行する場合、CDB全体でロールが変化します。ENABLED_PDBS_ON_STANDBY初期化パラメータを使用した場合、すべてのPDBがプライマリおよびスタンバイ・データベースに存在するとは限らない可能性に留意してください。

• データベース・ロールは個別のコンテナ・レベルではなく、CDBレベルで定義されます。

• ロールの変更に関連するDDLは、ロールがCDB全体に関連するため、ルート・コンテナで実行される必要があります。個別のプラガブル・データベース(PDB)には固有のロールはありません。

• CDBのフィジカル・スタンバイで、SQL文の構文は通常、コンテナでないデータベースと同じです。しかし、次に示すものを含む、一部の文の影響は異なる場合があります。

  • ALTER DATABASE RECOVER MANAGED STANDBYはルート・コンテナでのみ機能し、PDBでは使用できません。

  • 1つのロールはCDB全体に関連します。個別のPDBには固有のロールはありません。そのため、フィジカル・スタンバイに関連する次のロール変更DDLはCDB全体に影響します。

    ALTER DATABASE SWITCHOVER TO target_db_name

    ALTER DATABASE ACTIVATE PHYSICAL STANDBY

• ALTER PLUGGABLE DATABASE [OPEN|CLOSE] SQL文は、ルート・コンテナをすでにオープンしているならば、スタンバイでサポートされます。

• ALTER PLUGGABLE DATABASE RECOVER文はスタンバイでサポートされません。(スタンバイ・リカバリは常にCDBレベルです。)

• マルチテナント環境を管理するには、CDB_DBAロールが必要です。

• スタンバイ・データベースには固有のキーストアを含めることをお薦めします。

• マルチテナント環境では、REDOはスタンバイ・データベースのルート・コンテナに送信される必要があります。

  REDOがルート・コンテナに送信されているかどうかを判断する方法の例を次に示します。プライマリ・データベースが次の設定であると想定します。

  LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,
  PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
  

  REDOはbostonに送信されています。ルート・コンテナのコンテナID (CON_ID)は常に1のため、サービスbostonではCON_IDが1となるようにする必要があります。これを行うには、tnsnames.oraファイルのサービス名を確認します。次に例を示します。

  boston = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=boston-server)(PORT=1521))
  (CONNECT_DATA=(SERVICE_NAME=boston.us.example.com))
  

  bostonのサービス名は、boston.us.example.comです。

  スタンバイ・データベースでCDB_SERVICESビューを問い合せて、CON_IDを確認します。次に例を示します。

  SQL> SELECT NAME, CON_ID FROM CDB_SERVICES;
  
  NAME                                 CON_ID
  ---------------------------------------------
  boston.us.example.com                 1
  

  問合せの結果、bostonのCON_IDが1であると示されます。

関連項目:

• CDBの詳細は、『Oracle Database概要』を参照してください。

• キーストアの作成の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

3.6 プライマリ・データベースでのPDBの作成

Oracle Data Guard構成では、プライマリ・データベースのプラガブル・データベース(PDB)は、通常のデータベースのPDBを作成するのと同じ方法で作成します。

この項では、任意のタイプのPDBを作成したときにData GuardとOracle Multitenantオプションの間で行われるやり取りについての要点を示します。詳細な情報と例は、http://support.oracle.comにあるMy Oracle Supportノート2049127.1を参照してください。

通常のデータベースでPDBを作成するステップは、Oracle Multitenant管理者ガイドを参照してください。これらのステップに従う前に、次の説明を読んでください。

• PDBのサブセットをマルチテナント・コンテナ・データベース(CDB)のフィジカル・スタンバイに複製するように指定できます。このためには、ENABLED_PDBS_ON_STANDBY初期化パラメータを使用してPDBのリストを指定するか、STANDBYS句をCREATE PLUGGABLE DATABASE文で使用するか、あるいはその両方を実行します。

  ENABLED_PDBS_ON_STANDBYパラメータ(ENABLED_PDBS_ON_STANDBYを参照)は、フィジカル・スタンバイでのみ有効であり、プライマリ・データベースでは無視されます。(プライマリ・データベースに設定して使用できるのは、そのデータベースがスタンバイ・データベースになった場合のみです。)これは、どのPDBをフィジカル・スタンバイ・データベースで有効化するかしないかを指定するために使用できます。 このパラメータが指定されていない場合、STANDBYS句が使用されていないかぎりCDB内のすべてのPDBがスタンバイ上に作成されます。

  STANDBYS句は、リカバリが後で有効になるか無効になるかに影響しません。SQL CREATE PLUGGABLE DATABASE文のSTANDBYS句の構文は次のとおりです。

  CREATE PLUGGABLE DATABASE … STANDBYS={('cdb_name', 'cdb_name', ...) | NONE | ALL [EXCEPT ('cdb_name', 'cdb_name', ...)]}

  • cdb_nameは、PDBを含めるフィジカル・スタンバイ用のDB_UNIQUE_NAMEです。

  • NONEは、作成中のPDBをすべてのスタンバイCDBから除外します。PDBがすべてのスタンバイCDBから除外される場合、PDBのデータ・ファイルはオフラインになり、すべてのスタンバイCDBで名前なしとしてマークされます。PDBが作成された後にインスタンス化された新しいスタンバイCDBは、リカバリのために明示的にPDBを無効にし、スタンバイCDBから除外する必要があります。PDBをスタンバイCDBで除外した後に、そのスタンバイCDBで有効にすることができます。

  • ALL(デフォルト)は、作成中のPDBをすべてのスタンバイCDBに含めます。

  • EXCEPT cdb_nameは、作成中のPDBを、DB_UNIQUE_NAMEでこの句にリストされたCDBを除いてすべてのスタンバイCDBに含めます。

  STANDBYS句にCDB名のリストを指定する場合は、リストをカッコで囲み、それぞれの名前を一重引用符で囲む必要があります。DB_UNIQUE_NAMEの値には最大30文字を指定できます。大/小文字は区別されません。データベース名で有効な文字は、英数字、アンダースコア(_)、シャープ記号(#)およびドル記号($)です。

  PDBがシードから作成されるか、Active Data Guardを実行しているスタンバイのローカル・クローンとして作成されるか、またはSTANDBY_PDB_SOURCE_FILE_DBLINKパラメータを使用してリモート・クローンとして作成される場合を除き、リスト内のスタンバイには必要なファイルが事前移入されている必要があります。

• PDBを別のPDBまたは同じプライマリCDB内のシードPDBからローカル・クローンとして作成する場合は、次の点に注意してください。

  • シードから新しいPDBを作成すると、スタンバイはファイルを自動的にインスタンス化します。

  • Active Data Guard環境では、PDBが同じCDB内でクローニングされたときに、Data Guardがファイルを自動的にインスタンス化します。

  • 非Active Data Guard環境では、PDBが同じCDB内でクローニングされたときに、CREATE PLUGGABLE DATABASE文でSTANDBYS句を使用し、後でリカバリを有効化します。

• PDBのリモート・クローンまたはプラグインの実行時にスタンバイ・データベースを自動的に維持するには、次の初期化パラメータを使用します。

  • STANDBY_PDB_SOURCE_FILE_DBLINK - リモート・クローニングの場合に使用します。プライマリのPDBをクローニングするために使用するデータベース・リンクの名前を指定します。PDBのクローン操作に対するREDOがスタンバイに適用されると、スタンバイはそのデータベース・リンクを使用してソース・データベースに接続し、接続先のスタンバイ・データベースに対してクローニング・プロセスを繰り返します。このパラメータは、データベース・ディクショナリにアクセスしてリンクの詳細情報を取得するActive Data Guardでのみ使用できます。

    クローニング操作のソースPDBは、プライマリへのクローニングとスタンバイへのクローニングのどちらの期間中も読取り専用モードである必要があります。

    STANDBY_PDB_SOURCE_FILE_DBLINKパラメータを使用しないリモート・クローンでは、PDBの作成に使用するSQL CREATE PLUGGABLE DATABASE文でSTANDBYS=NONE句を使用する必要があります。

  • STANDBY_PDB_SOURCE_FILE_DIRECTORY - プラグインの場合に使用します。繰り返し実行されるプラグインで使用されるPDBのファイルが格納されるディレクトリの場所を指定します。PDBプラグイン操作のREDOがスタンバイに適用されると、スタンバイはデータ・ファイルのディレクトリの場所を検索し、検出後、DB_CREATE_FILE_DESTおよびDB_FILE_NAME_CONVERTパラメータの設定に基づいて、ファイルをスタンバイ上の必要な場所にコピーします。

    注意:

    ファイルは、ソースPDBデータ・ファイルのイメージ・コピーである必要があります。このコピーは、ソースPDBのマニフェストXMLファイルの作成後に作成する必要があります。

  これらのパラメータは、使用して不要になった後にリセットする必要があります。これらのパラメータを設定およびリセットするためにインスタンスを再起動する必要はないため、この操作による実行時の影響はありません。

  これらのパラメータの使用方法の詳細は、http://support.oracle.comにあるMy Oracle Supportノート2274735.1を参照してください。

• PDBをXMLファイルから作成するには、XMLファイルで指定されたデータ・ファイルをスタンバイ・データベースにコピーします。

  PDBをXMLファイルからプライマリ・データベースにプラグインするときは、構成内のすべてのスタンバイ・データベースにソースPDBのファイルへのアクセス権を付与する必要があります。(この唯一の例外は、CREATE PLUGGABLE DATABASE文のSTANDBYS句またはENABLED_PDBS_ON_STANDBY初期化パラメータのいずれかを使用してリカバリが延期されたスタンバイです。)

  構成内のスタンバイにソースPDBのファイルへのアクセス権を設定するには、STANDBY_PDB_SOURCE_FILE_DIRECTORY初期化パラメータを使用するか、ソースPDBのファイル(通常はプライマリ・データベースにプラグインされる同じPDBファイル・セット)をスタンバイ・サイトにコピーします。管理スタンバイ・リカバリの中断を最小限に抑えるため、プライマリでプラグイン操作を実行する前にファイルをスタンバイにコピーする必要があります。次のようにして、管理スタンバイ・リカバリで検出できるスタンバイの適切な場所にファイルがコピーされていること確認します。

  • データ・ファイルが標準的なオペレーティング・システムのファイル・システムに存在する場合、スタンバイ・データベースでのファイルの場所は、DB_FILE_NAME_CONVERTパラメータの値に基づいています。プライマリ・データベース初期化パラメータの設定の詳細は、「プライマリ・データベースの初期化パラメータの設定」を参照してください

  • データ・ファイルがASMに存在する場合、ASMCMDユーティリティを使用して、ファイルをスタンバイ・データベースの次の場所にコピーします。

    db_create_file_dest/db_unique_name/GUID/datafile
    

    GUIDパラメータは、PDBに割り当てられるグローバル一意識別子で、一度割り当てられると変わりません。GUIDパラメータの値を確認するには、元のソース・コンテナからPDBを切断する前に、V$CONTAINERSビューを問い合せます。次の例は、ソース・コンテナのPDBコンテナIDが3であるPDBのGUIDパラメータ値の確認方法を示しています。

    SELECT guid
      FROM V$CONTAINERS
     WHERE con_id=3;
     
    GUID
     
    D98C12257A951FC4E043B623F00A7AF5
    

    この例では、DB_CREATE_FILE_DESTパラメータの値が+DATAFILEで、DB_UNIQUE_NAMEパラメータの値がBOSTONである場合、データ・ファイルが次の場所にコピーされます。

    +DATAFILE/BOSTON/D98C12257A951FC4E043B623F00A7AF5/datafile
    

スタンバイ・データベースのデータ・ファイルのパス名は、プライマリでPDBを作成した結果のパス名と同じである必要があります。ただし、DB_FILE_NAME_CONVERTデータベース初期化パラメータがスタンバイで構成されている場合を除きます。この場合、スタンバイ・データベースのデータ・ファイルのパス名は、DB_FILE_NAME_CONVERTが適用されたプライマリでのパス名です。

関連項目:

• SQL文CREATE PLUGGABLE DATABASEの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。