ロール・トランジション、アセスメントおよびチューニング

綿密な計画、構成およびチューニングに基づいたOracle Data Guardのロール・トランジションにより、停止時間を効果的に最小化し、ビジネスへの影響を最小限に抑えながらデータベース環境をリストアできます。

フィジカル・スタンバイ・データベースを使用する場合、Oracle MAAのテスト結果では、Oracle Data Guardによるスイッチオーバーとフェイルオーバーの時間は数秒間に短縮されました。この項では、スイッチオーバーとフェイルオーバーのベスト・プラクティスについて説明します。ベスト・プラクティスに従う一方で、Oracle RACのスイッチオーバー時間は約30秒、単一インスタンス・データベースでは10秒未満であることが確認されています。検出時間は別々です。

ロール・トランジション前のData Guardヘルス・チェックの前提条件

次の前提条件を完了してから、スイッチオーバー操作を実行してください。

四半期ごと

四半期ごとに次のステップを実行します。

  1. Oracle Data Guard構成がMAAに準拠していることを確認します。

    1. 「Oracle AI Database構成のベスト・プラクティス」と「Oracle Data Guardの構成ベスト・プラクティス」を参照して、推奨されているData Guard構成のプラクティスがすべて適用されていることを確認します。

    2. PDBサービスの推奨事項については、「Oracle Multitenantのベスト・プラクティスの概要」を参照してください。

  2. 単純なアプリケーション・テストを実行します。これには次のことが含まれています。

    1. 既存のスタンバイ・データベースをスナップショット・スタンバイに変換します。

    2. 読取り/書込みテスト・データベースへのアプリケーション接続を、これが障害時リカバリ・テストであったかのように検証します。構成のガイダンスについては、「アプリケーションの継続的な可用性の構成」を参照してください。

  3. Data Guardロール・トランジション後にエンドツーエンドのアプリケーション・フェイルオーバーをテストします

    1. Data Guardスイッチオーバーを発行します。

    2. アプリケーション全体のフェイルオーバーを調整します。

    3. スイッチ・バックはオプションです。

スイッチオーバーの1か月前

スイッチオーバー操作を実行する1か月前に、MOSノート「Oracle Database 19cの重要な推奨個別パッチ(ドキュメントID 555.1)」を参照して、ご使用のリリースに影響を及ぼす可能性がある重大な問題を特定します。

また、Data Guardスイッチオーバー操作を含むターゲット計画メンテナンス期間中に永続的な接続を作成する監視、監査およびデータベース・バックアップなどの長時間実行されているレポートまたはジョブを一時停止または停止することを検討してください。

Oracle Multitenantデータベースを使用したData Guardロール・トランジションの実行中にアプリケーション・サービスの可用性に影響を与える一般的な構成問題を次に示します。

  • PDBの保存された状態またはトリガーが使用され、Data Guardロール・トランジション中に失敗します

  • アプリケーション・サービスのPDBごとにOracleクラスタウェア管理の個別のサービスを使用するかわりに、PDBのデフォルト・サービスが利用されます

  • ウォレット/セキュリティ設定がスタンバイで異なっています

アプリケーション・サービスとアプリケーション・フェイルオーバーの準備を確実にするには、次の点に留意します。

  1. PDBのデフォルト・サービス、SAVED STATE (再配置操作時を除く)またはデータベース・トリガーを使用してロールベースのサービスを管理しないでください。

  2. アプリケーション・サービスには、PDBごとにクラスタウェア管理の個別サービスを使用し、そのアプリケーション・サービスを利用してデータベースに接続します。

  3. クラスタウェア管理のアプリケーション・サービスを定義する場合は、どのPDBとサービスを起動するか、どのOracle RACインスタンスとデータベース・ロールで起動するかを定義します。

  4. Data Guardの場合、ロールを各クラスタウェア管理サービスに割り当てることで、常にロールベースのサービスを使用します。

データベースのスイッチオーバーおよびフェイルオーバーの準備状況の検証

VALIDATEコマンドを使用すると、ロール変更を実行する前に包括的な一連のデータベース・チェックを実行できます。このコマンドは、次の項目を確認します。

  • スタンバイ・データベースに、失われたREDOデータがあるかどうか
  • フラッシュバックが有効かどうか
  • 構成されている一時表領域ファイルの数
  • オンライン・データ・ファイルの移動が進行中かどうか
  • フィジカル・スタンバイ・データベースの場合、オンラインREDOログがクリアされているかどうか
  • プライマリ・データベースの場合、スタンバイREDOログがクリアされているかどうか
  • オンライン・ログ・ファイル構成
  • スタンバイ・ログ・ファイル構成
  • 適用関連のプロパティ設定
  • 転送関連のプロパティ設定
  • 自動診断リポジトリにエラーがあるかどうか(制御ファイルの破損、システム・データ・ファイルの問題、ユーザー・データ・ファイルの問題など)

スイッチオーバーの前に発行する必要がある、3つの主要なVALIDATEコマンドを次に示します。

  1. VALIDATE DATABASE VERBOSE standby - VALIDATE DATABASEコマンドでは、データベースについて簡潔な概要が表示され、検出されたエラーまたは警告が報告されます。VALIDATE DATABASE VERBOSEでは、簡潔な概要の全内容に加え、検証されたすべての項目が表示されます。
  2. VALIDATE DATABASE standby SPFILE - VALIDATE DATABASE SPFILEコマンドでは、プライマリ・データベースと指定のスタンバイ・データベースの間のパラメータの相違が報告されます。
  3. VALIDATE NETWORK CONFIGURATION FOR ALL - VALIDATE NETWORK CONFIGURATIONコマンドでは、構成のメンバー間のネットワーク接続性チェックが実行されます。

ロール・トランジションの準備状況を評価する方法を簡単に説明します。次のことを確認してください。

  • PRIMARY DATABASEセクション: 

    • DGMGRL> VALIDATE DATABASE VERBOSE 'Primary_DBName';

    • プライマリ・データベースでPDBの保存済状態があるかどうかを確認します。

      • SELECT * FROM dba_pdb_saved_states;

    • exachkまたはorachkを使用してヘルスを評価します。

  • 各STANDBY DATABASE STANDBY_DB_UNIQUE_NAMEセクション: 

    • DGMGRL> VALIDATE DATABASE VERBOSE 'Standby_DBName';
    • DGMGRL> VALIDATE DATABASE 'Standby_DBName' SPFILE;

    • exachkまたはorachkを使用してヘルスを評価します。

    • スタンバイ・クラスタおよびデータベースがプライマリ・クラスタおよびデータベースと対称であるかどうかを評価します。これにより、ロール・トランジション後のパフォーマンスが等しくなるか近くなることが保証されます。

    • クラスタの形状およびシステム・リソースが同じかどうか、spfileのメモリー設定が同じかどうか、およびクラスタ・リソースを共有するデータベースの数が同じかどうかを評価します。そうでない場合は、exawatcherグラフまたはoswatcherグラフを確認することで、差異を強調表示し、システム・リソースを利用可能かどうかを評価します。

  • ネットワーク・セクション:

    • DGMGRL> VALIDATE NETWORK CONFIGURATION FOR ALL;

  • REDO率履歴セクション:

    • SQL> SELECT thread#,sequence#,blocks*block_size/1024/1024 MB,(next_time-first_time)*86400 sec,
 blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s"
 FROM v$archived_log
 WHERE ((next_time-first_time)*86400<>0) and first_time
 between to_date('2015/01/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
 and to_date('2015/01/15 11:00:00','YYYY/MM/DD HH24:MI:SS') and dest_id=1
 order by first_time;

例:

Oracle Data Guard BrokerのVALIDATE DATABASEコマンドは、スイッチオーバーおよびフェイルオーバーの準備状況に関連する情報を収集します。

スタンバイ・データベースとプライマリ・データベースがアクセス可能であることと、適用ラグがターゲット・データベースのApplyLagThreshold未満であることが検証されています。これらのデータ・ポイントが有益である場合は、次に示すように、コマンド出力に"Ready for Failover: Yes"と表示されます。また、REDO転送が実行中の場合は、コマンド出力に"Ready for Switchover: Yes"と表示されます。 

DGMGRL> validate database [verbose] database_name

Database Role: Physical standby database
 Primary Database: standby_db_unique_name

Ready for Switchover: Yes
 Ready for Failover: Yes (Primary Running)

VALIDATE DATABASEは、オンラインREDOログがクリアされたかどうか、一時表領域の数、プライマリとスタンバイの間のパラメータの不一致、フラッシュバック・データベースのステータスなど、スイッチオーバー時間およびデータベース・パフォーマンスに影響する可能性のある追加情報をチェックします。

ほとんどのフェイルオーバーでは、プライマリ・データベースがクラッシュしているか、使用できなくなっています。Ready for Failoverという出力は、VALIDATE DATABASEが発行されたときにプライマリ・データベースが実行されているかどうかを示します。この状態からのフェイルオーバーは可能ですが、構成にプライマリ・データベースが2つあるスプリット・ブレインというシナリオを回避するため、フェイルオーバーを発行する前にプライマリ・データベースを停止することをお薦めします。ファスト・スタート・フェイルオーバーが使用されている場合、ブローカではフェイルオーバー時のスプリット・ブレインの回避のみが保証されます。

また、構成監視ツールとして、VALIDATE DATABASE VERBOSE standby、VALIDATE DATABASE standby SPFILEおよびVALIDATE NETWORK CONFIGURATION FOR ALLを定期的に実行する必要があります。

スイッチオーバーの数日前

Data Guardスイッチオーバーを実行する数日前に、次のステップを実行します。

  1. Data Guardブローカのトレース・レベルを設定します。

    Data GuardブローカのTraceLevel構成プロパティは、構成のすべてのメンバーに対してブローカが実行するトレースの量を制御するために使用されます。プロパティをUSERに設定すると、トレース対象は、完了した操作と、操作またはヘルス・チェックから発生する警告またはエラー・メッセージに制限されます。プロパティをSUPPORTに設定すると、問題のトラブルシューティングに必要な低レベルの情報が含まれ、トレースの量が増大します。 

    DGMGRL> EDIT CONFIGURATION SET PROPERTY TraceLevel = SUPPORT;

  2. ロール・トランジションのメトリックを有効にします。

    時間管理インタフェース(TMI)イベントは、Oracleで特定のコールが実行されるたびにアラート・ログに行を追加するオーバーヘッドの低いイベントです。

    アラート・ログ内のこれらのエントリ(またはタグ)は、コールの開始と終了を表します。次のトピックの表は、主要なスイッチオーバー操作とフェイルオーバー操作の説明を示しています。時間がどこに費やされているかを判断するには、これが最も正確な方法です。

    すべてのデータベースで、データベース・レベル・イベントを16453、トレース名をcontext forever、レベルを15に設定します。このトレースを有効にする方法が2つあります。EVENTデータベース・パラメータを使用する方法と、システム・レベルでEVENTSを設定する方法です。違いは、EVENTパラメータが動的ではなく、再起動後も保持されることです。SET EVENTSは動的ですが、データベースの再起動後は保持されません。次の例を参照してください。 

    ALTER SYSTEM SET EVENT=‘16453 trace name contextforever, level 15’ scope=spfile sid=’*’;
    ALTER SYSTEM SET EVENTS ‘16453 trace name context forever, level 15’;

Data Guardロール・トランジション

Oracle Data Guardブローカ、または最終的にData Guardブローカ・コマンドをコールする任意のOracle UIまたはユーティリティを必ず使用します。

長時間実行されているレポートまたはバッチ・ジョブ(永続的な接続がある監視、監査およびデータベース・バックアップなど)を一時停止または停止します。

Oracle Data Guard BrokerのSWITCHOVERコマンドを使用してスイッチオーバーを開始し、FAILOVERコマンドを使用してフェイルオーバーを開始します。

スイッチオーバー操作またはフェイルオーバー操作の一環として、ブローカは次のことを実行します。

  • 新しいプライマリ・データベースからREDO転送を構成します
  • 新しいスタンバイ・データベースでREDO適用を開始します
  • ブローカ構成内の他のスタンバイ・データベースが実行可能で、新しいプライマリからREDOを受信していることを確認します
  • Oracle ClusterwareとGlobal Data Servicesを統合して、ロールベースのサービスが必ず開始されるようにします

Data Guardスイッチオーバーを発行する前に、長時間実行されるレポート作成やジョブ(永続的な接続を作成する監視、監査、データベース・バックアップなど)を一時停止または停止します。

スイッチオーバーを開始するようにブローカを構成するには、SYSまたはSYSDBAとしてログインして、次を発行します。

DGMGRL> SWITCHOVER TO database_name;

フェイルオーバーを開始するようにブローカを構成するには、次を実行します:

DGMGRL> FAILOVER TO database_name [IMMEDIATE];

デフォルトでは、FAILOVERはフェイルオーバー前に受信したすべてのREDOを適用します。IMMEDIATE句を指定すると、保留中のREDOがスキップされ、すぐにフェイルオーバーされます。

SWITCHOVERコマンドおよびFAILOVERコマンドは多重呼出し不変であり、万一遷移が失敗した場合には再発行できます。

Data Guardロール・トランジションの監視

Data Guardロール・トランジションが行われている間は、Data Guard Brokerのメッセージを参照してください。詳細なロール・トランジションのステータスを抽出するには、プライマリおよびスタンバイのアラート・ログと、Data Guardスイッチオーバーおよびフェイルオーバーのメッセージとタグのブローカ・ログを参照してください。

主要なスイッチオーバー操作とアラート・ログ・タグ

スイッチオーバーは、次の4つの主なステップに分けられます。

  1. Convert to Standby - 既存の本番セッションを終了し、制御ファイルをスタンバイ制御ファイルに変換し、スタンバイにメッセージを送信してスイッチオーバーを続行します。

    Convert to Standby - これらのステップは、元のプライマリのアラート・ログにあります。残りのステップはすべて、元のスタンバイ・アラート・ログにあります。

  2. Cancel Recovery - 残りのREDOを適用し、リカバリを停止します。

  3. Convert to Primary - インスタンス(1つのインスタンス、次に他のすべてのインスタンス)の(マウント状態への) 2段階クローズ、オンラインREDOログのクリア、制御ファイルのプライマリ制御ファイルへの変換およびData Guard Brokerのブックキーピング。

  4. Open New Primary - すべてのインスタンスのパラレル・オープン。

表17-8 時間管理インタフェース・イベントが有効なステップを定義するアラート・ログ・タグ

ステップ ステージ 有効な時間管理インタフェース・イベント
Convert To Standby(primary alert log) BEGIN TMI: dbsdrv switchover to target BEGIN <DATE> <TIMESTAMP>
Convert To Standby(primary alert log) END TMI: kcv_switchover_to_target send 'switchover to primary' msg BEGIN <DATE> <TIMESTAMP>
Cancel Recovery(standby alert log) BEGIN TMI: kcv_commit_to_so_to_primary wait for MRP to die BEGIN <DATE> <TIMESTAMP>
Cancel Recovery(standby alert log) END TMI: kcv_commit_to_so_to_primary wait for MRP to die END <DATE> <TIMESTAMP>
Convert to Primary (standby alert log) BEGIN TMI: kcv_commit_to_so_to_primary BEGIN CTSO to primary <DATE> <TIMESTAMP>
Convert to Primary (standby alert log) END TMI: adbdrv BEGIN 10 <DATE> <TIMESTAMP>
Open Primary(standby alert log) BEGIN TMI: adbdrv BEGIN 10 <DATE> <TIMESTAMP>
Open Primary(standby alert log) END TMI: adbdrv END 10 <DATE> <TIMESTAMP>

主要なフェイルオーバー操作とアラート・ログ・タグ

すべてのフェイルオーバー・ステップは、フェイルオーバーが実行されたターゲット・スタンバイのアラート・ログに記載されています。

  1. Cancel Recovery - リカバリを停止し、(マウントされている)すべてのインスタンスをパラレルにクローズします。

  2. Terminal Recovery - スタンバイREDOログをアーカイブし、未適用のREDOをリカバリします。

  3. Convert to Primary - オンラインREDOログをクリアし、制御ファイルをスタンバイ制御ファイルに変換します。

  4. Open Primary - すべてのインスタンスをパラレルにオープンします。

表17-9 時間管理インタフェース・イベントが有効なステップを定義するフェイルオーバー・アラート・ログ・タグ

ステップ ステージ 有効な時間管理インタフェース・イベント
Cancel Recovery BEGIN TMI: adbdrv termRecovery BEGIN <DATE> <TIMESTAMP>
Cancel Recovery END TMI: adbdrv termRecovery END <DATE> <TIMESTAMP>
Terminal Recovery BEGIN TMI: krdsmr full BEGIN Starting media recovery <DATE> <TIMESTAMP>
Terminal Recovery END TMI: krdemr full END end media recovery <DATE> <TIMESTAMP>
Convert to Primary BEGIN TMI: kcv_commit_to_so_to_primary BEGIN CTSO to primary <DATE> <TIMESTAMP>
Convert to Primary END TMI: adbdrv BEGIN 10 <DATE> <TIMESTAMP>
Open Primary BEGIN TMI: adbdrv BEGIN 10 <DATE> <TIMESTAMP>
Open Primary END TMI: adbdrv END 10 <DATE> <TIMESTAMP>

ロール・トランジション後の検証

SHOW CONFIGURATION VERBOSEコマンドを使用して、スイッチオーバーまたはフェイルオーバーと、スタンバイの回復が成功したことを確認します。 

DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - DRSolution   
Protection Mode: MaxAvailability 
Members:   
         South_Sales  - Primary database     
         North_Sales - Physical standby database
         Fast-Start Failover: DISABLED
         Configuration Status:
          SUCCESS

スイッチオーバー操作時の問題のトラブルシューティング

Data Guardのスイッチオーバーまたはフェイルオーバー操作の失敗後に最も重要となる目標は、データベースとアプリケーションの可用性を可能なかぎり早く再開することです。

診断情報のソース

Oracle Data Guard Brokerのアクティビティに関する情報は、いくつかの形式で提供されます。

  • データベース・ステータスの情報 - SHOW DATABASE VERBOSE db_unique_nameコマンドを使用して、データベースの簡単な説明(名前、ロールなど)、データベースの状態、健全性チェックの問題に関する情報を入手できます。
    DGMGRL> SHOW DATABASE VERBOSE db_unique_name
  • Oracleアラート・ログ・ファイル - ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Oracle Data Guardをトラブルシューティングする場合は、このような情報のアラート・ログ・ファイルを確認できます。
  • Oracle Data Guard "ブローカ・ログ・ファイル" - ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作とステータス情報がブローカ・ログ・ファイルに記録されます。このファイルはOracle Data Guardの障害を診断する際に役立ちます。TraceLevel構成プロパティは、ブローカ・ログ・ファイルで報告される診断情報のレベルを指定するために使用されます。ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

初期問題の修正後のスイッチオーバーの再試行

報告された問題がすぐに修正できる場合は、スイッチオーバー操作を再試行できます。

報告された問題が修正できない場合や修正後もスイッチオーバー操作が失敗する場合は、スイッチオーバー用に別のデータベースを選択するか、構成をスイッチオーバー前の状態にリストアしてからスイッチオーバーを再試行します。または、「スイッチオーバー失敗後のロールバックによる稼働時間の最大化」を参照してください。

DGMGRL> SWITCHOVER TO database_name;

スイッチオーバー失敗後のロールバックによる稼働時間の最大化

フィジカル・スタンバイ・データベースでエラーが発生し、適切なタイミングでスイッチオーバーを続行できない場合は、新しいフィジカル・スタンバイ・データベースをプライマリ・ロールに戻して、データベースの停止時間を最小限に抑えます。

次のステップを実行します。

  1. 新しいスタンバイ・データベース(古いプライマリ)を停止し、マウントします。

  2. 新しいスタンバイ・データベースでREDO Applyを開始します。

  3. 新しいスタンバイ・データベースがいつでもプライマリ・ロールに戻せることを確認します。

    スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。値TO PRIMARYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。

  4. 次の文を発行して、新しいスタンバイ・データベースを変換してプライマリ・ロールに戻します。

     SQL> ALTER DATABASE SWITCHOVER TO target_db_name;

    ステップ4が失敗した場合は、失敗したスイッチオーバーのロールバックとやり直しを参照してください。