Data Guard Broker によるスイッチオーバーとフェイルオーバー (Oracle Database 19c)

スイッチオーバーとフェイルオーバー

　Data Guard 環境でプライマリ・データベースとスタンバイ・データベースの役割を交換する処理をスイッチオーバーと呼びます。この処理はプライマリ・データベースとスタンバイ・データベースのデータが完全に同じ状態であり、どちらのデータベースも起動していることが前提となります。一方、プライマリ・データベースの状態に依存せず、スタンバイ・データベースを新しいプライマリ・データベースに変換することをフェイルオーバーと呼びます。
Data Guard Broker ではどちらの処理もコマンド１行で実行することができます。

スイッチオーバーの条件

　Data Guard Broker はスイッチオーバーを実現するために、プライマリ・データベースとスタンバイ・データベースの同一性をチェックします。以下の VALIDATE DATABASE 文の例ではスイッチオーバーは可能だが、プライマリ・データベース（O19A）に、スタンバイREDOログ・ファイルが存在しない警告が出力されています。

VALIDATE DATABASE 文の実行

DGMGRL> VALIDATE DATABASE O19S

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

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

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

 クラスタウェアにより管理される:
   O19A:  YES
   O19S:  YES

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

 今後のログ・ファイル・グループの構成:
   スレッド番号オンラインREDOログ・グループスタンバイREDOログ・グループステータス
             (O19S)                  (O19A)                                                   
   1         4                       0                       不十分なSRL
   
   警告: スタンバイREDOログがスレッド1 (O19A上)に対して構成されていません

警告メッセージは好ましくないため、スタンバイ REDO ログを作成（ALTER DATABASE ADD STANDBY LOG 文）して再度、VALIDATE DATABASE 文を実行します。警告が解消されていることがわかります。

警告が解消された VALIDATE DATABASE 文

DGMGRL> VALIDATE DATABASE 'O19S';

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

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

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

  クラスタウェアにより管理される:
    O19A:  YES
    O19S:  YES

スイッチオーバーの実施

スイッチオーバーを実行するには SWITCHOVER TO {新プライマリ} 文を実行します。

スイッチオーバーの実行

DGMGRL> SWITCHOVER TO 'O19S'
現在スイッチオーバーを実行しています。お待ちください...
操作にはデータベース"O19S"への接続が必要です
接続中...
"O19S"に接続しました
SYSDBAとして接続しました。
新しいプライマリ・データベース"O19S"がオープン中です...
Oracle Clusterwareはデータベース"O19A"を再起動しています...
[W000 2025-04-21T15:37:59.714+09:00] Failed to attach to o19a.
<<< 途中省略 >>>
[W000 2025-04-21T15:38:13.739+09:00] Failed to attach to o19a.
"O19A"に接続しました
"O19A"に接続しました
スイッチオーバーに成功しました。新しいプライマリは"O19S"です

DGMGRL> SHOW CONFIGURATION

構成 - dg1_config

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

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

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

旧プライマリ・データベース（新スタンバイ・データベース）のトレース・ファイルを確認すると、最初にスイッチオーバーの確認（SWITCHOVER VERIFY）が実行され、その後 ALTER DATABASE SWITCHOVER TO 文が実行されていることがわかります。

2025-04-21T15:37:39.568410+09:00
SWITCHOVER VERIFY: Send VERIFY request to switchover target O19S
SWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVER
SWITCHOVER VERIFY: Send VERIFY request to switchover target O19S
SWITCHOVER VERIFY COMPLETE: READY FOR SWITCHOVER
2025-04-21T15:37:39.869392+09:00
Stopped service srv01
2025-04-21T15:37:40.946357+09:00
ALTER DATABASE SWITCHOVER TO 'O19S'

旧スタンバイ・データベースでも SWITCHOVER VERIFY のログがあり、新プライマリ・データベースとして起動しています。

2025-04-21T15:37:34.537722+09:00
 rfs (PID:63717): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:1862189)
2025-04-21T15:37:34.619622+09:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE
2025-04-21T15:37:34.717024+09:00
<<途中省略>>
ALTER SYSTEM SET fal_server='o19a' SCOPE=BOTH;
2025-04-21T15:37:36.000541+09:00
 rfs (PID:63741): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:1867574)
2025-04-21T15:37:36.087170+09:00
<<途中省略>>
2025-04-21T15:37:39.211393+09:00
Media Recovery Continuing
PR00 (PID:62621): Media Recovery Waiting for T-1.S-266
2025-04-21T15:37:40.242471+09:00
.... (PID:63760): The Time Management Interface (TMI) is being enabled for role transition
.... (PID:63760): information.  This will result in messages beingoutput to the alert log
.... (PID:63760): file with the prefix 'TMI: '.  This is being enabled to make the timing of
.... (PID:63760): the various stages of the role transition available for diagnostic purposes.
.... (PID:63760): This output will end when the role transition is complete.
SWITCHOVER: received request 'ALTER DATABASE COMMIT TO SWITCHOVER  TO PRIMARY' from primary database.
2025-04-21T15:37:40.242876+09:00
ALTER DATABASE SWITCHOVER TO PRIMARY (O19S)
Maximum wait for role transition is 15 minutes.
TMI: kcv_commit_to_so_to_primary wait for MRP to finish BEGIN 2025-04-21 15:37:40.242981
Switchover: Media recovery is still active

フェイルオーバーの実施

　フェイルオーバーを実行するには、スタンバイ・データベースに接続して FAILOVER TO 文を実行します。フェイルオーバーした後の旧プライマリ・データベースは Data Guard 構成から離脱しています。旧プライマリ・データベースは OPEN 状態のままです。

フェイルオーバーの実行

DGMGRL> CONNECT SYS/{パスワード}@O19S
"O19S"に接続しました
SYSDBAとして接続しました。

DGMGRL> FAILOVER TO 'O19S'
現在フェイルオーバーを実行しています。お待ちください...
フェイルオーバーに成功しました。新規プライマリは"O19S"です

DGMGRL> VALIDATE DATABASE 'O19A'
エラー: ORA-16541: メンバーは有効ではありません

DGMGRL> VALIDATE DATABASE 'O19S'

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

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

  クラスタウェアにより管理される:
    O19S:  YES

プライマリ・データベースに接続してフェイルオーバーを実行しようとするとエラー ORA-16600 が発生します。

プライマリ・データベースに接続してフェイルオーバーの実行

DGMGRL> FAILOVER TO 'O19S';
現在フェイルオーバーを実行しています。お待ちください...
エラー: ORA-16600: フェイルオーバー対象のターゲット・スタンバイ・データベースに接続されていません

失敗しました。
フェイルオーバーできません

プライマリ・データベースの再復帰

　フェイルオーバーを行うと、プライマリ・データベースとスタンバイ・データベースの関係は切れますが、旧プライマリを再度スタンバイ・データベースとして元に戻すことができます。内部的にはフラッシュバック・データベースを使ってデータベースへの更新を巻き戻し、同期がとれる状態から再度 Data Guard 環境を構築します。このためには ALTER DATABASE 文によりフラッシュバック機能を有効化する必要があります。

フラッシュバック・データベースの有効化（プライマリ）

SQL> ALTER DATABASE FLASHBACK ON;

データベースが変更されました。

SQL> SELECT flashback_on FROM v$database;

FLASHBACK_ON
------------------
YES

　Data Guard スタンバイ・データベース上ではフラッシュバック・データベースの有効化は実行できません。一時的に Data Guard 構成を停止してから ALTER DATABASE 文を実行します。

スタンバイ・データベースのフラッシュバック・データベースの有効化

SQL> ALTER DATABASE FLASHBACK ON;
ALTER DATABASE FLASHBACK ON
*
行1でエラーが発生しました。:
ORA-01153: 非互換のメディア・リカバリがアクティブです。

一時的に Data Guard による同期を停止するには DGMGRL ゆーてぃりてｘから EDIT DATABASE 文を実行します。

REDO適用の無効化と有効化

DGMGRL> EDIT DATABASE 'O19S' SET STATE='APPLY-OFF';
成功しました。

--- フラッシュバックの有効化

DGMGRL> EDIT DATABASE 'O19S' SET STATE='APPLY-ON';
成功しました。

　フェイルオーバー後の旧プライマリ・データベースを Data Guard 環境に戻す場合は REINSTATE DATABASE 文を実行します。この実行は復旧するデータベース以外に接続して実行する必要があります。旧プライマリ・データベースは再起動され、自動的にフラッシュバック・データベースによる巻き戻しと、Data Guard スタンバイ・データベースとして起動します。

フェイルオーバー後の再同期

DGMGRL> REINSTATE DATABASE 'O19A'
データベース"O19A"を修復しています。お待ちください...
Oracle Clusterwareはデータベース"O19A"を再起動しています...
[W000 2025-04-21T17:43:30.296+09:00] Failed to attach to o19a.
<<省略>>
[W000 2025-04-21T17:43:43.317+09:00] Failed to attach to o19a.
"O19A"に接続しました
"O19A"に接続しました
データベース"O19A"の修復を続行します...
データベース"O19A"の修復に成功しました

DGMGRL> SHOW DATABASE O19A

データベース - O19A

  ロール:          PHYSICAL STANDBY
  意図した状態  APPLY-ON
  トランスポート・ラグ: 0 秒 (0秒前に計算されました)
  適用ラグ:       0 秒 (0秒前に計算されました)
  平均適用頻度: 348.00 KB/秒
  リアルタイム問合せ: OFF
  インスタンス:
    O19A

データベース・ステータス:
SUCCESS

　復旧対象のデータベース（例では O19A）に接続して REINSTATE DATABASE 文を実行しても、ORA-16815 エラーが発生します。

フェイルオーバーで切り離されたデータベース

DGMGRL> REINSTATE DATABASE 'O19A'
データベース"O19A"を修復しています。お待ちください...
エラー: ORA-16815: メンバーを元の状態に戻す必要はありません

失敗しました。
データベース"O19A"の修復に失敗しました

Author: Noriyoshi Shinoda / Date: April 21, 2025