Data Guard Broker あれこれ

2022.10.05

既存のData Guard 環境をBroker構成に変更する

ここでは、以下のようなData Guard構成がすでにできているという前提で操作を進めている。

  • プライマリのDB_UNIQUE_NAME は DB19P
  • スタンバイのDB_UNIQUE_NAME は DB19S
  • 上記と同じ名前のネットサービス名がそれぞれの tnsnames.ora に設定済み

まず、データベース側の初期化パラメータ DG_BROKER_START を TRUE に変更する必要がある。プライマリとスタンバイ、双方で変更する。

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

パラメータを変更すると、直ちにDMONバックグラウンドプロセスが起動する。この時点でDB側の準備はできているが、まだBroker構成にはなっていない。

RAC環境の場合、DG_BROKER_START を設定する前に、構成ファイルの場所をRACの全ノードから参照可能なASMディスクグループ上に変更する必要がある。

ASM上にディレクトリを作成

$ asmcmd mkdir +data/DB19P/BROKER

構成ファイルの場所を変更

SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1='+DATA/DB19P/BROKER/DR1.DAT';
SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2='+DATA/DB19P/BROKER/DR2.DAT';

DG_BROKER_START を変更したタイミングで、指定した場所に構成ファイルが作成される。

Broker構成の作成と有効化

DGMGRL(Brokerのコマンドラインインターフェース)を使い、以下のようにプライマリデータベースを指定してBroker構成を作成する。

$ dgmgrl
DGMGRL> connect sys/oracle
DGMGRL> create configuration 'db19dg' as primary database is 'db19p' connect identifier is db19p;

ここに、スタンバイデータベースを追加するのだが、その前にスタンバイ側に設定されている LOG_ARCHIVE_DEST_n の中で、リモートのREDO転送先(service=xxxx)が指定されているものは設定を削除しておく必要がある。Broker構成ではリモートのREDO転送先の設定が自動的に行われるため、設定を削除せずに進めると、以下のエラーが発生する。

エラー: ORA-16698: メンバーのLOG_ARCHIVE_DEST_nパラメータでSERVICE属性が設定されています

ちなみに、プライマリ側の設定は残っていても問題ない。上記対処を行ったら、以下のようにスタンバイデータベースを追加する。

DGMGRL> add database 'db19s' as connect identifier is db19s;

この時点でBroker構成の確認コマンドを実行すると、構成は作成されたものの有効にはなっていないことがわかる。

DGMGRL> show configuration

構成 - db19dg

  保護モード: MaxPerformance
  メンバー:
  db19p - プライマリ・データベース
    db19s - フィジカル・スタンバイ・データベース

ファスト・スタート・フェイルオーバー:  Disabled

構成ステータス:
DISABLED

構成を有効化する。これでBroker構成としての最低限の設定は完了。

DGMGRL> ENABLE CONFIGURATION;

静的接続識別子のリスナー構成への追加

スイッチオーバーなどのロールの変更を行う際、Brokerがインスタンスの起動に使用するサービス名として、<db_unique_name>_DGMGRL がデフォルトで設定されている。ただ、Broker構成を作成しても、リスナーに対してこのサービス名に対する静的構成は行われないため、手動で設定を追加する必要がある。例えば、以下のような設定をプライマリ・スタンバイ双方の listener.ora に行う。

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = db19p)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME = db19p)
    )
    (SID_DESC=
     (GLOBAL_DBNAME=db19p_DGMGRL)
     (ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1)
     (SID_NAME=db19p)
    )
  )

RACやRestartなど、リスナーがクラスタウェアに管理されている場合は静的接続識別子の設定は不要。

スイッチオーバーを実行する

Broker構成でスイッチオーバーを実行する場合は、dgmgrl経由でswitchoverコマンドを実行する。

スイッチオーバーする前に検証コマンドを実行する。構成に問題がなければ、以下のような結果が返ってくるはずである。

DGMGRL> validate database 'db19p'

  データベース・ロール:  プライマリ・データベース

  スイッチオーバー可能:  はい

  フラッシュバック・データベースのステータス:
    db19p:  オフ

  クラスタウェアにより管理される:
    db19p:  NO
    データベースdb19pの静的接続識別子を検証しています...
    静的接続識別子を使用してデータベース"db19p"に接続できます。

DGMGRL> validate database 'db19s'

  データベース・ロール:        フィジカル・スタンバイ・データベース
  プライマリ・データベース:  db19p

  スイッチオーバー可能:  はい
  フェイルオーバー可能:  はい (プライマリ実行中)

  フラッシュバック・データベースのステータス:
    db19p:  オフ
    db19s:  オフ

  クラスタウェアにより管理される:
    db19p:  NO
    db19s:  NO
    データベースdb19pの静的接続識別子を検証しています...
    静的接続識別子を使用してデータベース"db19p"に接続できます。

私の環境では、以下のような警告が返ってくることがあった。

  現在のログ・ファイル・グループの構成:
    スレッド番号オンラインREDOログ・グループスタンバイREDOログ・グループステータス
              (db19p)                 (db19s)
    1         3                       2                       不十分なSRL

  今後のログ・ファイル・グループの構成:
    スレッド番号オンラインREDOログ・グループスタンバイREDOログ・グループステータス
              (db19s)                 (db19p)
    1         3                       1                       不十分なSRL

スタンバイREDOログのグループが足りないことを示すメッセージのようだが、実際には正しい数のスタンバイREDOログが構成されているはずだった。どうやら、スタンバイREDOログの作成時にTHREADを明示的に指定していないとこのようなメッセージが返ってくることがあるようだ。その場合このメッセージは無視可能。気になるようであれば以下のようにスタンバイREDOログを再作成すれば解消する。

ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 5;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 6;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 7;

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 
group 4 ('/u01/app/oracle/oradata/DB19P/stredo01.log') SIZE 200M,
group 5 ('/u01/app/oracle/oradata/DB19P/stredo02.log') SIZE 200M,
group 6 ('/u01/app/oracle/oradata/DB19P/stredo03.log') SIZE 200M,
group 7 ('/u01/app/oracle/oradata/DB19P/stredo04.log') SIZE 200M;

ほかに問題がなければ、以下のコマンドでスイッチオーバーを実行する。

DGMGRL> switchover to db19s

Broker構成でalter database switchoverを実行したらどうなるか

非Broker構成では、スイッチオーバーの実行を alter database switchover コマンドで行うが、Broker構成としているにもかかわらずこのコマンドを実行したらどうなるのか。

実際にやってみると、Broker構成によってスタンバイ側のREDO転送先設定が削除されているため、スイッチオーバー後はREDO転送が再開できない状態になってしまう。Broker側が自動的に設定を修正してくれることはなく、構成状況を確認してみても以下のようにエラーとなる。

DGMGRL> show configuration

構成 - db19dg

  保護モード: MaxPerformance
  メンバー:
  db19p - プライマリ・データベース
    エラー: ORA-16816: データベース・ロールが正しくありません

    db19s - フィジカル・スタンバイ・データベース
      エラー: ORA-16816: データベース・ロールが正しくありません

ファスト・スタート・フェイルオーバー:  Disabled

構成ステータス:
ERROR   (ステータスは12秒前に更新されました)

この状態から回復するためには、新しいプライマリ側に手動でREDO転送先設定を行い、再度スイッチオーバー(この時は alter database switchover を行うしかない)してBrokerが認識しているロールの状態に戻す必要がある。

スナップショットスタンバイに変換

スタンバイデータベースをスナップショットスタンバイに変換すると、スタンバイ側を更新可能な状態にすることができる。

DGMGRL> convert database 'db19s' to snapshot standby;
DGMGRL> convert database 'db19s' to snapshot standby;
データベース"db19s"をスナップショット・スタンバイ・データベースに変換中です。お待ちください...
データベース"db19s"は正常に変換されました

DGMGRL> show configuration

構成 - db19dg

  保護モード: MaxPerformance
  メンバー:
  db19p - プライマリ・データベース
    db19s - スナップショット・スタンバイ・データベース

ファスト・スタート・フェイルオーバー:  Disabled

構成ステータス:
SUCCESS   (ステータスは56秒前に更新されました)

再度フィジカルスタンバイデータベースに変換することで、スナップショットスタンバイ状態で更新した内容をすべて破棄して、プライマリと同じ状態に戻すことができる。

DGMGRL> convert database 'db19s' to physical standby;
DGMGRL> convert database 'db19s' to physical standby;
データベース"db19s"をフィジカル・スタンバイ・データベースに変換中です。お待ちください...
操作にはデータベース"db19p"への接続が必要です
接続中...
"db19p"に接続しました
SYSDBAとして接続しました。
Oracle Clusterwareはデータベース"db19s"を再起動しています...
"db19s"に接続しました
"db19s"に接続しました
データベース"db19s"の変換を続行します...
データベース"db19s"は正常に変換されました
スポンサーリンク

コメント