1. 概要および管理
  2. 概要および管理
  3. フィジカル・スタンバイ・データベースの作成

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がすべて完了するまで待機するためです。

関連項目:

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が適用されると、スタンバイでパスワード・ファイルが更新されます。

関連項目:

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;

アーカイブの詳細は、『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)を作成します。

次の手順を実行します。

  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. 構成されていない場合、スタンバイ・システムにリスナーを構成して、開始します。
  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$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リカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。

関連項目:

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であると示されます。

関連項目:

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が適用されたプライマリでのパス名です。

関連項目: