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

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。

以降の各項の内容は、次のとおりです。

ファスト・スタート・フェイルオーバーについて

ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動ステップを実行してフェイルオーバーを起動する必要はありません。

プライマリ・データベースに複数のスタンバイ・データベースがある場合、FastStartFailoverTargetプロパティを使用して複数のファスト・スタート・フェイルオーバー・ターゲットを指定できます。このようなターゲットはターゲット候補と呼びます。ブローカは、FaststartFailoverTargetプロパティでの指定順に基づいて、ターゲットを選択します。指定されたファスト・スタート・フェイルオーバー・ターゲットに問題が発生し、フェイルオーバーのターゲットにできない場合、ブローカはファスト・スタート・フェイルオーバー・ターゲットを別のターゲット候補のいずれかに自動的に変更します。

ファスト・スタート・フェイルオーバーはブローカ構成でのみ使用でき、DGMGRLまたはCloud Controlによってのみ構成できます。VALIDATE FAST_START FAILOVERコマンドを使用すると、ファスト・スタート・フェイルオーバー構成を検証し、ファスト・スタート・フェイルオーバーを開始できなくしている構成ミスを特定できます。

関連項目:

VALIDATE FAST_START FAILOVER

ファスト・スタート・フェイルオーバーの保護モード

ファスト・スタート・フェイルオーバーでは、最大保護、最大可用性または最大パフォーマンス保護モードを使用できます。

  • 最大保護モード

    データが消失しないことを保証する自動フェイルオーバー環境を提供します。

  • 最大可用性モード

    消失データがない(FastStartFailoverLagLimit構成プロパティがゼロに設定された場合)、またはFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)未満であることが保証される自動フェイルオーバー環境を提供します。

  • 最大パフォーマンス・モード

    消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)未満であることが保証される自動フェイルオーバー環境を提供します。

ファスト・スタート・フェイルオーバーが有効化されると、ブローカでは、構成されている消失データ量が保証される場合にのみファスト・スタート・フェイルオーバーの実行が可能となります。構成されている消失データ量を保証できない場合、プライマリ・データベースのREDO生成が停止します。最大可用性モードおよび最大パフォーマンス・モードでは、長期にわたる停止を回避するため、ファスト・スタート・フェイルオーバーを実行できないと記録された後、オブザーバまたはターゲット・スタンバイ・データベースにより、プライマリ・データベースでのREDO生成の続行が可能になる場合があります。

最大保護モードでは、プライマリ・データベースがターゲット・スタンバイとの接続を回復するまで、ブローカはプライマリ・データベースによるトランザクションのコミットを許可しないため、自動フェイルオーバーは常に使用可能です。したがって、ターゲット・スタンバイがプライマリより遅れることはありません(最大可用性モードや最大パフォーマンス・モードではその可能性があります)。

最大可用性モードでは、動作はFastStartFailoverLagLimitプロパティの値によって異なります。値がゼロの場合、自動フェイルオーバーが発生するには、プライマリによって生成されたすべてのREDOデータをスタンバイが受信している必要があります。この値がゼロでない場合、スタンバイ・データベースの適用ラグがFastStartFailoverLagLimitプロパティで指定された値以下になると、フェイルオーバーが発生する可能性があります。

最大パフォーマンス・モードでは、プライマリ・データベースのREDO生成時点とターゲット・スタンバイ・データベースのREDO適用時点の間に、FastStartFailoverLagLimitプロパティに指定された値を超過する遅れがなくなると、自動的なフェイルオーバー機能がリストアされます。

次の表に、ファスト・スタート・フェイルオーバーが有効化されている場合、どの保護モードでどのスタンバイ・タイプがサポートされているか概要を示します。また、この表では、どの保護モードで遠隔同期インスタンスを使用してターゲット・スタンバイにREDOデータを送信できるかを示しています。(スナップショット・スタンバイは、ファスト・スタート・フェイルオーバー・ターゲットとしてサポートされていないため、この表には含まれていません。)

保護モード フィジカル・スタンバイのサポート ロジカル・スタンバイのサポート 遠隔同期インスタンスのREDO送信のサポート
最大保護 はい 不要 不要
最大可用性 はい はい はい
最大パフォーマンス はい はい はい

この表に示したように、ファスト・スタート・フェイルオーバー・ターゲットが遠隔同期インスタンスからREDOデータを受け取るロジカルまたはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。これにより、距離に関係なくデータ損失がゼロになる保護が設定された構成で、ブローカの自動フェイルオーバー機能の利点を活用できます。

関連トピック

ファスト・スタート・フェイルオーバー構成内のオブザーバ

オブザーバは、プライマリ・データベースおよびスタンバイ・データベースとは異なるコンピュータ上で動作する、独立したOCIクライアント側コンポーネントであり、プライマリ・データベースの可用性を監視します。

オブザーバ・サイトにより、ファスト・スタート・フェイルオーバー環境を監視します。オブザーバの起動が完了したら、ユーザーによる操作は必要ありません。オブザーバおよび指定されたスタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティに指定された秒数を超えてプライマリ・データベースとの接続が失われた場合、オブザーバはスタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始します。また、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されている場合、FastStartFailoverThresholdの秒数よりも長い期間に及ぶ接続の消失を検出すると、プライマリ・データベースは停止します。FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、フェイルオーバーの完了後、元のプライマリ・データベースへの接続が再度確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に回復されます。

ノート:

ユーザーが構成可能なファスト・スタート・フェイルオーバー条件が検出されてファスト・スタート・フェイルオーバーが発生した場合、またはアプリケーションからDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースは必ず停止し、自動的に回復されることはありません。これは、FastStartFailoverPmyShutdownおよびFastStartFailoverAutoReinstate構成プロパティの設定には関係ありません。詳細は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

ファスト・スタート・フェイルオーバー中のプライマリ、ターゲット・スタンバイおよびオブザーバの間の関係

図6-1に、ファスト・スタート・フェイルオーバー中のプライマリ・データベース、ターゲット・スタンバイ・データベースおよびオブザーバの関係を示します。

  • ファスト・スタート・フェイルオーバー前: Oracle Data Guardは安定した状態で動作しており、プライマリ・データベースがターゲット・スタンバイ・データベースにREDOデータを転送し、オブザーバが全体の構成の状態を監視しています。

  • ファスト・スタート・フェイルオーバーの実行: プライマリ・データベースに障害が発生し、オブザーバおよびターゲット・スタンバイ・データベースへのネットワーク接続がどちらも失われます。オブザーバは、通信の切断を検出すると、ファスト・スタート・フェイルオーバーの開始前にFastStartFailoverThresholdプロパティによって定義された時間内において、プライマリ・データベースとの接続の再確立を試行します。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できず、ターゲット・スタンバイ・データベースがファスト・スタート・フェイルオーバー可能な状態である場合、ファスト・スタート・フェイルオーバーが実行されます。

  • ファスト・スタート・フェイルオーバー後: ファスト・スタート・フェイルオーバーが完了し、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールで動作しています。元のプライマリ・データベースが修復された後、オブザーバはそのデータベースとの接続を再確立し、新規スタンバイ・データベースとして回復します。新規プライマリ・データベースが新規スタンバイ・データベースへのREDOデータの転送を開始します。

図6-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係

図6-1の説明が続きます
「図6-1 プライマリ・データベースおよびスタンバイ・データベースとオブザーバの関係」の説明

関連項目:

オブザーバの構成および管理の詳細は、オブザーバの管理を参照してください

クライアント側ブローカ・ファイルの場所

クライアント側ブローカ・ファイルには、オブザーバ構成ファイル(observer.ora)、オブザーバ・ログ・ファイル、オブザーバ・ランタイム・データ・ファイル(fsfo.dat)、ファスト・スタート・フェイルオーバーのコールアウト構成ファイル、およびファスト・スタート・フェイルオーバーのコールアウト・スクリプト・ファイルがあります。

Oracle Databaseリリース21c以降では、DG_ADMIN環境変数を使用してクライアント側ブローカ・ファイルのデフォルトの場所を指定します。これらのファイルは、DG_ADMINディレクトリのサブディレクトリに格納されています。DG_ADMIN環境変数で指定されたディレクトリを作成し、必要な権限があることを確認する必要があります。

DG_ADMIN環境変数が設定されていないか、この環境変数によるディレクトリが存在しない場合、または$DG_ADMINディレクトリに必要な権限がない場合、ブローカは次の処理を行います。

  • オブザーバ・ランタイム・データ・ファイルとオブザーバ構成ファイルを現在の作業ディレクトリに保存します
  • オブザーバ・ログの表示に標準出力が使用されます

ノート:

コールアウト構成およびスクリプト・ファイルは$DG_ADMINディレクトリのサブディレクトリに格納する必要があるため、DG_ADMIN環境変数が正しく設定されていない場合、ファスト・スタート・フェイルオーバーのコールアウト機能は機能しません。

DGMGRLコマンドを実行するとき、クライアント側ブローカ・ファイルのパスとファイル名が明示的に指定されている場合は、指定された値が使用されます。ファイル名のみが指定されている場合、そのファイルはブローカの$DG_ADMIN_ディレクトリの下の適切なディレクトリに格納されます。パスのみが指定されている場合、ファイルはデフォルトのファイル名で、指定されたパスに格納されます。DG_ADMIN環境変数が設定されていない場合、ファイルは現在の作業ディレクトリに格納されます。

表6-1 クライアント側ファイルのデフォルト・ディレクトリの内容

ディレクトリ名 説明
admin

複数の構成で複数のオブザーバを管理するために、DGMGRLによって使用されるオブザーバ構成ファイルが含まれています。また、このファイルでは、ブローカ構成が宣言されており、複数の構成コマンドで使用される構成グループが定義されています。オブザーバ構成ファイルのデフォルト名はobserver.oraです。

DGMGRLを起動すると、DG_ADMIN環境変数が設定されており、指定したディレクトリに必要な権限がある場合は、$DG_ADMINディレクトリの下にadminフォルダが作成されます。

START OBSERVING、STOP OBSERVING、SET MASTEROBSERVERHOSTSなど、オブザーバ構成ファイルへのアクセスが必要なコマンドを実行したときに、ディレクトリに必要な権限がない場合はDGMGRLによってエラーがレポートされます。

config_ConfigurationSimpleName

オブザーバおよびコールアウト構成に関連するファイルが格納されています。このディレクトリには、その親ディレクトリと同じ権限があります。

1つ以上のオブザーバが登録されているブローカ構成ごとに、ConfigurationSimpleNameという名前のディレクトリが作成されます。ConfigurationSimpleNameは、ブローカ構成名の別名を表します。このディレクトリ内のサブディレクトリは、構成に関連するファイルを格納するために使用されます。

このディレクトリは、CONNECTコマンドを実行すると作成されます。START OBSERVERコマンドを実行したときに、このディレクトリに必要な権限がない場合はDGMGRLによってエラーがレポートされます。

config_ConfigurationSimpleName/log

ConfigurationSimpleNameという名前のブローカ構成の、オブザーバ・ログ・ファイルが含まれています。オブザーバ・ログ・ファイルのデフォルト名はobserver_hostname.logです。

config_ConfigurationSimpleName/dat

ConfigurationSimpleNameという名前のブローカ構成の、オブザーバ・ランタイム・データ・ファイルが含まれています。オブザーバ・ランタイム・データ・ファイルのデフォルト名はfsfo_hostname.datです。このファイルには、オブザーバに関する重要な情報が含まれています。クラッシュが発生した場合は、このファイル内のデータを使用して、オブザーバを再起動してクラッシュ発生前の状態にできます。

config_ConfigurationSimpleName/callout

ConfigurationSimpleNameという名前のブローカ構成の、コールアウト構成ファイル、コールアウト前スクリプト、コールアウト後スクリプトおよびコールアウト前成功ファイルが含まれています。コールアウト構成ファイルのデフォルト名はfsfocallout.oraです。

ノート:

データベースでOracle Databaseリリース21cより前のバージョンが使用されている場合、ConfigurationSimpleNameはデータベースのDB_UNIQUE_NAMEから導出されます。ConfigurationSimpleNameを参照してください。

DG_ADMINディレクトリに必要な権限

必要な権限がDG_ADMINディレクトリに付与されていることを確認してください。

LinuxやUnixでは、DG_ADMIN環境変数で指定されているディレクトリには、ディレクトリ所有者のみの読取り、書込みおよび実行権限が付与されている必要があります。DGMGRLによってこのディレクトリの下に作成されるサブディレクトリにも、同じ権限が付与されます。

Windowsでは、DG_ADMIN環境変数で指定されているディレクトリに排他的な権限が必要であり、このディレクトリには、DGMGRLを実行している現在のオペレーティング・システム・ユーザーのみがアクセスできます。DGMGRLによってこのディレクトリの下に作成されるサブディレクトリにも、同じ権限が付与されます。

ファスト・スタート・フェイルオーバーのコールアウト構成ファイル

コールアウト構成ファイルおよびスクリプト・ファイルを使用して、ファスト・スタート・フェイルオーバー操作の前後に実行する必要があるタスクを自動化します。

コールアウト構成ファイルの名前はfsfocallout.oraです。このファイルに別の名前は使用できません。このファイルは、$DG_ADMIN/config_ConfigurationSimpleName/calloutディレクトリに格納されます。DG_ADMIN環境変数が定義されていない場合、またはこの変数により指定されたディレクトリが存在しない場合、またはディレクトリに必要な権限がない場合、ファスト・スタート・フェイルオーバーのコールアウトは失敗します。

コールアウト構成スクリプトの名前は、fsfocallout.oraで指定します。これらのスクリプトはコールアウト構成ファイルと同じディレクトリに置く必要があります。2つのコールアウト構成スクリプト、1つのコールアウト前構成スクリプトおよび1つのコールアウト後構成スクリプトを作成できます。ファスト・スタート・フェイルオーバー操作の前に、オブザーバによって、ファスト・スタート・フェイルオーバー構成ファイルが存在するかどうかが確認されます。それが存在し、それにコールアウト前スクリプトの場所が含まれている場合は、このスクリプトが、ファスト・スタート・フェイルオーバーの開始前に実行されます。コールアウト前スクリプトでは、calloutディレクトリに.sucおよび.errファイルを作成する必要があります。.sucファイルがコンテンツに関係なく存在する場合、スクリプトが正常に実行されたことを示しています。ファスト・スタート・フェイルオーバー構成ファイル内でコールアウト後スクリプトが指定されている場合は、ファスト・スタート・フェイルオーバーの成功後に、このスクリプトが実行されます。

VALIDATE FAST_START FAILOVERコマンドは、コールアウト構成スクリプトを解析し、エラーまたは構成ミスがないか確認します。

ノート:

ファスト・スタート・フェイルオーバーの有効化(タスク7): ファスト・スタート・フェイルオーバー前後のアクションの構成(省略可能)

ファスト・スタート・フェイルオーバーを有効化するための前提条件

ブローカでファスト・スタート・フェイルオーバーを有効化するには、前提条件を満たしている必要があります。

前提条件を次に示します。

  • 保護モードを構成します。「構成に対する保護モードの設定」を参照してください。

  • ファスト・スタート・フェイルオーバー・ターゲットになる選択したスタンバイ・データベースは、プライマリ・データベースから直接REDOを受け取る必要があります。

  • ファスト・スタート・フェイルオーバーのターゲットに選択するスタンバイ・データベースのLogXptModeプロパティが、保護モードに応じて次のように設定されていることを確認します。

    • 最大保護 — SYNC

    • 最大可用性 — SYNC、FASTSYNCまたはASYNC

    • 最大パフォーマンス — ASYNC

    現在のプライマリ・データベースは、LogXptModeプロパティが適切に設定され、スタンバイREDOログが構成されている必要があります。最大可用性モードまたは最大パフォーマンス・モードのいずれかを使用している場合は、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを構成します。

  • ファスト・スタート・フェイルオーバーで遠隔同期インスタンスを使用するには、遠隔同期インスタンスの転送モードはSYNCまたはFASTSYNCに、ターゲット・スタンバイ・データベースの転送モードはASYNCに設定される必要があります。遠隔同期インスタンスは最大保護モードでは使用できません。

  • 「Oracle Data Guardのインストール」の説明に従って、オブザーバ・コンピュータにDGMGRLコマンドライン・インタフェースをインストールします。

  • オブザーバ・システムでTNSNAMES.ORAファイルを構成し、オブザーバがプライマリ・データベースおよび事前に選択されたターゲット・スタンバイ・データベースに接続できるようにします。

  • Oracle ClusterwareもOracle Restartも使用していない場合、オブザーバが回復の一部として自動的にデータベースを再起動できるように、静的サービス名を作成する必要があります。VALIDATE STATIC CONNECT IDENTIFIERコマンドを使用して、静的サービスが正しく構成されていることを確認します。詳細は、「前提条件」を参照してください。

ファスト・スタート・フェイルオーバーの有効化

ブローカ構成のデータベースに接続されている間は、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。

ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーのデータベース条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。(ファスト・スタート・フェイルオーバーの条件を満たす、アプリケーションに固有の条件が他にある場合、これらの条件のいずれかが発生した場合に即時にDBMS_DG.INITIATE_FS_FAILOVER機能をコールしてファスト・スタート・フェイルオーバーを開始するように、アプリケーションを設定できます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください)

ファスト・スタート・フェイルオーバーの有効化およびオブザーバ・プロセスの起動には、次のタスクがあります。これらのタスクでは、SYSまたはSYSDGとして接続しており、ブローカ構成でプライマリ・データベースおよびスタンバイ・データベースがすでに設定されていることを前提としています。

ファスト・スタート・フェイルオーバーの有効化(タスク1): 使用可能なスタンバイ・データベースのうち、フェイルオーバーのターゲットとして最適なデータベースの決定

フェイルオーバーのターゲットとなる使用可能なスタンバイ・データベースを決定する必要があります。

「ターゲット・スタンバイ・データベースの選択」に示したガイドラインに従います。

ファスト・スタート・フェイルオーバーの有効化(タスク2): FastStartFailoverTarget構成プロパティを使用したターゲット・スタンバイの指定

現在のプライマリ・データベースのFastStartFailoverTarget構成プロパティを使用して、1つ以上のファスト・スタート・フェイルオーバー・ターゲットを指定します。

ブローカは、このプロパティでの指定順に基づいて、ターゲット・スタンバイを選択します。

  • 構成内のスタンバイ・データベースが1つのみである場合、このステップをスキップしてタスク3に進みます。

  • 構成内に複数のスタンバイ・データベースがある場合、プライマリ・データベースでFastStartFailoverTargetプロパティを明示的に設定して、1つ以上のターゲット・スタンバイ・データベース候補を指定する必要があります。ファスト・スタート・フェイルオーバーを有効化する際、ブローカは、このプロパティが既存のスタンバイを示していることを確認します。(ターゲット・スタンバイは遠隔同期インスタンスになれないことに注意してください。ただし、ターゲットは遠隔同期インスタンスからREDOを受け取ることができます。)

    ノート:

    FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。

このプロパティの詳細は、「FastStartFailoverTarget」を参照してください。

ファスト・スタート・フェイルオーバーの有効化(タスク3): 使用する保護モードの決定

いかなるデータの消失も許容できない場合は、構成の保護モードが最大可用性または最大保護に設定されていることを確認してください。最大可用性モードでデータ損失がゼロの場合、FastStartFailoverLagLimitプロパティをゼロに設定する必要があります。

最大可用性モードでは、プライマリ・データベースとターゲット・スタンバイ・データベースの両方のLogXptModeデータベース・プロパティをSYNCまたはFASTSYNCに設定します。最大保護モードでは、LogXptModeデータベース・プロパティをSYNCに設定します(最大保護モードでは、遠隔同期インスタンスを使用してREDOをスタンバイに送信することはできません)。次に、LogXptModeプロパティを設定する例を示します。 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=SYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;

あるいは、RedoRoutesプロパティを使用して、ターゲット・スタンバイと、現在プライマリ・ロールになっているデータベースのためにREDO転送モードを設定します。その後、構成保護モードを最大可用性に設定してください。

わずかなデータの消失よりもプライマリ・データベースのパフォーマンスを重視する場合は、構成の保護モードを最大パフォーマンスに設定してファスト・スタート・フェイルオーバーを有効化することを検討してください。このモードでは、どれだけのデータ消失を許容できるかを秒単位で検討し、それに従ってFastStartFailoverLagLimit構成プロパティを設定する必要があります。このプロパティは、REDO適用に関してターゲット・スタンバイ・データベースがプライマリ・データベースから遅れることができるデータ量を秒単位で指定します。スタンバイ・データベースでREDOが適用された時点がプライマリ・データベースのREDO生成時点からその秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。FastStartFailoverLagLimit構成プロパティは、最大パフォーマンス・モードで動作している構成のファスト・スタート・フェイルオーバーが有効化されている場合にのみブローカによって使用されます。デフォルト値は30秒で、設定できる最小値は5秒です。

構成の保護モードを最大パフォーマンスに設定することに加えて、プライマリ・データベースとターゲットスタンバイ・データベースの両方でデータベース・プロパティLogXptModeがASYNCに設定されていることを確認する必要もあります。たとえば: 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode=ASYNC;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxPerformance;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=45;

ファスト・スタート・フェイルオーバーの有効化(タスク4): FastStartFailoverThreshold構成プロパティの設定

オブザーバおよびターゲット・スタンバイ・データベースの両方で、FastStartFailoverThreshold構成プロパティで指定された時間中にプライマリ・データベースへの接続が失われた場合、ファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverThresholdプロパティを設定し、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。たとえば: 

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

FastStartFailoverThresholdプロパティのデフォルト値は30秒で、設定できる最小値は6秒です。Oracle RACプライマリ・データベースが存在する場合、インスタンス障害が発生したときに誤ってフェイルオーバーが実行される可能性を最小限にするには、これより大きい値を指定することを考慮します。

この時間間隔は、オブザーバでプライマリ・データベースへの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、スタンバイ・データベースがフェイルオーバー可能な状態であれば、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。デフォルト値の30秒は、通常はほとんどの構成で停止および障害を検出できる値ですが、このプロパティでフェイルオーバーの感度を調整することで、一時的に不安定になった環境でフェイルオーバーが誤って実行される可能性を低くすることができます。

REDOの生成が停止し、プライマリ・データベースがオブザーバまたはターゲット・スタンバイ・データベースとの接続を再確立できない場合、FastStartFailoverPmyShutdown構成プロパティがTRUEに設定されていると、FastStartFailoverThresholdの秒数が経過した後にプライマリ・データベースが停止します。

レイテンシが非常に低いネットワーク環境では、ObserverPingIntervalおよびObserverPingRetryプロパティの組合せを使用して、プライマリの障害を検出するためにさらに低い値を構成できます。ObserverPingIntervalプロパティは、オブザーバがプライマリ・データベースにpingを実行する頻度をミリ秒単位で指定します。ObserverPingRetryプロパティでは、ターゲット・スタンバイ・データベースへのフェイルオーバーを試行する前に、オブザーバが失敗したpingを再試行する回数を指定します。これらのプロパティの両方が0以外の値に設定されている場合、プライマリ障害検出時間はFastStartFailoverThresholdプロパティによって提供される最小の制限よりも低く構成できます。

ファスト・スタート・フェイルオーバーが有効化されている場合でもFastStartFailoverThresholdプロパティを変更できることに注意してください。

関連項目:

FastStartFailoverThresholdプロパティの詳細は、「FastStartFailoverThreshold」を参照してください

ファスト・スタート・フェイルオーバーの有効化(タスク5): ファスト・スタート・フェイルオーバー関連の他のプロパティの設定(省略可能)

この表は、設定できるオプションのデータベース・プロパティを示します。

プロパティ名 説明 デフォルト値

FastStartFailoverPmyShutdown

この構成プロパティにより、ファスト・スタート・フェイルオーバーが有効で、プライマリがFastStartFailoverThresholdの秒数よりも長くSTALLEDになったことをV$FAST_START_FAILOVER_CONFIG.STATUSが示すと、プライマリ・データベースが停止します。TRUEの値は、分離されたプライマリ・データベースがユーザーの問合せに対応できないことを確認するのに役立ちます。

ユーザーの構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合、このプロパティを使用してプライマリ・データベースの停止を防止することはできません。

TRUE

FastStartFailoverLagLimit

構成プロパティは、REDOの適用に関して、プライマリよりスタンバイが遅れることができる許容範囲を秒単位で確立します。この値を超えて遅れる場合は、ファスト・スタート・フェイルオーバーが実行されません。設定可能な最小値は5秒です。

30秒

FastStartFailoverAutoReinstate

この構成プロパティを使用すると、プライマリ・データベースが分離またはクラッシュしたためにファスト・スタート・フェイルオーバーが開始した場合に、元のプライマリ・データベースが自動的に回復されます。この場合に元のプライマリ・データベースを自動的に回復しないようにするには、この構成プロパティをFALSEに設定します。ユーザー構成条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを要求した場合は、ブローカは元のプライマリ・データベースを自動的に回復しません。

TRUE

ObserverConnectIdentifier

このデータベース・プロパティは、オブザーバがプライマリおよびスタンバイ・データベースに接続して監視する方法を指定するために使用されます。REDOデータの転送に使用される接続識別子とは異なる識別子(DGConnectIdentifierプロパティで指定される接続識別子)をオブザーバが使用する場合は、プライマリ・データベースとターゲット・スタンバイ・データベースにこのプロパティを設定してください。

オブザーバは、DGConnectIdentifierプロパティの値を使用してプライマリおよびターゲット・スタンバイ・データベースに接続し、監視します。

ObserverOverride

ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。

FALSE
ObserverPingInterval

ObserverPingInterval構成プロパティは、オブザーバがプライマリ・データベースにpingする頻度を指定します。このプロパティは、ミリ秒単位で測定されます。最小値は100ミリ秒です。プライマリ・データベース障害の検出時間を短縮するには、ファスト・スタート・フェイルオーバーを有効にする前にObserverPingIntervalおよびObserverPingRetryプロパティを設定する必要があります。

有効な値は100以上です。デフォルト値は100ミリ秒です。
ObserverPingRetry OberverPingRetryプロパティは、ターゲット・スタンバイ・データベースへのフェイルオーバーを開始するまでに、オブザーバが失敗したpingを再試行する回数を指定します。失敗したpingとは、プライマリ・データベースへのpingが失敗したか、ObserverPingIntervalプロパティで指定された時間より長い時間がかかったケースを指します。プライマリ・データベース障害の検出時間を短縮するには、ObserverPingRetryプロパティとObserverPingIntervalプロパティの両方を設定する必要があります。最小値は10 したがって、検出時間を約1秒に短縮できます。 有効な値は10以上です。デフォルト値は10ミリ秒です。

ObserverReconnect

ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの新しい接続を定期的に確立しません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。

0 (ゼロ)

ファスト・スタート・フェイルオーバーの有効化(タスク6): 追加のファスト・スタート・フェイルオーバー条件の有効化(省略可能)

デフォルトでは、構成された時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。

必要に応じて、ファスト・スタート・フェイルオーバーを発生させるデータベース健全性条件を指定することができます。次の表に、これらの条件を示します。

健全性条件 説明 デフォルトで有効化
データファイル書込みエラー ファスト・スタート・フェイルオーバーが有効化され、データファイル書込みエラー条件が指定されている場合、任意のデータ・ファイル(一時ファイル、システム・データ・ファイル、UNDOファイルなど)で書込みエラーが発生すると、ファスト・スタート・フェイルオーバーが開始されます。 はい

破損したディクショナリ

重要なデータベースのディクショナリが破損しました。現時点では、この状態は、データベースがオープンされている場合にのみ検出されます。

はい

破損した制御ファイル

ディスク障害のために制御ファイルが永続的に破損しました。

はい

アクセス不可能なログ・ファイル

I/OエラーのためにLGWRがログ・グループのどのメンバーにも書き込むことができません。

不要

スタック・アーカイバ

デバイスに空き容量がないかデバイスを使用できないためにアーカイバがREDOログをアーカイブできません。

不要

Oracle RAC構成では、アクセス不可能なログ・ファイルおよびスタック・アーカイバの健全性条件は、単一インスタンスにのみ適用できます。これらの条件によるファスト・スタート・フェイルオーバーは、Oracle Clusterwareによって提供される可用性オプションに優先して実行されるので、有効化する前によく検討してください。

Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される特定の条件を指定できます。

ファスト・スタート・フェイルオーバーの有効化(タスク7): ファスト・スタート・フェイルオーバー前後のアクションの構成(省略可能)

ファスト・スタート・フェイルオーバー操作の前後に実行する必要があるタスクは、コールアウト・スクリプトを使用して自動化できます。

ファスト・スタート・フェイルオーバー操作の前または後に、指定したアクションを実行するには、次のようにします。

  1. コールアウト前スクリプトまたはコールアウト後スクリプト、あるいはその両方を作成します。
    コールアウト・スクリプトの格納に使用されるディレクトリおよび必要な権限の詳細は、ファスト・スタート・フェイルオーバーのコールアウト構成ファイルを参照してください。
  2. ファスト・スタート・フェイルオーバーのコールアウト構成ファイルを作成または更新し、前のステップで作成したスクリプトの名前を含めます。

例6-1 ファスト・スタート・フェイルオーバー構成ファイル

次の例では、ファスト・スタート・フェイルオーバー構成ファイル/home1/dataguard/config_NorthSales/callout/fsfocallout.oraの内容を示します。コールアウト構成スクリプトfsfo_precalloutおよびfsfo_postcalloutは、fsfocallout.oraと同じ場所に格納され、必要な権限を持っています。 

# This is a fast-start failover configuration file.

# The pre-callout script that is run before fast-start failover is enabled.
FastStartFailoverPreCallout=fsfo_precallout

# The timeout value (in seconds) for pre-callout script
FastStartFailoverPreCalloutTimeout=1200

# The name of the suc file created by the pre-callout script.
FastStartFailoverPreCalloutSucFileName=fsfo_precallout.suc

# The name of the error file that the pre-callout script creates 
FastStartFailoverPreCalloutErrorFileName=precallout.err

# Action taken by observer if the suc file does not exist after FastStartFailoverPreCalloutTimeout seconds
# or if an error file is detected before FastStartFailoverPreCalloutTimeout seconds passed
FastStartFailoverActionOnPreCalloutFailure=STOP

# The post-callout script that is run after fast-start failover succeeds
FastStartFailoverPostCallout=fsfo_postcallout

ファスト・スタート・フェイルオーバーの有効化(タスク8): DGMGRLまたはCloud Controlの使用

Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのENABLE FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーを有効化します。

ファスト・スタート・フェイルオーバーを有効化するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方が動作しており、接続され、さらに「ファスト・スタート・フェイルオーバーを有効化するための前提条件」にリストされた前提条件をすべて満たしている必要があります。

ノート:

Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードでは、複数のターゲットの指定は現在サポートされていません。複数のターゲットを指定する場合は、DGMGRLユーティリティを使用する必要があります。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの有効化

Cloud Controlでファスト・スタート・フェイルオーバーを有効にするには、ファスト・スタート・フェイルオーバー・ウィザードを使用します。Oracle Data Guardの「概要」ページで、「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にある「無効」をクリックして、「ファスト・スタート・フェイルオーバー」ページを開きます。次に、「ファスト・スタート・フェイルオーバー: モードを変更」ページで、「有効」をクリックします。Cloud Controlによってオブザーバが起動されます。次に、「ファスト・スタート・フェイルオーバー: 構成」ページで、フェイルオーバーのターゲットとするスタンバイ・データベースを選択します。役立つアドバイスについては、「ターゲット・スタンバイ・データベースの選択」を参照してください。このページでは、保護モードを変更できません。ファスト・スタート・フェイルオーバーは、現在の保護モードに従って有効化されます。現在構成されているモードが最大保護の場合、Cloud Controlは、モードを最大可用性にダウングレードします。

DGMGRLを使用したファスト・スタート・フェイルオーバーの有効化

DGMGRLを使用してファスト・スタート・フェイルオーバーを有効化するには、オブザーバ・コンピュータ上のデータベースを含むブローカ構成内のいずれかのデータベースに接続している間に、ENABLE FAST_START FAILOVERコマンドを発行します。たとえば: 

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

関連項目:

ノート:

スタンバイ・データベースが事前の予告なしにプライマリ・ロールを引き継ぐ場合があるため、ターゲット・スタンバイ・サイトでの管理はプライマリ・サイトでの管理と同じくらい包括的である必要があります。スタッフ・サポート、ハードウェアとソフトウェア、セキュリティ(ソフトウェアとサイトの両方)、ネットワーク接続および帯域幅が両方のサイトで同等である必要があります。

ファスト・スタート・フェイルオーバーの有効化(タスク9): オブザーバの起動

オブザーバを起動するには、プライマリ・データベースが実行されている必要があります。

ファスト・スタート・フェイルオーバーを有効化する前または後にオブザーバを起動できます。ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバは、プライマリ・データベースおよびターゲット・スタンバイ・データベースのステータスおよび接続の監視をただちに開始します。ファスト・スタート・フェイルオーバーが有効化されていない場合、オブザーバは、ファスト・スタート・フェイルオーバーが有効化されるまで待機してから監視を開始します。

Cloud Controlを使用したオブザーバの起動

Cloud Controlエージェントがオブザーバ・コンピュータにインストールされている場合、Cloud Controlを介してファスト・スタート・フェイルオーバーを有効にすると、オブザーバが自動的に起動されます。エージェントが存在しない場合、DGMGRLコマンドライン・インタフェースに関する次の手順を実行して、オブザーバを手動で起動する必要があります。

DGMGRLを使用したオブザーバの起動

DGMGRLを使用してオブザーバを起動するには、オブザーバ・コンピュータで次のコマンドを発行します。

DGMGRL> START OBSERVER;

オブザーバはSTART OBSERVERコマンドを発行したときに作成され、継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

1つのData Guard構成に対して最大4つのオブザーバを設定できます。1つはマスター・オブザーバ、その他はバックアップ・オブザーバです。

DGMGRLを使用したバックグラウンド・プロセスとしてのオブザーバの起動

オブザーバをバックグラウンド・プロセスとして起動するには、DGMGRLコマンドSTART OBSERVER IN BACKGROUNDを使用します。このコマンドが正常に発行されると、オブザーバ・コンピュータ上のコマンドライン・プロンプトがユーザーに戻り、ユーザーは引き続きコマンドを発行してブローカ構成と対話できます。オブザーバの起動には、この方法を使用することをお薦めします。

現在のプライマリに基づいた優先オブザーバの指定

データベースがプライマリ・ロールの場合にマスター・オブザーバにできるオブザーバを指定するには、PreferredObserverHostsプロパティを使用します。このプロパティを使用すると、データベースがプライマリ・ロールの場合にマスター・オブザーバになることができるオブザーバの優先順位付きリストを指定できます。

たとえば: 

EDIT DATABASE North_Sales SET PROPERTY PreferredObserverHosts="'ob1-host:1, ob2-host:2'; 
EDIT DATABASE South_Sales SET PROPERTY PreferredObserverHosts="'ob3-host:1, ob4-host:2';

この場合、North_Salesがプライマリ・ロールの場合、ob1-hostおよびob2-hostのオブザーバのみがマスター・オブザーバになることができます。オブザーバon ob1-hostは、ob2-host上のオブザーバより優先され、マスター・オブザーバになります。これらのオブザーバの両方が使用できない場合、ob3-hostおよびob4-host上のオブザーバはマスター・オブザーバになりません。

ファスト・スタート・フェイルオーバーの有効化(タスク10): ファスト・スタート・フェイルオーバー環境の検証

ファスト・スタート・フェイルオーバー構成の準備が整っているかどうかを検証するには、プライマリ・データベースでDGMGRLのSHOW CONFIGURATION VERBOSEコマンドまたはSHOW FAST_START FAILOVERコマンドを発行します。

たとえば:

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: Enabled in Zero Data Loss Mode

  Protection Mode:    MaxAvailability
  Lag Limit:          0 seconds

  Threshold:          30 seconds
  Ping Interval:      3000 milliseconds
  Ping Retry:         0 
  Active Target:      South_Sales
  Potential Targets:  "South_Sales"
    South_Sales valid
  Observer:           observer1
  Shutdown Primary:   TRUE
  Auto-reinstate:     TRUE
  Observer Reconnect: (none)
  Observer Override:  FALSE

Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile            NO
    Stuck Archiver                  NO
    Datafile Write Errors          YES

  Oracle Error Conditions:
    (none)

次の各項では、ファスト・スタート・フェイルオーバー環境の詳細を説明しています。

ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

ファスト・スタート・フェイルオーバーが有効化され、最大4つのオブザーバが起動された後、1つのオブザーバがマスター・オブザーバとして指定され、継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。

この項では、マスター・オブザーバがファスト・スタート・フェイルオーバーの必要性を判別し、必要に応じてフェイルオーバーを実行するためのステップをリストしています。

  1. 環境を監視し、プライマリ・データベースが使用可能であることを確認します。

    次の状況のように、プライマリ・データベースがクラッシュした場合、またはオブザーバとの接続が失われた場合、マスター・オブザーバはFastStartFailoverThreshold構成プロパティで指定されている秒数を待機してから、ファスト・スタート・フェイルオーバーを試行します。

    • プライマリ・データベースと、オブザーバおよびターゲット・スタンバイ・データベースの両方との接続が失われた場合

    • インスタンス障害

      単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスに障害が発生した場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。

    • 強制終了

      単一インスタンスのプライマリ・データベース(Oracle RACまたは非Oracle RAC)、またはOracle RACプライマリ・データベースのすべてのインスタンスがABORTオプションにより停止された場合、オブザーバがファスト・スタート・フェイルオーバーを試行します。他のタイプのデータベース停止(NORMAL、IMMEDIATE、TRANSACTIONAL)では、ファスト・スタート・フェイルオーバーは試行されません。

    次の状況では、マスター・オブザーバはしきい値を超えるまで待機せずに、ファスト・スタート・フェイルオーバーを実行します。

    • ユーザーが構成可能な条件

      マスター・オブザーバは、ユーザーが構成可能な条件が検出されたと判断すると、ファスト・スタート・フェイルオーバーを試行します。

    • DBMS_DG.INITIATE_FS_FAILOVERのアプリケーション・コール

      アプリケーションがこの機能をコールし、SUCCESSステータスを受け取ると、マスター・オブザーバがファスト・スタート・フェイルオーバーを試行します。

  2. FastStartFailoverThresholdプロパティにより指定された時間内に再接続します。

    プライマリ・データベースに可用性の問題があることをマスター・オブザーバが検出した場合、マスター・オブザーバは通常、FastStartFailoverThreshold構成プロパティに指定された時間内にプライマリ・データベースに再接続しようとします。FastStartFailoverThresholdの時間間隔は、オブザーバがプライマリ・データベースに障害があることを最初に検出したときに開始されます。

    ユーザーが構成可能な条件が発生したことをマスター・オブザーバが検出した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数でファスト・スタート・フェイルオーバーを要求した場合、FastStartFailoverThresholdプロパティに指定された時間間隔は無視されます。

    プライマリ・データベースがOracle Real Application Clusters (Oracle RAC)データベースである場合、マスター・オブザーバは残りのプライマリ・インスタンスのいずれかに接続しようとします。Oracle RACプライマリ・データベースを構成するすべてのインスタンスに障害が発生したことが検出されていないかぎり、ファスト・スタート・フェイルオーバーは実行されません。マスター・オブザーバは、データベース・プロパティDGConnectIdentifierまたはObserverConnectIdentifierに指定された値を使用して、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースに接続します。マスター・オブザーバは、これらのプロパティに指定された値を使用して、Oracle RACデータベースの任意のインスタンスに接続できる必要があります。

  3. ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態であることを確認します。

    ファスト・スタート・フェイルオーバーが開始されると、マスター・オブザーバはターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーする準備ができているかどうかを確認します。

    次の場合、ファスト・スタート・フェイルオーバーは実行できません。

    • ファスト・スタート・フェイルオーバーが有効でない場合

    • マスター・オブザーバがターゲット・スタンバイ・データベースに接続できない場合

      関連項目:

      オブザーバが動作していない場合は、「オブザーバに障害が発生した場合の動作」を参照

    • ブローカ構成の現在の状態に関して、マスター・オブザーバおよびターゲット・スタンバイ・データベースに一貫性がない場合

    • マスター・オブザーバが動作していない場合

    • 保護モードが最大可用性または最大保護で、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていない場合

    • 保護モードが最大パフォーマンスで、プライマリ・データベースに障害が発生したときにターゲット・スタンバイ・データベースのREDO適用時点がプライマリ・データベースのREDO生成時点からFastStartFailoverLagLimit構成プロパティで指定された時間を超えて遅れる場合

    • ターゲット・スタンバイ・データベースがプライマリ・データベースと通信している場合。ただし、ObserverOverride構成プロパティがTRUEに設定されている場合は、フェイルオーバーが試みられます。

    • ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列に、ファスト・スタート・フェイルオーバーを実行できない理由が表示された場合

    • 手動フェイルオーバーがすでに進行中です。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

    • ABORTオプションを使用せずにプライマリ・データベースを停止した場合

  4. ファスト・スタート・フェイルオーバーを開始します。

    ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、マスター・オブザーバの指示により、ただちにターゲット・スタンバイ・データベースがプライマリ・データベース・ロールにフェイルオーバーします。他のなんらかの理由でフェイルオーバーを実行できない場合、マスター・オブザーバはスタンバイ・データベースでフェイルオーバーの準備ができたかどうかをチェックし続けます。ただし、オブザーバはプライマリ・データベースへの再接続も無期限に試行し続けます。スタンバイがフェイルオーバーに同意する前にプライマリ・データベースに再接続すると、マスター・オブザーバはファスト・スタート・フェイルオーバーの開始の試行を中止します。

  5. 元のプライマリ・データベースを新規スタンバイ・データベースとして回復します。

    ファスト・スタート・フェイルオーバーが正常に完了した後、元のプライマリ・データベースへの接続が再確立され、FastStartFailoverAutoReinstate構成プロパティがTRUEに設定されている場合、マスター・オブザーバは元のプライマリ・データベースの新規スタンバイ・データベースとしての回復を試行します。FastStartFailoverPmyShutdown構成プロパティをTRUEに設定した場合、元のプライマリ・データベースは自動的に停止しているため、マスター・オブザーバが回復を試行する前に、手動で再起動する必要があります。

    プライマリがクラッシュしたか、オブザーバおよびターゲット・スタンバイ・データベースから分離したためにファスト・スタート・フェイルオーバーが発生した場合にのみ、これらのプロパティがプライマリの停止および自動回復の実行を左右する点に注意してください。

    関連項目:

    回復の詳細は、「ブローカ構成に含まれる元のプライマリ・データベースの回復」を参照

ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項

このリストは、ファスト・スタート・フェイルオーバーが有効になっている場合の制限について説明します。

  • 変更:

    • 構成保護モード

    • REDOをターゲット・スタンバイ・データベースまたは現在プライマリ・ロールになっているデータベースに送信するために使用されるREDO転送モード

    • 新しいプロパティ値に現在のファスト・スタート・フェイルオーバー・ターゲットが含まれていない場合は、プライマリ・データベースのFastStartFailoverTarget構成プロパティ。

    • 新しい値ではプライマリ・データベースがファスト・スタート・フェイルオーバーの現在のターゲット・スタンバイにREDOを送信できなくなる場合は、プライマリ・データベースのRedoRoutesプロパティ。(ターゲット・スタンバイ・データベースを含むすべてのスタンバイ・データベースのRedoRoutesプロパティは変更可能です。)

    • 遠隔同期インスタンスがプライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合、そのRedoRoutesプロパティ

  • 無効化または削除:

    • ブローカ構成

    • ファスト・スタート・フェイルオーバーのターゲットであるスタンバイ・データベース

    • プライマリ・データベースからREDOを受け取ってターゲット・スタンバイ・データベースにREDOを送信する場合の遠隔同期インスタンス

  • 手動フェイルオーバーの実行:

    • 「ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行」にリストされた条件を満たしていない場合

    • ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースに対する実行

      構成がファスト・スタート・フェイルオーバーを実行可能な状態かどうかを判断するには、DGMGRLのSHOW DATABASE <target-standby-database>コマンドを発行するか、プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかでV$DATABASEビューを問い合せます。ファスト・スタート・フェイルオーバーを実行できる状態である場合、V$DATABASE.FS_FAILOVER_STATUSの列値は、最大可用性モードではSYNCHRONIZED、最大パフォーマンス・モードではTARGET UNDER LAG LIMITです。ターゲット・スタンバイ・データベースについては、FS_FAILOVER_OBSERVER_PRESENT列にはYESと表示されます。

  • ファスト・スタート・フェイルオーバーのターゲットとして構成されていないスタンバイ・データベースへのスイッチオーバーの実行

  • スタンバイ・データベースがプライマリ・データベースと同期化されている場合を除く、最大可用性モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

  • スタンバイ・データベースがプライマリ・データベースのラグ制限内にある場合を除く、最大パフォーマンス・モードで動作している構成のターゲット・スタンバイ・データベースへのスイッチオーバーの実行

  • プライマリ・データベースのオープンの試行。オープンを試行すると、次のエラーが戻される場合あります。

    ORA-16649: possible failover to another database prevents this database from being opened

    ファスト・スタート・フェイルオーバーの妥当性チェックが失敗するか、2分未満で完了しないと、このエラーが戻されることがあります。

  • スタンバイがマウントされているが、オープンされていない場合、SQL ALTER DATABASE MOVE DATAFILEコマンドを使用して、ファスト・スタート・フェイルオーバーのターゲットとなっているフィジカル・スタンバイ上のオンライン・データ・ファイルを名称変更するか、再配置します。

ノート:

プライマリおよび最初のファスト・スタート・フェイルオーバー・ターゲットの両方が停止している場合、Data Guard Brokerは2番目のファスト・スタート・フェイルオーバー・ターゲットにフェイルオーバーできません。

監視専用モードでのファスト・スタート・フェイルオーバーの構成

ファスト・スタート・フェイルオーバーの監視専用モードでは、使用している環境でファスト・スタート・フェイルオーバーの動作をテストできます。現在の構成またはアプリケーションに影響はありません。

このモードでは、ブローカ構成に対して実際に変更は行われません。ファスト・スタート・フェイルオーバーの条件が満たされると、ブローカはファスト・スタート・フェイルオーバーが開始された可能性があることを示すメッセージをオブザーバ・ログおよびブローカ・ログに追加します。ログには、フェイルオーバーの場合に実行されるアクションに関するその他の詳細も含まれています。

監視専用モードに関する次の点に注意してください。

  • プライマリ・データベースは、オブザーバまたはターゲット・スタンバイから応答がなくても、UNSYNCまたはLAGGING状態になることがあります。

  • オブザーバまたはターゲット・スタンバイから応答がない場合でも、プライマリ・データベースをオープンできます。

  • ファスト・スタート・フェイルオーバーのターゲットへの手動フェイルオーバーは、オブザーバから応答を受信することなく実行できます。

  • 事前条件チェックが満たされていない場合でも、手動フェイルオーバーを実行できます。これには、ブローカ構成がUNSYNCまたはLAGGING状態にあるか、監視されていない状態であるか、フェイルオーバー・ターゲットが無効であるか、回復が進行中であるか、マスター・オブザーバの切替えが進行中である場合が含まれます。

  • 他のデータベースにスイッチオーバーまたは手動フェイルオーバーできます。

監視専用モードでファスト・スタート・フェイルオーバーを構成するには、次のようにします。

DGMGRL> ENABLE FAST_START FAILOVER OBSERVE ONLY;

ファスト・スタート・フェイルオーバーが有効化されている場合のプライマリ・データベースの停止

プライマリ・データベースまたはスタンバイ・データベースが通常の方法で停止された場合、ファスト・スタート・フェイルオーバーは起動されません。

通常の停止では、SHUTDOWN NORMAL、SHUTDOWN IMMEDIATEまたはSHUTDOWN TRANSACTIONALを使用します。通常の停止では、プライマリ・データベースおよびスタンバイ・データベースが再度接続され通信状態になるまで、ファスト・スタート・フェイルオーバーを実行できません。

ファスト・スタート・フェイルオーバーが有効化されている場合の手動によるロール変更の実行

ファスト・スタート・フェイルオーバーが有効化されている場合でも、特定の条件を満たしているかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。

条件は次のとおりです。

  • ロール変更の対象が、プライマリ・データベース上のFastStartFailoverTargetデータベース・プロパティで指定されたスタンバイ・データベースと同一であること。

  • ターゲット・スタンバイ・データベースがプライマリ・データベースと同期化されていること(最大可用性モードまたは最大保護モードで動作している構成の場合)またはターゲット・スタンバイ・データベースがラグ制限内にあること(最大パフォーマンス・モードで動作している構成の場合)。

  • 手動フェイルオーバーの場合、オブザーバが起動しており、ターゲット・スタンバイ・データベースと通信していること。手動フェイルオーバーを実行する前に、プライマリ・データベースが停止されていることを確認する必要があります。

ノート:

必要な場合は、FORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化できます。「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

関連項目:

スイッチオーバーおよび手動フェイルオーバーの詳細は、それぞれ「スイッチオーバー」および「手動フェイルオーバー」を参照してください

アプリケーションによるファスト・スタート・フェイルオーバーの指示

DBMS_DG PL/SQLパッケージを使用して、特定のアプリケーションのファスト・スタート・フェイルオーバー設定をカスタマイズできます。

アプリケーションに独自に認識される重大な条件が検出されたとき、アプリケーションはDBMS_DG.INITIATE_FS_FAILOVER機能をコールして、即時ファスト・スタート・フェイルオーバーを開始できます。この機能は、接続から構成内のプライマリ・データベースまたはいずれかのスタンバイ・データベースにコールできます。プロシージャがコールされたデータベースは、オブザーバにそれを通知します。フェイルオーバー・ターゲット・データベースがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)、オブザーバによりただちにファスト・スタート・フェイルオーバーが開始されます。オブザーバによってファスト・スタート・フェイルオーバーが開始されると、プライマリ・データベースは自動的に停止します。オブザーバは元のプライマリ・データベースの回復を試行しません。

構成がフェイルオーバー不能の場合、DBMS_DG.INITIATE_FS_FAILOVER機能は、ORAエラー番号(例外ではなく)を返して、ファスト・スタート・フェイルオーバーを実行できないことをコール元に通知します。

ノート:

可能であればオブザーバがフェイルオーバーを開始するため、アプリケーションでDBMS_DG.INITIATE_FS_FAILOVER機能をコールする際には注意が必要です。

関連項目:

DBMS_DGパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な場合、DGMGRL SHOW FAST_START FAILOVER、SHOW CONFIGURATION VERBOSEまたはSHOW OBSERVERコマンドを発行できます。

または、ターゲット・スタンバイ・データベースでV$FAST_START_FAILOVER_CONFIGビューを問い合せることもできます。

V$FS_FAILOVER_STATSビューを問い合せて、システムで発生しているファスト・スタート・フェイルオーバーに関する統計を表示することもできます。

次に、DGMGRL SHOWコマンドを使用してファスト・スタート・フェイルオーバー情報を表示する例を示します。次のビューについても説明します。

例1: SHOW FAST_START FAILOVER

DGMGRLのSHOW FAST-START FAILOVERコマンドは、すべてのファスト・スタート・フェイルオーバー関連情報を表示します。たとえば: 

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: Enabled in Zero Data Loss Mode

  Protection Mode:    MaxAvailability
  Lag Limit:          0 seconds

  Threshold:          30 seconds
  Ping Interval:      3000 milliseconds
  Ping Retry:         0 
  Active Target:      South_Sales
  Potential Targets:  "South_Sales"
    South_Sales valid
  Observer:           observer1
  Shutdown Primary:   TRUE
  Auto-reinstate:     TRUE
  Observer Reconnect: (none)
  Observer Override:  FALSE

Configurable Failover Conditions
  Health Conditions:
    Corrupted Controlfile          YES
    Corrupted Dictionary           YES
    Inaccessible Logfile            NO
    Stuck Archiver                  NO
    Datafile Write Errors          YES

  Oracle Error Conditions:
    (none)

例2: SHOW CONFIGURATION VERBOSE

次の例は、DRSolution構成のファスト・スタート・フェイルオーバー情報を示しています。

DGMGRL> SHOW CONFIGURATION VERBOSE

Configuration - config

  Protection Mode: MaxAvailability
  Members:
  North_Sales - Primary database
    South_Sales - (*) Physical standby database 

  (*) Fast-Start Failover target

  Properties:
    BystandersFollowRoleChange      = 'ALL'
    CommunicationTimeout            = '180'
    ConfigurationSimpleName         = 'config'
    ConfigurationWideServiceName    = 'North_Sa_CFG'
    DrainTimeout                    = '0'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverLagLimit       = '0'
    FastStartFailoverPmyShutdown    = 'TRUE'
    FastStartFailoverThreshold      = '30'
    ObserverOverride                = 'FALSE'
    ObserverPingInterval            = '0'
    ObserverPingRetry               = '0'
    ObserverReconnect               = '0'
    OperationTimeout                = '30'
    PrimaryLostWriteAction          = 'CONTINUE'
    TraceLevel                      = 'USER'

Fast-Start Failover: Enabled in Zero Data Loss Mode
  Lag Limit:          0 seconds
  Threshold:          30 seconds
  Ping Interval:      3000 milliseconds
  Ping Retry:         0 
  Active Target:      South_Sales
  Potential Targets:  "South_Sales"
    South_Sales valid
  Observer:           observer1
  Shutdown Primary:   TRUE
  Auto-reinstate:     TRUE
  Observer Reconnect: (none)
  Observer Override:  FALSE

Configuration Status:
SUCCESS

例3: SHOW OBSERVER

次のSHOW OBSERVERコマンドは、DRSolutionブローカ構成内の複数のオブザーバに関する情報を表示します。 

DGMGRL> SHOW OBSERVER

Configuration - config

  Fast-Start Failover:     ENABLED

  Primary:            North_Sales
  Active Target:      South_Sales

Observer "observer1" - Master

  Host Name:                    observer1
  Last Ping to Primary:         0 seconds ago
  Last Ping to Target:          2 seconds ago
  Log File:                     /sales/observer_observer1.log
  State File:                   /sales/fsfo.dat

Observer "observer2" - Backup

  Host Name:                    observer2
  Last Ping to Primary:         1 second ago
  Last Ping to Target:          1 second ago
  Log File:                     /sales/observer_observer2.log
  State File:                   /sales/fsfo.dat

V$FAST_START_FAILOVER_CONFIGビュー

V$FAST_START_FAILOVER_CONFIGビューを問い合せて、オブザーバが起動しており、構成がファスト・スタート・フェイルオーバー可能な状態かどうかを確認できます。

V$FAST_START_FAILOVER_CONFIGビューを問い合せる場合、次の列に特に注意してください。

  • 表6-2に示す値が含まれる可能性のあるFAILOVER列。FAILOVER列の値がDISABLEDの場合、ファスト・スタート・フェイルオーバーに関連する残りの列に対して返される値(V$DATABASE.FS_FAILOVER_*)は無関係になります。

  • オブサーバーが実行され、データベースをアクティブにpingしているかどうかを示すOBSERVER_PRESENT列。

表6-2 V$FAST_START_FAILOVER_CONFIGビューのSTATUS列

列値 説明 ファスト・スタート・フェイルオーバー ...

BYSTANDER

ファスト・スタート・フェイルオーバーは有効化されていますが、このスタンバイ・データベースはファスト・スタート・フェイルオーバーのターゲットではありません。このデータベースはファスト・スタート・フェイルオーバーのステータス情報を提供できません。

有効

DISABLED

ファスト・スタート・フェイルオーバーは無効化されています。

不可

LOADING DICTIONARY

プライマリ・データベースのデータ・ディクショナリのコピーをロードし終えていないロジカル・スタンバイ・データベースにのみ表示されます。

不可

PRIMARY UNOBSERVED

ターゲット・スタンバイ・データベースが、プライマリ・データベースとSYNCHRONIZEDされているかプライマリ・データベースのTARGET UNDER LAG LIMITにあり、オブザーバに接続されているとき、プライマリ・データベースがオブザーバに接続されていない場合、ターゲット・スタンバイ・データベースにのみ表示されます。

不可

REINSTATE FAILED

障害が発生したプライマリ・データベースの新規スタンバイ・データベースとしての回復に失敗しました。ブローカのdrc*ログ・ファイルの詳細は、「診断情報のソース」を参照してください。

完了済

REINSTATE REQUIRED

障害が発生したプライマリ・データベースは、新規プライマリに対する新規スタンバイ・データベースとして回復する必要があります。オブザーバにより回復プロセスが自動的に開始されます。REINSTATE REQUIREDは、ファスト・スタート・フェイルオーバーの発生後にのみ存在し、新規プライマリ・データベースと回復を実行しているデータベースの両方に表示されます。回復が完了すると、両方のデータベースでクリアされます。

完了済

STALLED

ターゲット・スタンバイ・データベースとの接続が切断され、UNSYNCHRONIZED状態(最大可用性モード)またはTARGET OVER LAG LIMIT状態(最大パフォーマンス・モード)の変更がターゲット・スタンバイ・データベースとオブザーバのどちらからも確認できない場合、プライマリ・データベースに表示されます。これらの条件でプライマリが無期限にストールするには、FastStartFailoverPmyShutdown構成プロパティの値がFALSEである必要があることに注意してください。このプロパティの値がTRUEの場合、プライマリは、FastStartFailoverThresholdプロパティで指定された秒数の間ストールした後に停止します。

フェイルオーバーが実行された可能性が高いため、プライマリ・データベースが停止またはストールします。

ノート: この状態は、ファスト・スタート・フェイルオーバーが可能で、ターゲット・スタンバイ・データベースもオブザーバも存在しないときに起動し、データベースのオープンを継続可能かどうかを確認した場合にもプライマリで発生します。

可

TARGET OVER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過した場合に表示されます。

不可

TARGET UNDER LAG LIMIT

構成が最大パフォーマンス・モードで動作しているとき、プライマリ・データベースのREDO生成時点からのスタンバイ・データベースのREDO適用時点の遅れが、FastStartFailoverLagLimit構成プロパティに指定された秒数を超過していない場合に表示されます。

可

SUSPENDED

プライマリ・データベースまたはターゲット・スタンバイ・データベースが制御された方法で(ABORTオプションではなく、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを使用して)停止された場合、ターゲット・スタンバイ・データベースにのみ表示されます。この場合、ファスト・スタート・フェイルオーバーは禁止されます。プライマリ・データベースとの接続がリストアされると、SUSPENDEDがクリアされます。

不可

SYNCHRONIZED

プライマリ・データベースとターゲット・スタンバイ・データベースが同期化されており、構成が最大可用性モードで動作している場合に表示されます。

ターゲット・スタンバイ・データベースがSYNCHRONIZEDを表示し、FS_FAILOVER_OBSERVER_PRESENT列がYESを表示する場合に可能です。

UNSYNCHRONIZED

ターゲット・スタンバイ・データベースがプライマリ・データベースのすべてのREDOデータを持たず、構成が最大可用性モードで動作している場合に表示されます。

不可

FS_FAILOVER_MODE

現在のファスト・スタート・フェイルオーバー・モードを表示します。

モードには、次のいずれかの値を含むことができます。

  • DISABLED: ファスト・スタート・フェイルオーバーは無効化されています。

  • OBSERVE-ONLY: ファスト・スタート・フェイルオーバーは監視専用モードで有効にされます。

  • ZERO DATA LOSS: ファスト・スタート・フェイルオーバーがデータ損失ゼロで有効にされます。このモードでは、FastStartFailoverLagLimit構成プロパティはゼロに設定されます。

  • POTENTIAL DATA LOSS: ファスト・スタート・フェイルオーバーがデータ損失一部ありで有効化されます。このモードでは、FastStartFailoverLagLimit構成プロパティはゼロ以外の値に設定されます。ファスト・スタート・フェイルオーバーでは、FastStartFailoverlagLimitで指定された時間内にデータ損失が発生する可能性があります。

V$FAST_START_FAILOVER_CONFIGビュー

プライマリ・データベースでV$FAST_START_FAILOVER_CONFIGビューを問い合せると、システム上のファスト・スタート・フェイルオーバー構成について統計を表示できます。

監視可能な統計の一部を次に示します。

  • MODE。現在のファスト・スタート・フェイルオーバー・モードが表示されます。

  • STATUS。ファスト・スタート・フェイルオーバーのステータスが示されます。

  • CURRENT_TARGET。Data Guard構成の現在のフェイルセーフ・フェイルオーバー・オブザーバのターゲット・スタンバイであるスタンバイのDB_UNIQUE_NAMEが示されます。

次に、V$FAST_START_FAILOVER_CONFIGビューを問い合せる例を示します。 

SQL> SELECT FSFO_MODE, STATUS, CURRENT_TARGET FROM V$FAST_START_FAILOVER_CONFIG;

FSFO_MODE           STATUS                 CURRENT_TARGET
------------------- ---------------------- ------------------------------
ZERO DATA LOSS      SYNCHRONIZED           South_Sales

V$FS_FAILOVER_STATSビュー

プライマリ・データベースのV$FS_FAILOVER_STATSビューを問い合せて、システムで発生したファスト・スタート・フェイルオーバーに関する統計を表示できます。

ファスト・スタート・フェイルオーバーは完全に自動化されており、いつでも発生する可能性があるので、このような問合せを実行すると役立つ場合があります。監視可能な統計の一部を次に示します。

  • LAST_FAILOVER_TIMEは、最後に発生したファスト・スタート・フェイルオーバーのタイムスタンプを示します。

  • LAST_FAILOVER_REASONは、最後に発生したファスト・スタート・フェイルオーバーの原因を示します。

次に、V$FS_FAILOVER_STATSビューの問合せの例を示します。 

SQL> SELECT LAST_FAILOVER_TIME, LAST_FAILOVER_REASON FROM V$FS_FAILOVER_STATS;
 LAST_FAILOVER_TIME
--------------------
LAST_FAILOVER_REASON
--------------------------------------------------------------------------------
12/14/2022 17:12:13
Primary Disconnected

ファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバーを無効化すると、オブザーバはターゲット・スタンバイ・データベースへのフェイルオーバーを開始できなくなります。

ファスト・スタート・フェイルオーバーが無効化されている場合でも、手動フェイルオーバーを実行できることがあります。手動フェイルオーバーの詳細は、「手動フェイルオーバー」を参照してください。

ノート:

ファスト・スタート・フェイルオーバーを無効にしても、オブザーバは停止されません。オブザーバを停止するには、「オブザーバの停止」を参照してください。

ファスト・スタート・フェイルオーバーを無効にするには、Cloud Controlのファスト・スタート・フェイルオーバー・ウィザードまたはDGMGRLのDISABLE FAST_START FAILOVER [FORCE]コマンドを使用します。FORCEオプションを使用すると、エラーが発生した場合でも、接続先のデータベースでファスト・スタート・フェイルオーバーが無効化されます。FORCEオプションが必要かどうかは、プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在するかどうかによって決まります。

  • プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在し、接続先のデータベースがプライマリ・データベースとネットワークで接続されている場合、FORCEオプションを使用しても効果はありません。オプションを指定せずにDISABLE FAST_START FAILOVERを使用してください。この方法では、ブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

    無効化操作中にエラーが発生した場合、ブローカによりエラー・メッセージが戻され、無効化操作が停止されます。

  • プライマリ・データベースおよびターゲット・スタンバイ・データベースにネットワーク接続が存在しないか、または接続先のデータベースにプライマリ・データベースとのネットワーク接続が存在しない場合、DISABLE FAST_START FAILOVERをFORCEオプションとともに使用することを考慮します。

    DISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカはブローカ構成内のすべてのデータベースでファスト・スタート・フェイルオーバーをi無効化できない場合があります。その結果、フェイルオーバーの条件を満たしているとオブザーバが判別した場合に、オブザーバがターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを実行しないという保証がなくなります。次のリストに、プライマリ・データベース、ターゲット・スタンバイ・データベースおよびファスト・スタート・フェイルオーバーのターゲットでないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドが発行された場合に、ブローカ構成でファスト・スタート・フェイルオーバーが無効化される範囲を示しています。

    次のデータベースでこのコマンドを発行した場合、次のようになります。

    • プライマリ・データベースとの接続が存在しないターゲット・スタンバイ・データベースで発行した場合、ターゲット・スタンバイ・データベースでのみファスト・スタート・フェイルオーバーが無効化されます。この場合、オブザーバではフェイルオーバーの条件を満たしていてもファスト・スタート・フェイルオーバーを実行できません。ファスト・スタート・フェイルオーバーの発生を確実に防ぐには、ターゲット・スタンバイ・データベースに接続しているときにFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化します。

      プライマリ・データベースおよびターゲット・スタンバイ・データベースのネットワーク接続が回復すると、ブローカによりブローカ構成全体のファスト・スタート・フェイルオーバーが無効化されます。

    • プライマリ・データベースで発行した場合、構成内のネットワーク接続が確立されたすべてのデータベースで、ファスト・スタート・フェイルオーバーの無効化が試行されます。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が確立されていない場合、ターゲット・スタンバイ・データベースではファスト・スタート・フェイルオーバーが有効のままとなり、フェイルオーバーの条件を満たした場合にオブザーバによりファスト・スタート・フェイルオーバーが試行されます。

      注意:

      この処理を実行すると、ファスト・スタート・フェイルオーバーが発生した場合に、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。このため、ターゲット・スタンバイ・データベースにこのコマンドを最初に発行する必要があります。

    • プライマリ・データベースとの接続が存在しない別のスタンバイ・データベースで発行した場合、このデータベースではファスト・スタート・フェイルオーバーが無効化されます。ターゲット・スタンバイ・データベースでファスト・スタート・フェイルオーバーが無効化されていないため、フェイルオーバーの条件を満たした場合に、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行される場合があります。

      プライマリ・データベースとスタンバイ・データベース(非ターゲット)のネットワーク接続が回復すると、ブローカの現在のファスト・スタート・フェイルオーバーの設定(ENABLEDまたはDISABLED)がターゲットでないスタンバイに伝播されます。

      注意:

      ネットワークが切断されており、プライマリ・データベースまたはプライマリ・データベースと接続されていないスタンバイ・データベースでDISABLE FAST_START FAILOVER FORCEコマンドを発行した場合、ブローカ構成内の一部のデータベースでファスト・スタート・フェイルオーバーが無効化されない場合があります。結果として、フェイルオーバーの条件を満たしている場合、オブザーバによりターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが開始される可能性があります。これにより、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。

FORCEオプションを必要とする条件

FORCEオプションを使用しないファスト・スタート・フェイルオーバーの無効化が正常に実行されるのは、コマンドが発行されたデータベースとプライマリ・データベースの間にネットワーク接続が存在し、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在する場合のみです。ファスト・スタート・フェイルオーバーを無効化するには、この方法をお薦めします。

ただし、プライマリ・データベースとターゲット・スタンバイ・データベースの間にネットワーク接続が存在しない場合、またはファスト・スタート・フェイルオーバーの無効化コマンドを発行したデータベースとプライマリ・データベースとの間にネットワーク接続が存在しない場合に、ファスト・スタート・フェイルオーバーを無効化する必要があることも考えられます。ネットワーク接続が失われている場合、フェイルオーバーの条件を満たした場合に、オブザーバでターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーが試行されることがあるので注意してください。FORCEオプションは、次の場合にファスト・スタート・フェイルオーバーを無効にするための推奨の方法です。

  • ネットワーク障害により、プライマリ・データベースがオブザーバおよびターゲット・スタンバイ・データベースから分離された場合(フェイルオーバーの条件を満たす前)。

    この場合、プライマリ・データベースが分離されている間にファスト・スタート・フェイルオーバーが実行された可能性があるため、プライマリ・データベースがストールし、トランザクションをコミットできなくなります。ネットワークの切断が長時間にわたると予想され、プライマリ・データベースを使用可能にする必要がある場合は、まず、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。次に、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効にします。可能な場合、プライマリ・データベースでFORCEオプションによりファスト・スタート・フェイルオーバーを無効にする前に、ターゲット・スタンバイ・データベースにファスト・スタート・フェイルオーバーが実行されていないことを確認します。

    注意:

    この処理により、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

  • 構成内のスタンバイ・データベースに手動フェイルオーバーを実行する場合(たとえば、プライマリ・データベースおよびターゲット・スタンバイ・データベースがフェイルオーバー可能でないときにプライマリ・データベースで障害が発生したため)。

    この場合、データベースがフェイルオーバー可能でないため、ファスト・スタート・フェイルオーバーを実行できません。同じ理由で、ターゲット・スタンバイ・データベースへの手動フェイルオーバーを実行できません。続行するには、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、手動フェイルオーバーを実行する必要があります。

    注意:

    この処理によりデータが失われ、構成内の2つのデータベースで同時にプライマリ・データベース・ロールが引き継がれる可能性があります。ターゲット・スタンバイでFORCEオプションによりファスト・スタート・フェイルオーバーを最初に無効化しておくと、これを回避できます。

  • ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーに失敗した場合。

    なんらかの理由でフェイルオーバーに失敗した場合、ターゲット・スタンバイ・データベースがフェイルオーバー可能かどうかにかかわらず、ターゲット・スタンバイ・データベースが動作不能になる可能性があります。フェイルオーバーに使用できる別のスタンバイ・データベースが存在する場合、まずそのスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効化してから、そのスタンバイ・データベースへの手動フェイルオーバーを実行できます。

  • まもなくプライマリ・データベースによりサービスが再開されるため、ファスト・スタート・フェイルオーバーを実行しないようにする場合。

    この場合、ターゲット・スタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にします。プライマリ・データベースとターゲット・スタンバイ・データベースとの接続が回復すると、構成内のすべてのデータベースでファスト・スタート・フェイルオーバーが無効化されます。

Cloud Controlを使用したファスト・スタート・フェイルオーバーの無効化

ファスト・スタート・フェイルオーバー・ウィザードで「無効化」をクリックします。次に、「続行」をクリックして次のページに進みます。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

DGMGRLを使用したファスト・スタート・フェイルオーバーの無効化

DISABLE FAST_START FAILOVERコマンドまたはDISABLE FAST_START FAILOVER FORCEコマンドを発行します。詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」の「DISABLE FAST_START FAILOVER」コマンドを参照してください。

ファスト・スタート・フェイルオーバーのパフォーマンスに関する考慮事項

このリストには、ファスト・スタート・フェイルオーバーの使用時に、より優れたパフォーマンスを得るための推奨事項がいくつか含まれています。

  • フェイルオーバー時間は、ターゲット・スタンバイ・データベース(フィジカルまたはロジカル・スタンバイ・データベース)がプライマリ・データベースから受け取ったREDOデータをすべて適用したかどうかによって決まります。

  • 最大パフォーマンス・モードで動作している構成でファスト・スタート・フェイルオーバーを有効化すると、REDOデータが非同期でターゲット・スタンバイに転送されるため、プライマリ・データベースでの全体的なパフォーマンスが向上します。この場合はデータが消失しないことが保証されないことに注意してください。

  • スタンバイ・データベースへのREDOデータの適用がプライマリ・データベースのREDO適用率と一致した状態が保たれるように、リカバリを最適化するステップを実行すると、ファスト・スタート・フェイルオーバーが高速になります。ログ適用率を最適化するには、次のようにします。

    • データベース・プロパティDelayMinsを設定することにより、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用を遅延させないでください(詳細は、「ログ適用サービスの管理」を参照してください)。

    • フィジカル・スタンバイ・データベースのログ適用率のチューニングの詳細は、『Oracle Data Guard概要および管理』を参照してください。

    • 次の場所にあるOracle Maximum Availability Architectureの簡単な技術的説明を参照してください。

      http://www.oracle.com/goto/maa

  • FastStartFailoverLagLimit構成プロパティを設定する際は、パフォーマンスとデータ消失の可能性の間のトレードオフを考慮してください。

    • ラグ制限を低くすると、データの消失は最小限に抑えられますが、プライマリ・データベースのパフォーマンスに影響を与える場合があります。

    • ラグ制限を高くすると、消失データ量が増加する可能性がありますが、プライマリ・データベースのパフォーマンスへの影響は緩和されます。

オブザーバの管理

オブザーバ・プロセスは、ブローカのDGMGRLクライアント側コンポーネントに統合されており、通常はプライマリ・データベースまたはスタンバイ・データベースおよびブローカ構成を管理するコンピュータとは異なるコンピュータ上で動作します。

1つのData Guard構成に対して最大4つのオブザーバを設定できます。オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。(「ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行」を参照)。オブザーバの主な目的は、停止時間が長くなる可能性がある、手動フェイルオーバー・プロセスで必要な人的操作を少なくすることで、高可用性および完全自動コンピューティングを強化することです。

Cloud ControlのOracle Data Guardの「概要」ページまたはDGMGRLコマンドを使用して、オブザーバを管理できます。図6-2に、オブザーバによるファスト・スタート・フェイルオーバー構成の監視を示しています。

図6-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ

図6-2の説明が続きます
「図6-2 ファスト・スタート・フェイルオーバー環境でのオブザーバ」の説明

次の各項では、オブザーバの管理情報を説明します。

オブザーバのインストールおよび起動

オブザーバは、プライマリ・システムおよびスタンバイ・システムとは別のコンピュータ・システムにインストールし、動作させる必要があります。

オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分であり、次の各項で詳細に説明しています。

オブザーバを起動するには、SYSDGまたはSYSDBA権限を持つアカウントでDGMGRLにログインできる必要があります。オブザーバは、DGMGRLでOracle Data Guard構成に接続したときに使用したSYS資格証明を使用してプライマリ・データベースおよびターゲット・スタンバイ・データベースに接続するOCI (Oracle Call Interface)クライアントです。

関連項目:

  • オブザーバとDGMGRLの間の互換性要件の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1625597.1を参照してください

Data Guard Broker構成での複数のオブザーバの起動

ノート:

Oracle Databaseリリース12.2以上では、Oracle Enterprise Manager Cloud Control (Cloud Control)でEnterprise Managerコマンドライン・インタフェース(EM CLI)を使用した複数のオブザーバの構成がサポートされます。EMCLI動詞dg_configure_observersを使用します。この動詞のサブコマンドには、start、stop、setMaster、showおよびdelete_alternate_observerが含まれます。

1つのData Guard Broker構成を監視するために最大で4つのオブザーバを登録できます。各オブザーバは、START OBSERVERコマンドの発行時に指定する名前で識別されます。1つの構成に対して複数のオブザーバが登録されている場合は、次の条件が適用されます。

  • ファスト・スタート・フェイルオーバーが有効化されている場合、オブザーバの1つはマスター・オブザーバです。残りのオブザーバはバックアップ・オブザーバと呼ばれます。ファスト・スタート・フェイルオーバーが無効化されている場合、どのオブザーバもマスター・オブザーバとは呼ばれず、すべてのオブザーバが同じ機能を持ちます。

  • 同一のData Guard Broker構成上で2つのオブザーバに同じ名前を付けることはできません。

  • オブザーバの名前を指定しない場合は、デフォルトのオブザーバ名(START OBSERVERコマンドが発行されたマシンのホスト名)が使用されます。

  • オブザーバ名の大/小文字は区別されません。

  • 文字列"NONAME"はオブザーバ名として使用できません。

  • 各オブザーバには独自のログ・ファイルがあります。ログ・ファイル名は、START OBSERVERコマンドのLOGFILE ISオプションで指定します。指定したログ・ファイルにアクセスできない場合、またはLOGFILE ISオプションが使用されていない場合、オブザーバの出力は標準出力に送信されます。

  • テスト目的の場合を除き、Data Guard Broker構成に対して同じホスト上で複数のオブザーバを起動しないことをお薦めします。

  • SHOW FAST_START FAILOVERコマンドは、登録済オブザーバのリストを表示して、どのオブザーバがマスターなのかを示します。

  • SHOW OBSERVERコマンドは、登録済オブザーバの詳細情報を表示します。

マスター・オブザーバとバックアップ・オブザーバ

ファスト・スタート・フェイルオーバーが無効化されている場合、オブザーバでファスト・スタート・フェイルオーバーを調整する必要がないため、プライマリおよびターゲット・スタンバイでは、ファスト・スタート・フェイルオーバーが有効化されるまでマスター・オブザーバは指定されません。ファスト・スタート・フェイルオーバーが有効化されている場合、プライマリおよびスタンバイは登録済オブザーバの1つをランダムに選択してマスターにします。ファスト・スタート・フェイルオーバーが有効化されていて、登録済オブザーバがない場合、最初に起動したオブザーバがマスター・オブザーバに指定され、その後に起動した他のオブザーバはすべてバックアップ・オブザーバになります。Data Guard Brokerでファスト・スタート・フェイルオーバーを調整できるのはマスター・オブザーバのみです。他の登録済オブザーバはすべてバックアップ・オブザーバとみなされます。

マスター・オブザーバの手動による変更

必要に応じてSET MASTEROBSERVER TO Observer-Nameコマンドを使用し、マスターにするオブザーバを変更できます。たとえば: 
DGMGRL> SET MASTEROBSERVER TO boston-obsever;
Succeeded.

PreferredObserverHostsプロパティが現在のプライマリに対して設定されている場合は、プロパティで指定されたオブザーバのみをSET MASTEROBSERHOST TOコマンドで使用できます。このコマンドが発行された場合、実際に切替えが発生するのは、プライマリがターゲット・スタンバイと次回通信したとき(ファスト・スタート・フェイルオーバーが有効化されている場合、通常は数秒以内)です。SHOW OBSERVERコマンドを発行して、切替えが実行されたことを確認できます。詳細は、「SET MASTEROBSERVER TO」を参照してください。

バックグラウンド・プロセスとしてのオブザーバの起動

オブザーバをバックグラウンド・プロセスとして実行するには、DGMGRLコマンドSTART OBSERVER IN BACKGROUNDを使用します。特定のブローカ構成内にある1つ以上のデータベースに接続可能な接続識別子を指定する必要があります。次に、オブザーバをバックグラウンド・プロセスとして起動する例を示します。 

DGMGRL> START OBSERVER IN BACKGROUND 
FILE IS  /net/sales/dat/oracle/broker/fsfo.dat 
LOGFILE IS /net/sales/dat/oracle/broker/observer.log 
CONNECT IDENTIFIER IS sales_p

Submitted command "START OBSERVER" using connect identifier "sales_p" 

DGMGRL>

START OBSERVER IN BACKGROUNDコマンドではOracleウォレットを使用して資格証明を取得し、データベース・サーバーにログインして、オブザーバを登録します。CONNECTコマンドを使用してブローカ構成内のデータベース・サーバーに正常に接続している場合でも、このコマンドでは既存の接続が無視され、Oracleウォレットに格納されている資格証明が使用されます。詳細は、「START OBSERVER IN BACKGROUND」を参照してください。

単一ホスト上での複数のオブザーバの起動

1つのOracleホームを使用して複数のオブザーバを起動し、各オブザーバで異なるファスト・スタート・フェイルオーバー構成を監視する場合は、FILE修飾子を使用して、監視する各構成に一意のオブザーバ構成ファイルの場所を指定してください。オブザーバが生成するロギングを取得する場合は、START OBSERVERコマンドでLOGFILEオプションを使用し、一意のファイル名を指定してください。たとえば: 

% dgmgrl
DGMGRL> CONNECT /@primary1;
DGMGRL> START OBSERVER FILE IS '/u01/oracle/dbs/config1.dat' 
LOGFILE IS '/u01/oracle/log/config1.log'

% dgmgrl
DGMGRL> CONNECT /@primary2;
DGMGRL> START OBSERVER FILE IS '/u01/oracle/dbs/config2.dat' 
LOGFILE IS '/u01/oracle/log/config2.log'

マスター・オブザーバに関する情報の表示

マスター・オブザーバに関する情報を検索するには、V$FAST_START_FAILOVER_CONFIGビューを問い合せます。

  • OBSERVER_HOSTは、マスター・オブザーバが動作するコンピュータの名前を示します

  • OBSERVER_PRESENTは、マスター・オブザーバがローカル・データベースに接続しているかどうかを示します

次の表の列値は、Oracle Real Application Clusters (Oracle RAC)環境内の全インスタンスで一貫性が保たれています。つまり、オブザーバがOracle RAC内のインスタンスに接続されている場合、すべてのインスタンスにYESの値が示されます。

表6-3 V$DATABASEビューのFS_FAILOVER_OBSERVER_PRESENT列

列値 説明

YES

マスター・オブザーバは現在ローカル・データベースに接続している

NO

マスター・オブザーバはローカル・データベースに接続していない

たとえば、ファスト・スタート・フェイルオーバーが実行可能かどうかを判断するには、ターゲット・スタンバイ・データベースで、STATUS列にSYNCHRONIZEDまたはTARGET UNDER LAG LIMITが表示されており、OBSERVER_PRESENT列にYESと表示されていることを確認します。たとえば:

データベース STATUS 保護モード OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

最大可用性

YES

スタンバイ

SYNCHRONIZED

最大可用性

YES

プライマリ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

スタンバイ

TARGET UNDER LAG LIMIT

最大パフォーマンス

YES

次の例では、プライマリ・データベースとオブザーバの間のネットワークに障害が発生したと仮定しています。この場合、FS_FAILOVER_STATUSおよびFS_FAILOVER_OBSERVER_PRESENT列は次の表に示すように表示され、ファスト・スタート・フェイルオーバーは実行されません。

データベース FS_FAILOVER_STATUS FS_FAILOVER_OBSERVER_PRESENT

プライマリ

SYNCHRONIZED

NO

スタンバイ

PRIMARY UNOBSERVED

YES

関連項目:

すべてのオブザーバに関する情報の表示

V$FS_FAILOVER_OBSERVERSビューでは、マスター・オブザーバやバックアップ・オブザーバを含むすべてのオブザーバに関する詳細情報を検索できます。

オブザーバごとに、V$FS_FAILOVER_OBSERVERSビューにより、オブザーバ名、ホスト、マスター・オブザーバかどうか、マスター・オブザーバになった時期、プライマリおよびターゲット・スタンバイ・データベースに現在接続しているかどうか、オブザーバ・ログ・ファイルの場所、およびオブザーバ・ランタイム・データ・ファイル(fsfo.dat)の場所が示されます。

関連項目:

マスター・オブザーバに障害が発生した場合の動作。

マスター・オブザーバに障害が発生した場合のブローカの動作は、ブローカ構成内のオブザーバが1つなのか、複数あるのかによって異なります。

オブザーバが1つしかない場合は、そのオブザーバがマスター・オブザーバとみなされます。オブザーバが複数ある場合は、そのうちの1つのみがマスター・オブザーバです。

ブローカ構成の登録済オブザーバが1つのみの場合

構成の登録済オブザーバが1つのみで、プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でオブザーバからの接続が失われた場合、ブローカにより、構成が監視されていないと報告されます。 構成およびデータベースのステータスにより、オブザーバが動作していないと報告され、次のいずれかのステータス・メッセージが戻されます。 

ORA-16658: unobserved fast-start failover configuration
ORA-16820: fast-start failover observer is no longer observing this database

構成が監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。そのため、ターゲット・スタンバイ・データベースに障害が発生した場合でも、プライマリ・データベースはトランザクションの処理を続行できます。オブザーバとプライマリ・データベースとの接続が再確立され、プライマリ・データベースによりターゲット・スタンバイ・データベースに通知が送られると、構成ステータスによりSUCCESSステータスが戻されます。

関連項目:

ファスト・スタート・フェイルオーバー構成の統計およびステータスの表示

ブローカ構成に複数の登録済オブザーバがある場合

構成に複数の登録済オブザーバがあり、プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でマスター・オブザーバからの接続が失われた場合、ブローカは、バックアップ・オブザーバを新しいマスター・オブザーバに指定しようとします。この指定はオブザーバ・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)に記録されます。また、SHOW FAST_START FAILOVERコマンドおよびSHOW OBSERVERコマンドで表示される出力で、新しいマスター・オブザーバが識別されます。

ノート:

新しいマスター・オブザーバの識別中、新しいマスター・オブザーバが選択されて構成を監視し始めるまで、ファスト・スタート・フェイルオーバーは発生しません。

プライマリ・データベースまたはターゲット・スタンバイ・データベースとすべてのバックアップ・オブザーバとの接続が失われた場合、ブローカは、バックアップ・オブザーバを新しいマスター・オブザーバに指定しようとせずに、構成が監視されていないことを報告します。構成およびデータベースのステータスにより、登録済オブザーバが1つしかない場合に戻るエラー・メッセージと同じメッセージが報告されます。

オブザーバのプライマリへの接続の管理

ObserverOverrideおよびObserverReconnectプロパティを使用すると、プライマリへの接続をさらに制御できます。

オブザーバが、FastStartFailoverThresholdプロパティで指定されているより長い期間、プライマリ・データベースへの接続を失った場合、スタンバイ・データベースへのフェイルオーバーが試みられます。FastStartFailoverThresholdプロパティで指定された期間内にスタンバイがプライマリからアクセスを受けた場合、フェイルオーバーは試行されません。

この動作をオーバーライドして、オブザーバがFastStartFailoverThresholdで指定された秒数より長い間プライマリにアクセスできない場合にファスト・スタート・フェイルオーバーが行われるようにするには、ObserverOverrideプロパティをTRUEに設定します。たとえば: 

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverOverride=TRUE;

通常、オブザーバは一度プライマリに接続したら、接続に障害が発生しないかぎり、再接続を試みません。プライマリへのネットワーク接続の健全性をテストする手段として、オブザーバがプライマリ・データベースに定期的に再接続する場合は、ObserverReconnect構成プロパティを使用します。これは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。次の例では、ObserverReconnectが30秒に設定されています。この場合、オブザーバは30秒ごとにプライマリ・データベースに対して新しい接続を確立します。 

DGMGRL> EDIT CONFIGURATION SET PROPERTY ObserverReconnect=30;

ファスト・スタート・フェイルオーバーの開始にかかる時間の構成

ブローカ構成プロパティを使用して、プライマリ・データベースでの障害の検出にかかる時間を設定します。

ファスト・スタート・フェイルオーバーを有効にする前に、次のいずれかの方法を使用して、プライマリ・データベースでの障害の検出にかかる時間を設定します。

  • FastStartFailoverThreshold構成プロパティの設定

    ブローカは、このプロパティで指定された秒数の経過後にフェイルオーバーを開始します。最小検出時間は6秒で、これはFastStartFailoverThresholdプロパティのデフォルト値です。

  • ObserverPingIntervalおよびObserverPingRetry構成プロパティを設定します。

    プライマリ障害検出時間を1秒にするには、これらのプロパティを両方とも設定します。ObserverPingIntervalの最小値は100ミリ秒で、ObserverRetryCountの最小値は10です。

ノート:

ObserverPingIntervalおよびObserverPingRetryプロパティの設定は、低レイテンシ環境でのみ使用する必要があります。

オブザーバの停止

特定のオブザーバまたはすべてのオブザーバを手動で停止できます。

オブザーバを停止する前に、次の点に注意してください。

  • オブザーバは、STOP OBSERVERコマンドを発行してすぐには停止しません。ブローカがSTOP OBSERVER要求を受け取ると、要求は次回オブザーバがブローカと通信する際にオブザーバに渡され、その後にオブザーバは停止します。

  • オブザーバを停止しても、ファスト・スタート・フェイルオーバーは無効化されません。ただし、ターゲット・スタンバイ・データベースが監視されない状態の場合、ファスト・スタート・フェイルオーバーは実行できません。

  • ファスト・スタート・フェイルオーバーが無効化されている場合にオブザーバを停止するには、プライマリ・データベースが動作している必要があります。

  • ファスト・スタート・フェイルオーバーが有効化されているときにオブザーバを停止するには、プライマリ・データベースおよびターゲット・スタンバイ・データベースが接続されており、相互に通信している必要があります。相互に分離している場合は、まずFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にしてから、オブザーバを停止する必要があります。(FORCEオプションを使用する際に考慮すべき重要事項については、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。)

すべてのオブザーバの停止

STOP OBSERVER ALLを指定すると、ブローカ構成内に登録済のすべてのオブザーバを停止できます。

オブザーバが複数ある場合の特定のオブザーバの停止

複数の登録済オブザーバが動作している場合に特定のオブザーバを停止するには、次のコマンドを発行します。

DGMGRL> STOP OBSERVER observer_name;

任意のマシンからDGMGRLにログインして、オブザーバを停止できます。たとえば、observer1が動作しているシステムにログインして、observer2を停止できます。

複数のオブザーバが構成されている環境で、マスター・オブザーバは停止できません(ただし、それが動作中の最後のオブザーバである場合を除きます)。現在マスター・オブザーバに指定されているオブザーバを停止するには、まずSET MASTEROBSERVERコマンドを発行して、別のオブザーバをマスター・オブザーバに指定します。その後で、STOP OBSERVERコマンドを元のマスター・オブザーバに対して正常に発行できます。

オブザーバが1つしかない場合のオブザーバの停止

オブザーバを停止するには、次のいずれかの方法を使用します:

  • Cloud Controlの使用

    ファスト・スタート・フェイルオーバー・ウィザードの1ページ目で「オブザーバを停止」オプションを選択し、ページ下部の「続行」をクリックします。詳細は、Cloud Controlのオンライン・ヘルプを参照してください。

  • DGMGRLの使用

    次のコマンドを発行します。

    DGMGRL> STOP OBSERVER;

    登録済オブザーバが複数ある場合、このコマンドを実行するとエラーが戻ります。オブザーバが複数ある場合、名前は必須です。

ノート:

詳細は、STOP OBSERVERコマンドを参照してください。

オブザーバの別のコンピュータへの移動

オブザーバを1つのシステム上で停止し、別のシステム上で再起動する処理により、オブザーバをコンピュータ間で移動できます。

オブザーバを別のコンピュータに移動するには:

  1. 「オブザーバの停止」の説明に従って、ブローカ構成内の任意のコンピュータ・システムからオブザーバを停止します。
  2. 「ファスト・スタート・フェイルオーバーの有効化」のステップ8の説明に従って、新規コンピュータ・システムでオブザーバを起動します。

オブザーバを移動する際にファスト・スタート・フェイルオーバーを無効化する必要はありません。

オブザーバによるファスト・スタート・フェイルオーバー構成情報のメンテナンス方法

オブザーバでは、オブザーバを起動した作業ディレクトリに作成されているバイナリ・ファイルで、ファスト・スタート・フェイルオーバー構成に関する情報が永続的にメンテナンスされます。

デフォルトでは、オブザーバの起動時に、現行の作業ディレクトリにこのファイルが作成され、fsfo.datという名前が付けられます。このファイルには、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方に対する接続識別子が含まれます。

権限のないユーザーはこのファイルを読めないことを確認します。

オブザーバの起動後は、ファイルの名前および場所を変更できません。ただし、オブザーバの起動にDGMGRLのSTART OBSERVERコマンドを使用し、FILE IS修飾子を含める場合は、ファイルの名前または場所を変更できます。詳細は、START OBSERVERコマンドを参照してください。

ノート:

オブザーバが通常と異なる方法で(CTRL/Cを入力するなど)停止された場合、オブザーバを再起動し、FILE IS修飾子を含む既存のfsfo.datファイルを参照してください。

複数構成のオブザーバの管理

DGMGRLを使用して、ブローカ構成のグループ内にある複数のオブザーバを管理できます。

構成のグループに対応する複数のオブザーバを起動、停止および表示できます。また、構成のグループに対応する複数のマスター・オブザーバ・ホストを特定の1つのホストに切り替えることもできます。

管理対象のブローカ構成のグループは、オブザーバ構成ファイルで宣言されます。デフォルトのグループは、オブザーバ構成ファイルに定義されているすべての構成です。デフォルトを使用しない場合、特定のグループを定義できます。オブザーバ構成ファイルはテキスト・ファイルで、オブザーバとグループを定義する構文はlistener.oraファイルまたはtnsnames.oraファイルで使用されている構文と類似しています。次の順に、2つの部分で構成されます。

  1. 構成宣言 — このセクションは必須です。オブザーバ構成ファイルの最初の部分として表示される必要があります。

  2. グループ定義 — このセクションは省略可能です。指定する場合は、2番目の部分に、グループごとに1つ以上のブローカ構成が宣言されている必要があります。

必須の構成宣言の構文

構成宣言の構文を次に示します。

BROKER_CONFIGS = ( 
(configuration1-definition) 
(configuration2-definition)
...
(configuration-n-definition)
)

各ブローカ構成の定義を次に示します。

CONFIG= (NAME        =configuration-name)
        (CONNECT_ID  =connect-identifier) 
        (CONFIG_HOME =config-home-location) 
)

次の点に注意してください。

  • configuration-nameは、Data Guard Broker構成のメタデータに定義されている名前と異なっていてもかまいません。(メタデータに定義されている名前には、オブザーバ構成ファイルでは使用できない空白や国際文字が含まれている場合があるので、これは便利です。)

  • connect-identifierはtnsnames.oraに定義されているTNS別名であり、これを使用して、このData Guard Broker構成内のすべてのデータベースのすべてのインスタンスに接続できます。

  • Config-home-locationでは、オブザーバ・ログ・ファイルおよびFSFO.datファイルの場所を指定します。

  • 構成定義内で重複する構成名は使用できません。

グループ定義(省略可能)の構文

ブローカ構成グループの定義(省略可能)の構文を次に示します。

CONFIG_GROUPS = ( 
(group1-definition) 
(group2-definition)
...
(group-n-definition)
)

各グループの定義を次に示します。

GROUP =(NAME=group-name)
             (CONFIG_LIST= 
                   (NAME=configuration1-name)
                   (NAME=configuration2-name)
                   ...
                   (NAME=configuration-n-name)
              )

次の点に注意してください。

  • グループ定義セクションは省略可能です。グループが定義されていない場合でも、ファイルに定義されているすべての構成全体に対する操作は可能です。

  • ALLという語は予約済キーワードなので、グループ名としては使用できません。

  • 重複するグループ名は使用できません。
  • 定義するグループごとに1つ以上のブローカ構成が必要です。
  • 参照されるブローカ構成名はすべて構成宣言セクションに含まれている必要があります。
  • ブローカ構成は複数のグループに属することができます。

オブザーバ構成ファイルの指定

複数のオブサーバーに影響するコマンドを実行する際、オブサーバー構成ファイルの名前と場所を指定しなかった場合、は、$DG_ADMIN/adminまたは現在の作業ディレクトリ(環境変数DG_ADMINが定義されていない場合)でobserver.oraという名前のファイルを検索します。ファイルが存在しない場合、コマンドは失敗します。

ただし、オブザーバ構成ファイルの名前と場所は指定できます。これを行うには、SET ObserverConfigFileコマンドおよびSHOW ObserverConfigFileコマンドを使用します。これらのコマンドはDGMGRLコマンドラインから発行できますが、コマンドの使用に先立ってログオンする必要はありません。

  • SET ObserverConfigFile — カスタマイズされたオブザーバ構成ファイルを指定する場合に使用します。ObserverConfigFileはDGMGRLセッションのランタイム・プロパティです。新しいDGMGRLクライアントを起動するたびに、これを指定する必要があります。

  • SHOW ObserverConfigFile — ランタイム・プロパティObserverConfigFileを確認する場合に使用します。現在のDGMGRLクライアントを起動した後にSET ObserverConfigFileコマンドを使用していない場合、結果は常にObserverConfigFile=observer.oraとなります。

複数構成でのオブザーバを管理するためのコマンド

(オブザーバ構成ファイルに宣言されている)構成のグループに対して実行可能なコマンドを次に示します。

  • START OBSERVING [cfg_group_name] — 指定したグループの各ブローカ構成に対応する新規オブザーバを起動します。グループ名が指定されていない場合は、observer.oraに定義されている各ブローカ構成に対して新規オブザーバが起動されます。

  • STOP OBSERVING [cfg_group_name] — このDGMGRLを実行中のこのホスト上で動作している、指定したグループのすべてのブローカ構成のローカル・オブザーバを停止します

  • SHOW OBSERVERS [FOR fg_group_name ] — 指定したグループのすべての構成のオブザーバに関する情報を表示します。このコマンドによって表示される情報は、個々の構成に対してSHOW OBSERVERコマンドを実行した場合に表示される情報と同じです。グループ名が指定されていない場合、SHOW OBSERVERSだけでもコマンドは有効です。その動作は、START OBSERVINGおよびSTOP OBSERVINGがオブザーバ構成ファイルに定義されているすべての構成に対して動作するのと同様です。

  • SET MASTEROBSERVER TO — オブザーバ構成ファイルを手動で変更できます。

関連項目:

ブローカ構成へのアクセスに必要な資格証明

管理対象のすべてのブローカ構成用の資格証明は、Oracleウォレットを使用して保存する必要があります。Data Guard Brokerでは資格証明を管理または保存しません。オブザーバ構成ファイルに指定されている接続識別子を使用して、ブローカ構成用の資格証明をOracleウォレットから探します。資格証明が取得できない場合、試行されたコマンドは失敗します(ただし、資格証明が取得されなかったブローカ構成に対してのみ)。

例6-2 オブザーバ構成ファイルの例

オブザーバ構成ファイルの例を次に示します。

# is the comment sign in this file
BROKER_CONFIGS = ( 
 #Broker configuration 'SALES'; the connect ID is 'SALES_P'
 (CONFIG = (NAME=SALES)
           (CONNECT_ID=SALES_P)
           (CONFIG_HOME= ORACLE_HOME/LOG/)) 
 #Broker configuration 'HR'; the connect ID is 'HR_P'
 (CONFIG = (NAME=HR)
           (CONNECT_ID=HR_P) 
           (CONFIG_HOME= ORACLE_HOME/LOG/))
 #Broker configuration 'CUSTOMER'; The connect ID is 'CUSTOMER_P'
 (CONFIG = (NAME =CUSTOMER)
                 (CONNECT_ID=CUSTOMER_P)
                 (CONFIG_HOME= ORACLE_HOME/LOG1/))
            )
# The portion 'CONFIG_GROUP' lists definitions of 
# all broker configuration groups
CONFIG_GROUPS= ( 
 # Configuration 'GRP_A' includes 'SALES' and 'HR'
 (GROUP = (NAME=GRP_A)
                (CONFIG_LIST= 
                   (NAME=SALES)
                   (NAME=HR)))
 # Configuration 'GRP_B' includes 'SALES' and 'CUSTOMER'
 (GROUP = (NAME=GRP_B)
          (CONFIG_LIST= 
            (NAME=SALES)
            (NAME=CUSTOMER)))
)

ブローカ構成SALESは、3つのデータベース(Boston、ChicagoおよびDallas)とCONNECT_IDのSALES_Pで構成されているため、SALES_P接続識別子は、構成内のすべてのデータベースのすべてのインスタンスに接続できるように定義されている必要があります。ConfigurationWideServiceName構成プロパティを使用すると、この接続識別子の設定を簡素できます。Data Guard Brokerは、各インスタンスが作成され、そのインスタンスのブローカ管理が開始されると、このサービスをインスタンスに公開します。 

SALES_P = (DESCRIPTION =
                (ADDRESS_LIST =
                    (ADDRESS=(PROTOCOL=TCP)(HOST=boston-cluster)(PORT = 1521))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=chicago-cluster)(PORT = 1521))
                    (ADDRESS=(PROTOCOL=TCP)(HOST=dallas-cluster)(PORT = 1521)))
                (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=cfgSvc.us.example.com)))

オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている場合の環境へのパッチ適用

オブザーバが実行中でファスト・スタート・フェイルオーバーが有効化されている環境にパッチを適用する場合は、パッチを適用する前に次のステップを実行してください。

  1. DGMGRL STOP OBSERVERコマンドを使用してオブザーバを停止します。構成に対して複数のオブザーバが起動されている場合は、環境にパッチを適用するオブザーバの名前を必ず指定してください(STOP OBSERVER observer-name)。STOP OBSERVERコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。

  2. DGMGRL DISABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを無効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があることに注意してください。

    ノート:

    パッチを適用する環境で動作しているのはバックアップ・オブザーバのみでマスター・オブザーバがない場合、ファスト・スタート・フェイルオーバーを無効化する必要はありません。

すべてのデータベースにパッチが正常に適用された後、次のステップに従ってファスト・スタート・フェイルオーバーを有効化しオブザーバを起動してください。

  1. DGMGRL ENABLE FAST_START FAILOVERコマンドを使用してファスト・スタート・フェイルオーバーを有効化します。このコマンドを正常に実行するには、プライマリとターゲット・スタンバイの接続が確立されている必要があります。
  2. DGMGRL START OBSERVERコマンドを使用してオブザーバを起動します。構成に複数のオブザーバがある場合は、環境にパッチが適用されたオブザーバの名前を必ず指定してください(START OBSERVER observer-name)。

ブローカ構成に含まれる元のプライマリ・データベースの回復

回復により、ブローカ構成に対する高可用性がリストアされるため、新規プライマリ・データベースに障害が発生した場合に、別のファスト・スタート・フェイルオーバーが実行されます。

FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、プライマリ・データベースがクラッシュするか、マスター・オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われたことが原因でファスト・スタート・フェイルオーバーが開始された場合、マスター・オブザーバは元のプライマリ・データベースのスタンバイ・データベースとしての回復を自動的に試行します。回復されたデータベースは、新規プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲットとして機能し、後続のファスト・スタート・フェイルオーバーが可能になります。新規スタンバイ・データベースは、新規プライマリ・データベースからのREDOデータの受信を開始した時点で、フェイルオーバーの実行可能なターゲットとなります。

マスター・オブザーバによる元のプライマリ・データベースの自動回復を可能にするには、データベースを起動およびマウントする必要があります。ファスト・スタート・フェイルオーバーが有効化されていると、どのような場合もオープンできません。ブローカは、データベースを新しいプライマリ・データベースのスタンバイ・データベース(元のスタンバイと同じタイプ)として回復します。

元のプライマリ・データベースが自動的に回復されない場合、DGMGRLのREINSTATEコマンドまたはCloud Controlを使用して手動で回復できます。手動回復の段階的なステップは、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

要件

回復がサポートされるのは、ブローカ構成でフェイルオーバーを実行した後に限られます。また、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方でフラッシュバック・データベースを有効化する必要があります。

すべてのファスト・スタート・フェイルオーバーおよび回復の要件の詳細は、「ファスト・スタート・フェイルオーバーを有効化するための前提条件」を参照してください。

回復に関する制限事項

このリストでは、ブローカが以前のプライマリ・データベースを自動的に回復できない条件を説明します。

  • ユーザーが構成可能な条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションで要求した場合

  • FastStartFailoverAutoReinstateがFALSEに設定されている場合

  • ファスト・スタート・フェイルオーバーの完了後、元のプライマリ・データベースが再起動されるまでに別のフェイルオーバーまたはスイッチオーバーが発生した場合

  • ファスト・スタート・フェイルオーバーが無効化されている場合

  • マスター・オブザーバが元のプライマリ・データベースに接続できない場合

  • 元のプライマリ・データベースが新規プライマリ・データベースに接続できない場合

  • 元のプライマリ・データベースおよび新規プライマリ・データベースが、同じファスト・スタート・フェイルオーバー環境内で構成されていない場合

  • ファスト・スタート・フェイルオーバーが無効化されているとき、手動フェイルオーバーによって元のプライマリ・データベースが無効化された場合

    ノート:

    スイッチオーバー、手動フェイルオーバーまたはファスト・スタート・フェイルオーバーの実行時にスタンバイ・データベースを無効した場合は、自動的に回復されません。

自動回復に失敗した場合、ブローカによりエラーがログに記録され、元のプライマリ・データベースはマウントされた状態のままとなります。この時点で、次のいずれかを実行できます。

失敗した回復のブローカによる処理方法

回復操作(自動または手動)が進行中のときに障害が発生した場合、ブローカにより、ブローカ構成ファイルおよびブローカ・ログ・ファイルに、適切な情報が記録されます。

元のプライマリ・データベースは無効化されます。進行中の障害のほとんどは再起動できません(プライマリ・データベースにおけるアーカイブREDOログ・ファイルの破損など)。データベースをスタンバイ・データベースとして手動で再作成してから再有効化する必要があります。

関連項目:

「無効化されたデータベースの再作成および再有効化の方法」

ファスト・スタート・フェイルオーバー環境でのデータベースの停止

必要に応じて、ファスト・スタート・フェイルオーバー環境のプライマリ・データベースまたはターゲット・スタンバイ・データベースを停止できます。

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

  1. オブザーバを停止し、プライマリ・データベースおよびターゲット・スタンバイ・データベースの両方について、V$FS_FAILOVER_OBSERVERS固定ビューのすべての行のREGISTERED列に値「NO」が含まれるまで待機します。こうすると、プライマリ・データベースの停止中に、ファスト・スタート・フェイルオーバーは実行されません。
  2. DGMGRLのSHUTDOWNコマンドまたはSQL*PlusのSHUTDOWN文を使用して、プライマリ・データベースおよびターゲット・スタンバイ・データベースを停止します。

データベースを再起動する場合、任意の順序で実行できます。両方のデータベースを再起動したら、オブザーバを再起動できます。

その他のスタンバイ・データベースは、いつでも、任意の順序で、ファスト・スタート・フェイルオーバーに影響なくシャットダウンできます。