3 フィジカル・スタンバイ・データベースの作成
非同期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ビューがあります。
3.1 スタンバイ・データベースを作成するためのプライマリ・データベースの準備
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。
フィジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースで次の準備作業を実行します。
注意:
これらの準備のためのタスクは、1回のみ実行してください。これらの手順を完了すると、データベースは、1つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。
3.1.1 強制ロギングの有効化
スタンバイ・データベースを作成するためのプライマリ・データベースの準備の一部として、プライマリ・データベースをFORCE LOGGING
モードで配置します。
これは、データベース作成後に、次のSQL文を使用して実行できます。
SQL> ALTER DATABASE FORCE LOGGING;
この文を発行する場合、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。
関連項目:
-
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つの例に示した各パラメータ設定に関する簡単な説明を示します。
パラメータ | お薦めする設定 |
---|---|
プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースの |
|
各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
Oracle Data Guardの機能を完全に有効にするには、このパラメータの |
|
プライマリ・データベースの制御ファイルのパス名を指定します。制御ファイルの別のコピーを用意しておき、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後、容易にインスタンスを再開できるようにしておくことをお薦めします。 |
|
REDOデータがアーカイブされるプライマリ・システムおよびスタンバイ・システムの位置を指定します。
注意: 高速リカバリ領域を( |
|
リモート・ログイン・パスワード・ファイルを使用して管理ユーザーまたはREDO転送セッションを認証する場合は、このパラメータを |
|
スレッド(%t)、順序番号(%s)およびリセットログID(%r)を使用して、アーカイブREDOログ・ファイルのフォーマットを指定します。 |
|
FALサーバー(通常はプライマリ・ロールで実行中のデータベース)のOracle Netサービス名を指定します。シカゴのデータベースがスタンバイ・ロールで実行されている場合、ボストンのデータベースが欠落しているログ・ファイルを自動的に送信できなければ、ボストンのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
|
スタンバイ・データベースのデータファイルのパス名とファイル名の位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのデータファイルのパス名がスタンバイ・データファイルのパス名に変換されます。このパラメータは、フィジカル・スタンバイ・データベースのパス名の変換にのみ使用されます。このパラメータにより、複数のペアのパスを指定できます。 |
|
スタンバイ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にプライマリの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。このパラメータにより、複数のペアのパスを指定できます。 |
|
データファイルがプライマリ・データベースに追加または削除された場合に、それに対応してスタンバイ・データベースも自動的に変更されるように、 |
注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。
3.1.5 アーカイブの有効化
アーカイブが有効になっていない場合は、プライマリ・データベースをARCHIVELOG
モードにし、自動アーカイブを有効にする必要があります。
次のSQL文を発行します。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN;
アーカイブの詳細は、『Oracle Database管理者ガイド』を参照してください。
3.2 フィジカル・スタンバイ・データベースの作成手順
フィジカル・スタンバイ・データベースの作成で実行するタスクを次に示します。
次のトピックを十分に理解していることが求められます。
-
データベース管理者の認証
-
データベース初期化パラメータ
-
REDOログ、データファイルおよび制御ファイルの管理
-
アーカイブREDOログの管理
-
高速リカバリ領域
-
Oracle Net構成
表3-1は、フィジカル・スタンバイ・データベースの作成で実行するタスク、および各タスクを実行するデータベースのチェックリストです。
表3-1 フィジカル・スタンバイ・データベースの作成
タスク | データベース |
---|---|
プライマリ |
|
プライマリ |
|
プライマリ |
|
プライマリ |
|
スタンバイ |
|
スタンバイ |
|
スタンバイ |
3.2.1 フィジカル・スタンバイの作成 タスク1: プライマリ・データベース・データファイルのバックアップ・コピーの作成
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。Recovery Manager(RMAN)ユーティリティを使用することをお薦めします。
バックアップの推奨については『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を、データベースのバックアップ操作の実行については『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)を作成します。
次の手順を実行します。
例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ログ・ファイルがフェッチ(要求)されます。 |
注意:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。
3.2.4 フィジカル・スタンバイの作成 タスク4: プライマリ・システムからスタンバイ・システムへのファイルのコピー
必要なディレクトリがすべて作成されていることを確認します。オペレーティング・システムのコピー・ユーティリティを使用して、プライマリ・システムのバイナリ・ファイルをスタンバイ・システムの正しい場所にコピーします。
コピーするバイナリ・ファイルは次のとおりです。
-
「プライマリ・データベース・データファイルのバックアップ・コピーの作成」で作成されたデータベース・バックアップ
-
「スタンバイ・データベース用の制御ファイルの作成」で作成されたスタンバイ制御ファイル
-
「スタンバイ・データベース用のパラメータ・ファイルの作成」で作成された初期化パラメータ・ファイル
3.2.5 フィジカル・スタンバイの作成 タスク5: スタンバイ・データベースをサポートする環境の設定
環境設定として、Windowsベース・サービス、パスワード・ファイルおよびSPFILEを作成し、Oracle Net環境を設定します。
次の手順を実行します。
3.2.7 フィジカル・スタンバイの作成 タスク7: フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
スタンバイ・データベースで、V$MANAGED_STANDBY
ビューを問い合せて、REDOがプライマリ・データベースから送信され、スタンバイ・データベースに適用されていることを確認します。
次に、V$MANAGED_STANDBY
ビューの問合せの例を示します。
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#
を適用していることを示します。
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のフィジカル・スタンバイ・データベースを作成するために使用できます。
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を作成する手順は、『Oracle Database管理者ガイド』を参照してください。これらの手順に従う前に、次の点に注意してください。
-
Oracle Database 12cリリース1 (12.1)では、PDBをプライマリ・デーベースに追加する際に指定できるのは、PDBが作成されてすべてのスタンバイでリカバりされた(
ALL
)か、どのスタンバイにもリカバリされていない(NONE
)かのみです。 Oracle Database 12cリリース2 (12.2.0.1)以降、すべてのPDBを選択するか何も選択しないかのかわりに、マルチテナント・コンテナ・データベース(CDB)のフィジカル・スタンバイに複製するPDBのサブセットを指定できます。このためには、ENABLED_PDBS_ON_STANDBY
初期化パラメータを使用してPDBのリストを指定するか、拡張STANDBYS
クオリファイアをCREATE PLUGGABLE DATABASE
文で使用するか、あるいはその両方を実行します。スタンバイCDB上で有効化されていないPDBは、無効化のまま残すか(真のSUBSETスタンバイ)、後日すべての必須ファイルがスタンバイCDBで使用可能になったときに有効化できます。 -
ENABLED_PDBS_ON_STANDBY
パラメータはフィジカル・スタンバイ上でのみ有効で、プライマリ・データベースにより無視されます。(プライマリ・データベースに設定できるのは、そのデータベースがスタンバイ・データベースになったときに使用される場合のみです。)これは、どのPDBをフィジカル・スタンバイ・データベースで有効化するかしないかを指定するために使用できます。 このパラメータが指定されていない場合、STANDBYS
句が使用されていないかぎりCDB内のすべてのPDBがスタンバイ上に作成されます。このパラメータの詳細は、ENABLED_PDBS_ON_STANDBYを参照してください。 -
作成中の新しいPDBをどのスタンバイCDBに含めるかを指定するには、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に含めます。
CDB名のリストの前後にはカッコが必要で、それぞれの名前を一重引用符で囲む必要があります。
DB_UNIQUE_NAME
の値には最大30文字を指定できます。大/小文字は区別されません。データベース名で有効な文字は、英数字、アンダースコア(_)、シャープ記号(#)およびドル記号($)です。注意:
EXCEPT
句は、Oracle Database 12cリリース2 (12.2.0.1)以降で使用できます。 -
-
PDBを異なるPDBまたは同じプライマリCDB内のシードPDBからのローカル・クローンとして作成するには、ソースPDBに属するデータ・ファイルをスタンバイ・データベースにコピーします。(この手順はOracle Active Data Guard環境では必要ありません。PDBがスタンバイ・データベースに作成されるとデータ・ファイルがスタンバイにコピーされるためです。)
別のCDBからプライマリCDBへのPDBのリモート・クローンを実行するには、
STANDBY=NONE
句を使用してファイルをコピーし、http://support.oracle.com
のMy Oracle Supportノート2049127.1にある次の手順によりリカバリを有効にする必要があります。 -
PDBをXMLファイルから作成するには、XMLファイルで指定されたデータ・ファイルをスタンバイ・データベースにコピーします。
スタンバイ・データベースでOracle Active Data Guardオプションが有効化されている場合(読取り専用でオープン)、プライマリ・データベースにプラグインされるPDBデータ・ファイルと同じセットをそのスタンバイ・データベースにコピーします。Oracle 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言語リファレンス』を参照してください。