| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
非同期REDO転送、リアルタイム適用、デフォルトのOracle Data Guard構成を使用して、最大パフォーマンス・モードのフィジカル・スタンバイ・データベースを手動で作成できます。次のメイン・トピックを参照してください。
関連項目:
サーバーのパラメータ・ファイルの作成と使用の詳細は、『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ビューがあります。
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。フィジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースで次の準備作業を実行します。
注意:
これらの準備のためのタスクは、1回のみ実行してください。これらの手順を完了すると、データベースは、1つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。
プライマリ・データベースをFORCE LOGGINGモードにします。これは、データベース作成後に、次のSQL文を使用して実行できます。
SQL> ALTER DATABASE FORCE LOGGING;
この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。
関連項目:
FORCE LOGGINGモード指定の影響の詳細は、『Oracle Database管理者ガイド』を参照してください。
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構成の各メンバーを構成する必要があります。また、構成内のすべてのフィジカル・スタンバイ・データベースには、プライマリ・データベースのパスワード・ファイルの最新コピーが必要です。
注意:
認証にリモート・ログイン・パスワードを使用している場合、REDO転送ユーザーのログイン・パスワードを変更するたびに、更新されたパスワード・ファイルを構成内の各フィジカルまたはスナップショット・スタンバイ・データベースにコピーする必要があります。
スタンバイ・データベースのOracle ASMディスク・グループにパスワード・ファイルを格納した場合、更新したパスワード・ファイルをプライマリ・データベースからスタンバイ・データベースのOracle ASMの場所にコピーする必要があります。Oracle ASMまたはデータベース・インスタンス・パスワード・ファイルを指定した場所にコピーするために使用するASMCMD pwcopyコマンドの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。srvctlユーティリティを使用してデータベース構成を変更する方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
関連項目:
リモート・ログイン・パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』および『Oracle Databaseリファレンス』を参照してください。
SSLの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Net Servicesの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
スタンバイ・データベースが最初に構成に追加されるときに、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データベースの構成」を参照してください。
プライマリ・データベースでは、データベースがプライマリ・ロールで動作している間の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つの例に示した各パラメータ設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
|
プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースの |
|
各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
Oracle Data Guardの機能を完全に有効にするには、このパラメータの |
|
プライマリ・データベースの制御ファイルのパス名を指定します。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。 |
|
REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。
注意: 高速リカバリ領域を( |
|
リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータを |
|
スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。 |
|
FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
|
スタンバイ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されます。このパラメータにより、複数のペアのパスを指定できます。 |
|
スタンバイ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。このパラメータにより、複数のペアのパスを指定できます。 |
|
データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、 |
注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。
この項では、フィジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。次のトピックを十分に理解していることが求められます。
データベース管理者の認証
データベース初期化パラメータ
REDOログ、データファイルおよび制御ファイルの管理
アーカイブREDOログの管理
高速リカバリ領域
Oracle Net構成
表3-1は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。
表3-1 フィジカル・スタンバイ・データベースの作成
| タスク | データベース |
|---|---|
プライマリ |
|
プライマリ |
|
プライマリ |
|
プライマリ |
|
スタンバイ |
|
スタンバイ |
|
スタンバイ |
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager(RMAN)ユーティリティを使用することをお薦めします。
バックアップの推奨については『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を、データベースのバックアップ操作の実行については『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
次の例に示すように、スタンバイ・データベース用の制御ファイルを作成します(プライマリ・データベースは開いている必要はありませんが、マウントはされている必要があります)。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';
ALTER DATABASEコマンドはスタンバイ・ロールで動作するデータベースを指定します。この場合、bostonという名前のデータベースです。
プライマリ・データベースとスタンバイ・データベースの両方に単一の制御ファイルを使用することはできません。それぞれに独自のファイルが必要です。
注意:
制御ファイル・バックアップがプライマリで作成され、スタンバイでリストアされる(またはその逆)場合、リストアされたシステム上のスナップショット制御ファイルの場所は、デフォルトになるように構成されます。(スナップショット制御ファイル名のデフォルト値はプラットフォーム固有であり、Oracleホームに依存します。)RMANのCONFIGURE SNAPSHOT CONTROLFILEコマンドを使用して、手動で正しい値に再構成します。
次の手順を実行して、スタンバイ・データベースのパラメータ・ファイルを作成します。
例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に示したパラメータ設定のうち、プライマリ・データベースとは異なる設定に関する簡単な説明を示します。
| パラメータ | 推奨する設定 |
|---|---|
|
このデータベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
スタンバイ・データベースの制御ファイルのパス名を指定します。例3-1は2つの制御ファイルに対してこれを行う方法を示しています。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。 |
プライマリ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。 |
|
プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。 |
|
|
REDOデータのアーカイブ先を指定します。例3-1では、次のようになっています。
注意: 高速リカバリ領域を( |
|
FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、シカゴのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。
必要なディレクトリがすべて確実に作成されるようにし、オペレーティング・システムのコピー・ユーティリティを使用して、次のバイナリ・ファイルをプライマリ・システムからスタンバイ・システムの正しい場所にコピーします。
「プライマリ・データベース・データファイルのバックアップ・コピーの作成」で作成されたデータベース・バックアップ
「スタンバイ・データベース用の制御ファイルの作成」で作成されたスタンバイ制御ファイル
「スタンバイ・データベース用のパラメータ・ファイルの作成」で作成された初期化パラメータ・ファイル
次の手順を実行して、Windowsベース・サービスの作成、パスワード・ファイルの作成、Oracle Net環境の設定およびSPFILEの作成を行います。
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
スタンバイ・データベースで、V$MANAGED_STANDBYビューを問い合せて、REDOがプライマリ・データベースから送信され、スタンバイ・データベースに適用されていることを確認します。次に例を示します。
SQL> SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY WHERE CLIENT_PROCESS='LGWR' OR PROCESS='MRP0'; CLIENT_PROCESS PROCESS THREAD# SEQUENCE# STATUS -------------- --------- ---------- ---------- ------------ N/A MRP0 1 80 APPLYING_LOG LGWR RFS 1 80 IDLE
問合せ出力はプライマリ・データベースごとにLGWRのCLIENT_PROCESSを含む1行が表示される必要があります。これはREDO転送が正常に機能し、プライマリREDOスレッドがスタンバイに送信されていることを示します。
注意:
プライマリ・データベースがOracle RACデータベースの場合、現在アクティブなプライマリ・インスタンスごとにLGWRのCLIENT_PROCESSを含む1行が表示されます。
問合せ出力もMRPごとに1行が表示される必要があります。MRPステータスがAPPLYING_LOGを示し、SEQUENCE#が現在プライマリ・データベースにより送信されている順序番号と等しい場合、スタンバイではすべてのギャップが解決済で、現在はリアルタイム適用モードになっています。
注意:
MRPはプライマリから現在送信されている順序番号よりも古いSEQUENCE#を示すことがあります。これは、ギャップとして送信されたアーカイブ・ログ・ファイルを適用しているものの、まだ解消されていないことを示します。すべてのギャップが解消されたら、同じ問合せはMRPが現在のSEQUENCE#を適用していることを示すようになります。
この時点で、フィジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次に、フィジカル・スタンバイ・データベースに対して実行できるその他の操作について説明します。
データ保護モードのアップグレード
各種データ保護モードの構成の詳細は、「Oracle Data Guardの保護モード」を参照してください。
フラッシュバック・データベースの有効化
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Oracle Data Guard環境でのフラッシュバック・データベースの使用例は、「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」および「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。
通常のプライマリ・データベースのフィジカル・スタンバイを作成できるように、マルチテナント・コンテナ・データベース(CDB)のフィジカル・スタンバイを作成できます。CDBのフィジカル・スタンバイの作成および使用時に注意する動作の違いの一部を次に示します。
データベース・ロールは個別のコンテナ・レベルではなく、CDBレベルで定義されます。
スイッチオーバー操作またはフェイルオーバー操作を実行する場合、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=sales-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.example.com))
bostonのサービス名は、sales.us.example.comです。
スタンバイ・データベースでCDB_SERVICESビューを問い合せて、CON_IDを確認します。次に例を示します。
SQL> SELECT NAME, CON_ID FROM CDB_SERVICES; NAME CON_ID --------------------------------------------- sales.us.example.com 1
問合せの結果、bostonのCON_IDが1であると示されます。
関連項目:
CDBの詳細は、『Oracle Database概要』を参照してください。
CDBおよびPDBでの権限とロールの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
キーストアの作成の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
この項では、フィジカル・スタンバイを使用しているときに、プライマリ・データベースでPDBを作成する方法について説明します。
Oracle Data Guard構成では、プライマリ・データベースのPDBは、通常のデータベースのPDBを作成するのと同じ方法で作成します。通常のデータベースでPDBを作成する手順は、『Oracle Database管理者ガイド』を参照してください。これらの手順に従う前に、次の点に注意してください。
作成中の新しいPDBがスタンバイCDBに含まれるかどうかを指定するには、SQL CREATE PLUGGABLE DATABASE文のSTANDBYS句を使用します。新しいPDBをすべてのスタンバイCDBに含めるにはALL(デフォルト)を指定します。新しいPDBをすべてのスタンバイCDBから除外するにはNONEを指定します。
PDBがすべてのスタンバイCDBから除外される場合、PDBのデータ・ファイルはオフラインになり、すべてのスタンバイCDBで名前なしとしてマークされます。PDBが作成された後にインスタンス化された新しいスタンバイCDBは、リカバリのために明示的にPDBを無効にし、スタンバイCDBから除外する必要があります。PDBをスタンバイCDBで除外した後に、そのスタンバイCDBで有効にすることができます。
注意:
STANDBYS句は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用できます。
PDBを同じプライマリCDB内の別のPDBのローカル・クローンとして作成する場合、ソースPDBに属するデータファイルをスタンバイ・データベースにコピーします。(PDBをスタンバイ・データベースで作成すると自動的にデータ・ファイルがコピーされるため、Active Data Guard環境ではこの手順は必要ありません。)
別のCDBからプライマリCDBへのPDBのリモート・クローンを実行する場合、STANDBY=NONE句を使用してファイルをコピーし、http://support.oracle.comのMy Oracle Supportノート2049127.1にある次の手順によりリカバリを有効にする必要があります。
PDBをXMLファイルから作成する場合、XMLファイルで指定されたデータファイルをスタンバイ・データベースにコピーします。
スタンバイ・データベースのActive Data Guardオプションが有効な場合(読取り専用でオープン)、プライマリ・データベースにプラグインされるPDBデータ・ファイルと同じセットをスタンバイ・データベースにコピーします。Active Data Guardが有効化されているシステム上で実行されている管理スタンバイ・リカバリまたはデータベース・セッションの中断を最低限に抑えるには、プライマリ・データベースの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言語リファレンス』を参照してください。
キーストアの作成の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
