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 適切なロギング・モードの有効化
スタンバイ・データベースを作成するためのプライマリ・データベースの準備の一部として、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つの例に示した各パラメータ設定に関する簡単な説明を示します。
パラメータ | お薦めする設定 |
---|---|
プライマリ・データベースで、データベースが作成されたときに使用された名前を指定します。フィジカル・スタンバイ・データベースで、プライマリ・データベースの |
|
各データベースの一意の名前を指定します。この名前はデータベースと固定され、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
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;
ノート:
スタンバイ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)を作成します。
次のステップを実行します。
例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$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のフィジカル・スタンバイ・データベースを作成するために使用できます。
createDuplicateDB
です。
基本の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
句は、リカバリが後で有効になるか無効になるかに影響しません。SQLCREATE 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の作成に使用するSQLCREATE 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
/datafileGUID
パラメータは、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言語リファレンス』を参照してください。