4 ブローカ構成のメンバーの管理

ブローカ構成メンバーを管理する方法と、構成の各メンバーの状態を監視する方法を学習します。

• ブローカ構成メンバーの管理

• ブローカ構成メンバーの状態管理

• データベース・プロパティの管理

• REDO転送サービスの管理

• リカバリ・アプライアンスに対応したREDO転送サービスの管理

• ログ適用サービスの管理

• データ保護モードの管理

• 遠隔同期インスタンスの管理

• ファスト・スタート・フェイルオーバーの管理

• データベース変換の管理

• データベース・ステータス

4.1 ブローカ構成メンバーの管理

ブローカは構成ファイルの情報を使用して、構成の各メンバーの状態を管理および監視します。

ブローカでは、ブローカ構成に含まれる様々なタイプのメンバーが区別されます。各タイプのメンバーは、そのタイプのメンバーに適切な、状態とプロパティの組合せを持っています。

4.2 ブローカ構成メンバーの状態管理

構成の各メンバーは、様々な状態を示している可能性があり、構成が有効化されている場合は、その状態によってOracle Data Guardの動作が決まります。

次の表に、様々な状態を示します。

スナップショット・スタンバイ・データベースは、状態を持たず、REDOデータを受信するのみであるため、この表にはリストされていません。

状態がないため、遠隔同期インスタンスもこの表に含まれません。それはREDOを受け取って、スタンバイ・データベースに転送するだけです。

Zero Data Loss Recovery Applianceは状態を持たないため、この表には含まれていません。

表4-1 データベースの状態と説明

データベース・ロール	状態名	説明
プライマリ	TRANSPORT-ON	REDO転送サービスは、プライマリ・データベースが読取り/書込みアクセス用にオープンされるとREDOデータをスタンバイ・データベースまたは遠隔同期インスタンスに転送するように設定されます。 これがOracle RACデータベースの場合は、読取り/書込みモードでオープンされているすべてのインスタンスでREDO転送サービスが実行されます。 これは、プライマリ・データベースが初めて有効化されるときのデフォルト状態です。
プライマリ	TRANSPORT-OFF	プライマリ・データベースのREDO転送サービスが停止します。 これがOracle RACデータベースの場合は、どのインスタンスでもREDO転送サービスが実行されません。
フィジカル・スタンバイ	APPLY-ON	フィジカル・スタンバイ・データベースのREDO Applyが開始します。 スタンバイ・データベースがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでのみREDO Applyを起動します。このインスタンスに障害が発生すると、ブローカは、マウントされているか読取り専用でオープンされている他のインスタンスを自動的に選択します。この新規インスタンスが適用インスタンスとなります。 Oracle Database 12cリリース2 (12.2.0.1)では、稼働中のアクティブな各フィジカル・スタンバイ・インスタンスでREDO Applyが実行されるように設定できます。複数のインスタンス上でREDO Applyを実行するようにデータベースがすでに設定されている場合は、Data Guard BrokerのプロパティApplyInstancesを使用して、Oracle RACフィジカル・スタンバイ・データベース上でREDO Applyに関係するインスタンスの数を制限できます。 APPLY-ONは、フィジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。 Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。
フィジカル・スタンバイ	APPLY-OFF	REDO Applyが停止します。 これがOracle RACデータベースの場合は、データベースの状態をAPPLY-ONに変更するまで、インスタンスでは適用サービスが実行されません。
ロジカル・スタンバイ	APPLY-ON	ロジカル・スタンバイ・データベースがオープンされている場合、ロジカル・スタンバイのデータベース・ガードがオンであれば、そのデータベースでSQL Applyが起動します。 これがOracle RACデータベースの場合は、単一のインスタンス(適用インスタンス)でSQL Applyが実行されます。このインスタンスに障害が発生すると、ブローカは自動的に他のオープン・インスタンスを選択します。この新規インスタンスが適用インスタンスとなります。 これは、ロジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。
ロジカル・スタンバイ	APPLY-OFF	SQL Applyは実行されません。ロジカル・スタンバイのデータベース・ガードはオンです。 これがOracle RACデータベースの場合は、状態をAPPLY-ONに変更するまで、インスタンスではSQL Applyが実行されません。

4.2.1 データベースの状態遷移

DGMGRLのEDIT DATABASEコマンドを使用して、データベースの状態を明示的に変更できます。

たとえば、次の例に示すEDIT DATABASEコマンドは、North_Salesデータベースの状態をTRANSPORT-OFFに変更します。

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
Succeeded.

次の各項では、プライマリ・データベースおよびスタンバイ・データベースにおいて考えられる状態遷移について詳細に説明します。

プライマリ・データベースの状態遷移

プライマリ・データベースをTRANSPORT-ON状態に遷移する際に、ブローカは構成メンバーのREDO転送関連プロパティと、プライマリ・データベースのRedoRoutesプロパティを使用して、REDO転送サービスを設定します。REDO転送サービスを設定するために、プライマリ・データベースのLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータと全データベース(プライマリまたはスタンバイ)および遠隔同期インスタンスのLOG_ARCHIVE_CONFIG初期化パラメータが設定されます。必要な場合は、データベースのデータ保護モードもブローカ構成ファイルに記録されている保護モードに合せて設定されます。最後に、データベースがオープンされている場合、各スレッドのログが切り替えられ、REDO転送サービスが開始されます。

プライマリ・データベースをTRANSPORT-OFF状態に遷移する際、ブローカはLOG_ARCHIVE_DEST_STATE_n初期化パラメータをリセットし、すべての管理対象スタンバイへのREDO転送サービスをオフにします。ブローカ管理のすべてのスタンバイへのREDOデータの転送が停止されます。ログ・ファイルは、引き続きプライマリ・データベース側でアーカイブされます。

プライマリ・データベースがOracle RACデータベースの場合、ブローカはすべてのプライマリ・インスタンス上で、まったく同じ設定を使用してREDO転送サービスを構成します。

フィジカル・スタンバイ・データベースの状態遷移

フィジカル・スタンバイ・データベースをAPPLY-ON状態に遷移する際に、ブローカはREDO Apply関連プロパティで指定されたオプションを使用してREDO Applyを起動します。スタンバイがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでREDO Applyを起動します。

Oracle Database 12cリリース2 (12.2.0.1)では、稼働中の複数のアクティブなフィジカル・スタンバイ・インスタンスでREDO Applyが実行されるように設定できます。(この機能を使用するには、スタンバイ・データベースにOracle Active Data Guardオプションのライセンスが必要です。)複数のインスタンス上でREDO Applyを実行するようにデータベースがすでに設定されている場合は、Data Guard BrokerのプロパティApplyInstancesを使用して、Oracle RACフィジカル・スタンバイ・データベース上でREDO Applyに関係するインスタンスの数を制限できます。

Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。

他のインスタンスがオープンされている場合、REDO Applyを開始する前に適用インスタンスをオープンする必要があります。

APPLY-OFF状態に遷移すると、ブローカはREDO Applyを停止します。

ノート:

フィジカル・スタンバイ上のOracle RAC One Nodeでオンライン・データベース再配置を実行する場合、新しいインスタンスは現在実行中のインスタンスと同じモードで開始されます。そのため、データベースが元のインスタンスにマウントされている場合、そのデータベースは新しいインスタンスにマウントされることになります。同様に、データベースが元のインスタンスでオープンしている場合、そのデータベースは新しいインスタンスでオープンされることになります。これにより、新しいインスタンスは、データベースのOracle Clusterwareで記録された開始オプションと一致しないモードで開始される可能性があります。

ロジカル・スタンバイ・データベースの状態遷移

ロジカル・スタンバイ・データベースがAPPLY-ON状態に遷移すると、ブローカは、データベースがオープンされるまで待機し、データベース・ガードを有効化してロジカル・スタンバイ・データベース内の表への変更を防ぎ、ログ適用関連プロパティで指定されたオプションを使用してSQL Applyを起動します。ロジカル・スタンバイ・データベースがOracle RACデータベースの場合、ブローカは単一のスタンバイ・インスタンス(適用インスタンス)でSQL Applyを起動します。

APPLY-OFF状態に遷移すると、ブローカはSQL Applyを停止します。

関連項目:

• SQL Applyの管理の詳細は、「ログ適用サービスの管理」を参照してください

• REDO転送サービスの管理の詳細およびREDO転送関連プロパティの一覧は、REDO転送サービスの管理を参照してください

• データベース・ガードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

• EDIT DATABASEコマンドの詳細は、Oracle Data Guardコマンドライン・インタフェース・リファレンスを参照してください。

4.3 データベース・プロパティの管理

データベース・プロパティには、監視可能なタイプと構成可能なタイプがあります。

どちらのタイプのプロパティも、データベース単位の有効範囲を持つプロパティとインスタンス固有の有効範囲を持つプロパティとしてさらに分類できます。

• 監視可能なプロパティの値は、関連データベースが有効である場合にのみ表示できます。

  監視可能なプロパティを使用するとデータベース関連のランタイム情報を表示できますが、このタイプのプロパティの値は変更できません。

• 構成可能なプロパティの値は、表示して動的に更新できます。

  構成可能なプロパティは、ブローカの操作や構成に影響を与えます。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して変更できます。プロパティは、構成とそのメンバーが有効か無効かに関係なく編集できます。ただし、構成メンバーが無効化されている場合は、該当する構成またはメンバーを有効にするまで、新しいプロパティ値は有効になりません。

  関連項目:

  すべてのデータベース・プロパティの詳細リストは、「Oracle Data Guard Brokerのプロパティ」を参照してください

これらのプロパティを表示するには、DGMGRLのSHOWコマンドを使用するか、Cloud Controlの「プロパティの編集」ページを使用できます。例4-1では、SHOW DATABASE VERBOSEコマンドを使用して、North_Salesデータベースに関する情報を表示しています。

関連項目:

DGMGRLコマンドライン・インタフェースの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照

例4-1 SHOW DATABASE VERBOSEコマンドの使用によるプロパティの表示

SHOW DATABASE VERBOSE 'North_Sales';

Database - North_Sales

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    North_sales1

  Properties:
    DGConnectIdentifier             = 'North_Sales.example.com'
    ObserverConnectIdentifier       = ''
    FastStartFailoverTarget         = ''
    PreferredObserverHosts          = ''
    LogShipping                     = 'ON'
    RedoRoutes                      = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    ReopenSecs                      = '30'
    NetTimeout                      = '300'
    RedoCompression                 = 'DISABLE'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '0'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = ''
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '0'
    LogArchiveMinSucceedDest        = '0'
    DataGuardSyncLatency            = '0'
    LogArchiveTrace                 = 255
    LogArchiveFormat                = 'db1r_%d_%t_%s_%R.arc'
    DbFileNameConvert               = 'dbs/cdb2_, dbs/cdb1_, dbs/bt, dbs/t, dbs/cdb4_, dbs/cdb1_, dbs/dt, dbs/t'
    LogFileNameConvert              = 'dbs/cdb2_, dbs/cdb1_, dbs/bt, dbs/t, dbs/cdb4_, dbs/cdb1_, dbs/dt, dbs/t'
    ArchiveLocation                 = ''
    AlternateLocation               = ''
    StandbyArchiveLocation          = ''
    StandbyAlternateLocation        = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    LogXptStatus                    = '(monitor)'
    SendQEntries                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    HostName                        = ’North_Sales.example.com'
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=North_Sales.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)
(INSTANCE_NAME=north_sales1)(SERVER=DEDICATED)))'
    TopWaitEvents                   = '(monitor)'
    SidName                         = '(monitor)’

  Log file locations:
    Alert log               : /dev/oracle/log/diag/rdbms/North_Sales/north1/trace/alert_north1.log
    Data Guard Broker log   : /dev/oracle/log/diag/rdbms/North_Sales/north1/trace/drcnorth1.log

Database Status:
SUCCESS

4.3.1 監視可能な(読取り専用)プロパティ

監視可能なプロパティを使用すると構成メンバー関連の情報を表示できますが、プロパティの値は変更できません。

監視可能なプロパティは、ブローカ構成内の問題を診断しようとするときに、非常に役立つ場合があります。たとえば、監視可能なプロパティInconsistentLogXptPropsを表示して、REDO転送サービス・プロパティの値に矛盾がある(ブローカ構成ファイルと、データベースで現在使用されている実際の値との間に一貫性がない)箇所を判断できます。

DGMGRLのSHOW DATABASE VERBOSEコマンドを使用すると、すべての監視可能なプロパティを表示できます。特定のプロパティの詳細を知るには、SHOW DATABASEコマンドを使用します。たとえば、次にInconsistentLogXptPropsプロパティの使用例を示します。

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';

INCONSISTENT LOG TRANSPORT PROPERTIES

 INSTANCE_NAME     STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE 
  south_sales1      South_Sales     ReopenSecs           600           300

Cloud Controlでは、これらのプロパティから取得された情報が「プロパティの編集」ページに表示されます。

4.3.2 構成可能(変更可能)なプロパティ

構成可能なプロパティは、データベースまたは遠隔同期インスタンスの操作や構成に影響を与えます。

DGMGRLまたはCloud Controlを使用してプライマリ・データベースを作成し、既存のスタンバイ・データベースおよび遠隔同期インスタンスを新しいブローカ構成にインポートすると、データベース・インスタンスまたは遠隔同期インスタンスの設定から、最初にプロパティ値がインポートされます。

多くのプロパティ値は、構成メンバーが無効の場合でも有効の場合でも更新できます。新しいメンバーが構成に追加されると、ブローカはそのメンバーに接続して、メンバーのプロパティの初期値を現在のメンバー設定からインポートします。次に例を示します。

DGMGRL> SHOW DATABASE 'North_Sales' LogXptMode;
  LogXptMode = ASYNC

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY LogXptMode='SYNC';
  Property "LogXptMode" updated

DGMGRL> SHOW DATABASE 'North_Sales' LogXptMode;
  LogXptMode = SYNC

構成が有効な場合、ブローカは、REDO転送に関連するプロパティについて、ブローカ構成ファイル内のメンバーのプロパティの値と、メンバーで使用されている値の一貫性を維持します。ブローカは、構成ファイルの初期化パラメータに関連するプロパティの値を維持しなくなりました。一貫性の維持に関しては問題ありません。ブローカはこれらのプロパティの値を維持しなくなりましたが、ブローカCLIを使用してこれらのプロパティの値を更新および調査することはできます。ユーザー・アクションにより、システム・グローバル領域(SGA)のパラメータ値がサーバー・パラメータ・ファイルのパラメータ値と異なることがあります。これは非一貫性としてフラグ付けされず、次回データベースを再起動するとサーバー・パラメータ・ファイルの値が有効になります。これらのプロパティを変更するには、指定したデータベースにアクセスできる必要があります。

ノート:

プロパティの値は構成が無効な場合にも変更できますが、変更結果は構成が有効化されるまで構成メンバーに対して有効になりません。また、一部のプロパティ値は無効な状態でのみ変更可能なことに注意してください。

4.3.2.1 ブローカの構成可能なプロパティのデフォルト値へのリセット

ブローカの大部分の構成可能なプロパティにはデフォルト値がありますが、異なる値を指定してデフォルト値を上書きできます。

Oracle Database 12cリリース1 (12.1)より前のリリースでは、一度デフォルト値を変更すると、プロパティを後で以前のデフォルト値に設定しなおした場合も、ユーザーが設定した値とみなされました。

Oracle Database 12cリリース1 (12.1)では、プロパティのデフォルト値が回復されたことを認識し、ユーザー設定の値とはみなさなくなりました。これはアップグレード・シナリオで好都合です。これにより、プロパティのデフォルト値がリリースによって異なっても、アップグレードの完了後、新しいデフォルト値が自動的に有効になります。ユーザー設定とみなされる値は、自動的にアップグレードされません。

デフォルト値をリセットするために実際のデフォルト値を知っている必要はありません。デフォルト値は、構成、構成メンバーまたはインスタンスのレベルでリセットすることができます。

関連項目:

• 「EDIT CONFIGURATION RESET (プロパティ)」

• 「EDIT DATABASE RESET (プロパティ)」

• 「EDIT FAR_SYNC RESET (プロパティ)」

• EDIT RECOVERY_APPLIANCE RESET (プロパティ)

4.4 REDO転送サービスの管理

REDO転送サービスを管理するには、各構成メンバーに構成可能なプロパティを指定します。

次のようなプロパティを指定します。

• DGConnectIdentifier

• StandbyAlternateLocation

• Binding

• Encryption (このプロパティはリカバリ・アプライアンスでのみ設定可能です)

• LogShipping

• LogXptMode

• MaxFailure

• NetTimeout

• RedoCompression

• RedoRoutes

• ReopenSecs

• StandbyArchiveLocation

これらのプロパティを使用して、スタンバイ・データベースに対するREDO転送サービスのブローカによる設定方法を指定できます。LOG_ARCHIVE_DEST_n初期化パラメータの設定など、実際のREDO転送の設定(StandbyArchiveLocationプロパティを除く)は、ブローカによりプライマリ・データベース上で実行されます。プロパティの変更によりLOG_ARCHIVE_DEST_n初期化パラメータの属性変更が必要な場合、ブローカは各スレッド上でログを強制的に切り替えます。これにより、プライマリ・データベースでは新規設定が即時に使用されます。

また、スタンバイ・データベースに切り替える準備として、これらのプロパティをプライマリ・データベース上で事前に設定する必要があります。

4.4.1 REDO転送の設定

REDOデータは、Oracle Netを使用してスタンバイ・データベースに転送されます。

Oracle Netサービス名は、LOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性で指定され、スタンバイ・データベースへのREDOデータの転送に使用されます。Oracle Netサービス名は、スタンバイ・データベースへの接続に必要な情報が記述された接続記述子に変換されます。

SERVICE属性は、データベース・プロパティDGConnectIdentifierを使用して設定または変更できます。DGConnectIdentifierプロパティは、構成にデータベースを初めて追加するときに設定されます。このプロパティの初期値は、ADD DATABASEコマンドのオプションのCONNECT IDENTIFIER IS句に指定した接続識別子です。

DGConnectIdentifierプロパティの値は、FAL_SERVER初期化パラメータの設定にも使用されます。いずれかのデータベースのDGConnectIdentifierプロパティが変更されると、対応するLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性も変更されます。また、構成内で有効化されたすべてのスタンバイ・データベースで、FAL_SERVER初期化パラメータが更新されます。

4.4.2 データ保護モードに対応したREDO転送サービスの管理

構成全体の保護モードの一部として、REDO転送サービスも、選択したデータ保護モードに対して正しく設定されていることを確認する必要があります。

ブローカによるデータ保護モードの処理方法については、「データ保護モードの管理」で説明します。

REDO転送サービスをSYNC、ASYNCまたはFASTSYNCモードに設定するには、LogXptModeまたはRedoRoutesデータベース・プロパティを使用します。

次のREDO転送モードがサポートされています。

SYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルは、最大保護モードまたは最大可用性モードのいずれかで動作している構成に必要です。このREDO転送サービスでは、プライマリ・データベースに対して最高レベルのデータ保護が可能ですが、パフォーマンスへの影響も大きくなる可能性があります。

ASYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNCおよびNOAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルでは、プライマリ・データベースに対して適度なレベルのデータ保護が可能になり、パフォーマンスへの影響も小さくなります。

FASTSYNC

このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびNOAFFIRM属性を使用して構成します。このモードは、最大可用性保護モードでのみ利用できます。

4.4.3 高度なREDO転送設定

RedoRoutesプロパティを使用すると、デフォルトの動作(プライマリ・データベースがそのREDOを構成内にあるすべての可能なREDO転送先に送信する)を上書きできます。

デフォルト以外のREDO転送トポロジの例としては、たとえば、フィジカル・スタンバイまたは遠隔同期インスタンスが、プライマリ・データベースから受け取ったREDOを1つ以上の接続先に転送するものや、指定された接続先に対して使用されるREDO転送モードが、どのデータベースがプライマリ・ロールであるかによって異なるものなどがあります。

関連項目:

• RedoRoutes (RedoRoutesプロパティを使用する場合のREDOルーティング・ルールの詳細)

例4-2 リアルタイム・カスケードに対するRedoRoutesプロパティの使用

プライマリ・データベース(North_Sales)と2つのフィジカル・スタンバイ・データベース(Local_SalesとRemote_Sales)がある構成を考えます。Local_Salesデータベースは、高可用性のために、プライマリと同じデータセンターに置かれています。Remote_Salesデータベースは、障害回復目的で、リモート・データセンターに置かれています。プライマリから両方のデータベースにREDOを送信するかわりに、RedoRoutesプロパティを使用して、ローカルのフィジカル・スタンバイ・データベースが、North_Salesからリモートのフィジカル・スタンバイ・データベース(Remote_Sales)にREDOを転送するようにリアルタイム・カスケードを構成することができます。そのためには、RedoRoutesプロパティを次のように設定する必要があります。

• North_Salesデータベースでは、North_Salesがプライマリ・ロールである場合、同期転送モードを使用してLocal_SalesデータベースにREDOを送信するように、RedoRoutesプロパティを指定する必要があります。このルールにより、プライマリがRemote_Salesデータベースに直接REDOデータを送信することがなくなります。

• Local_Salesデータベースでは、North_Salesがプライマリ・ロールの場合、Local_Salesが、North_Salesから受け取ったREDOをRemote_Salesに転送するように、RedoRoutesプロパティを指定する必要があります。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : Local_Sales SYNC)';
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';

実行時のRedoRoutes構成を表示するには、SHOW CONFIGURATIONコマンドを使用します。次に例を示します。

DGMGRL> SHOW CONFIGURATION;
 
Configuration - Sales_Configuration
 
  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales  - Physical standby database (receiving current redo)
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

Remote_Sales接続先のREDOルート・ルールで、ASYNCREDO転送属性が明示的に指定されることで、その接続先へのREDOのリアルタイム・カスケーディングが有効にされたことに注意してください。(リアルタイム・カスケードにはOracle Active Data Guardオプションのライセンスが必要です。)

REDOのリアルタイム・カスケーディングを無効にするには、ASYNCREDO転送属性を指定しないでください。次に例を示します。

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales)';

例4-3 リモート代替宛先に対するRedoRoutesプロパティの使用

RedoRoutesプロパティを使用すると、端末メンバーがREDOデータの受信元のメンバーに障害が発生してもREDOデータを受信できるように、リモート代替宛先を設定することもできます。前述の例を使用すると、プライマリ・データベースとしてNorth_Salesを使用し、スタンバイ・データベースLocal_Salesに障害が発生したときにREDOデータを直接Remote_Salesに送信できます。PRIORITY属性を使用して、Local_Salesの障害が解決された時点でRemote_SalesへのREDOの送信を再開できるように設定することもできます。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : ( Local_Sales ASYNC PRIORITY=1, Remote_Sales ASYNC PRIORITY=2 ))';
Property "RedoRoutes" updated

DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';
Property "RedoRoutes" updated

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
  North_Sales    - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales - Physical standby database
Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

RedoRoutes構成全部を表示するには、SHOW CONFIGURATION VERBOSEコマンドを使用します。次に例を示します。

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
    North_Sales - Primary database
      Local_Sales - Physical standby database
        Remote_Sales - Physical standby database
      Remote_Sales - Physical standby database (alternate of Local_Sales)

  Properties:
    FastStartFailoverThreshold      = '180'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '300'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    ConfigurationWideServiceName    = 'c0_CFG'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

4.4.4 REDO転送サービスのオン/オフの切替え

REDO転送サービスのオンとオフを切り替えるには、プライマリ・データベースの状態を設定します。

プライマリ・データベースの状態をTRANSPORT-ONに設定するとプライマリ・データベースでREDO転送サービスが起動し、TRANSPORT-OFFに設定するとプライマリ・データベースのREDO転送サービスが停止します。

ノート:

すべてのスタンバイ・データベースへのREDO転送サービスをオフにしないことをお薦めします。オフにすると、プライマリ・データベースに障害が発生した場合にデータが消失する危険性があります。

スタンバイ・データベースへのREDO転送サービスのオンとオフを個別に切り替えるには、対象のスタンバイ・データベースにデータベース・プロパティLogShippingを使用します。LogShippingプロパティは、値ONおよびOFFを受け入れます。スタンバイ・データベースに対してLogShippingプロパティをOFFに設定すると、そのスタンバイ・データベースへのREDO転送サービスはオフになりますが、他のデータベースへのREDO転送サービスは影響を受けません。LogShippingをONに設定すると、スタンバイ・データベースへのREDO転送サービスをオンに戻せます。

プライマリ・データベースの状態の設定とLogShippingプロパティの設定の関係は、次のとおりです。

• プライマリ・データベースの状態がTRANSPORT-OFFに設定されている場合、各スタンバイ・データベースの個々のLogShippingプロパティ値に関係なく、すべてのスタンバイ・データベースへのREDO転送サービスが停止します。

• プライマリ・データベースの状態がTRANSPORT-ONに設定されている場合は、各スタンバイ・データベースへのREDO転送サービスは、それぞれのデータベースのLogShippingプロパティにより決定されます。

例4-4および例4-5に、REDO転送サービスをオフにする方法を2つの使用例により示します。

例4-4 すべてのスタンバイ・データベースへのREDO転送サービスをオフにする場合

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
DGMGRL> SHOW DATABASE 'North_Sales';
 
Database - North_Sales
 
  Role:            PRIMARY
  Intended State:  TRANSPORT-OFF
  Instance(s):
    north_sales1
 
Database Status:
SUCCESS

例4-5 特定のスタンバイ・データベースへのREDO転送サービスをオフにする場合

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated

DGMGRL> SHOW DATABASE 'South_Sales' 'LogShipping';
  LogShipping = 'OFF'

4.4.5 アーカイブREDOログ・ファイルの位置の指定

ブローカの構成可能なプロパティを使用して、アーカイブ・スタンバイREDOログ・ファイルとアーカイブ・オンラインREDOログ・ファイルの両方を格納する位置を設定できます。

オンラインREDOログ・ファイルの場合、プライマリ、ロジカルまたはスナップショット・スタンバイ・データベースでArchiveLocationおよびAlternateLocationプロパティを使用します。

スタンバイREDOログ・ファイルの場合、スタンバイ・データベースでStandbyArchiveLocationおよびStandbyAlternateLocationプロパティを使用します。StandbyArchiveLocationが設定されていない場合、ArchiveLocationまたはAlternateLocationは、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルの両方のアーカイブ場所を指定します。StandbyArchiveLocationが設定されている場合、ArchiveLocationおよびAlternateLocationはオンラインREDOログ・ファイルのアーカイブ場所を指定します。

StandbyArchiveLocationプロパティは、アーカイブREDOログ・ファイルを格納する位置を指定します。ブローカが使用するのは、プライマリ・データベースから受け取ったアーカイブREDOログ・ファイルのみを格納する位置です。データベースがプライマリ・データベース、ロジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースのいずれかであるときに、ローカルで生成されたアーカイブREDOログ・ファイルの場合は、ArchiveLocationプロパティを指定する必要があります。ブローカでは、StandbyArchiveLocationおよびArchiveLocationプロパティの値をローカルに生成されたログ用に設定した位置と同じ位置に設定できます。この場合、ブローカによりアーカイブ先のVALID_FOR属性が適切に設定されるため、プライマリ・データベースから受け取るアーカイブREDOログ・ファイルとローカルに生成されるアーカイブREDOログ・ファイルの両方に同じ位置を使用できます。場所がオンラインREDOログ・ファイルとスタンバイREDOログ・ファイルの両方に使用される場合は、ArchiveLocationプロパティを共有の場所に構成し、StandbyArchiveLocationプロパティを空のままにする必要があります。

StandbyAlternateLocationおよびAlternateLocationプロパティを使用して、アーカイブREDOログ・ファイルを格納する別の位置を設定することもできます。これらのプロパティによって指定された代替の位置は、元のアーカイブの位置(StandbyArchiveLocationまたはArchivelocationで指定される)が失敗した場合にアーカイブREDOログ・ファイルが格納される場所です。ブローカは、LOG_ARCHIVE_DEST_n初期化パラメータのALTERNATE属性を使用して、代替位置を正しく設定します。

ノート:

スタンバイ上のデータベース・リカバリ領域をアーカイブREDOログ・ファイルの格納に使用できます。この場合、StandbyArchiveLocationプロパティまたはArchiveLocationプロパティの値をUSE_DB_RECOVERY_FILE_DESTに設定できます。

データベースのリカバリ領域を使用していない場合、ロジカル・スタンバイ・データベースでArchiveLocationプロパティをStandbyArchiveLocationプロパティの値と異なる値にしておくことをお薦めします。

例4-6 スタンバイREDOログ・ファイルとオンラインREDOログ・ファイルに同じアーカイブ場所を使用する

次の例では、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルに同じアーカイブの場所を使用します。

ArchiveLocation='/archfs/arch'

例4-7 アーカイブ・スタンバイおよびオンラインREDOログ・ファイルの代替の場所の指定

次の例では、オンラインREDOログ・ファイルとスタンバイREDOログ・ファイルに同じアーカイブの場所を使用します。AlternateLocationプロパティを構成すると、ArchiveLocationプロパティで指定された場所が使用できない場合に、スタンバイREDOログ・ファイルを格納するために共有の代替の場所を使用できます。

ArchiveLocation='/archfs/arch'
AlternateLocation='/archfs/alt'

例4-8 オンラインREDOログ・ファイルおよびスタンバイREDOログ・ファイルの個別のアーカイブ場所の指定

この例では、スタンバイREDOログ・ファイルおよびオンラインREDOログ・ファイルの個別のアーカイブ場所を構成します。また、オンラインREDOログ・ファイルおよびスタンバイREDOログ・ファイルの代替のアーカイブ場所を構成するには、AlternateLocationおよびStandbyAlternateLocationプロパティをそれぞれ使用します

ArchiveLocation='/archfs/arch/online'
AlternateLocation='/archfs/alt/online'
StandbyArchiveLocation='/archfs/arch/standby'
StandbyAlternateLocation='/archfs/alt/standby'

4.4.6 その他のREDO転送設定

データベース・プロパティを使用して、REDO転送サービスのパフォーマンスをチューニングし、REDO転送サービスの障害ポリシーを設定できます。

使用されるプロパティは、Binding、MaxFailure、NetTimeout、RedoCompressionおよびReopenSecsです。これらのプロパティは、LOG_ARCHIVE_DEST_n初期化パラメータの属性に対応します。

関連項目:

これらのデータベース・プロパティの詳細は「Oracle Data Guard Brokerのプロパティ」を参照

4.4.7 Oracle RACデータベース環境でのREDO転送サービス

プライマリ・データベースがOracle RACデータベースの場合、ブローカは各プライマリ・データベース・インスタンス上のREDO転送サービスが同一に設定されていることを確認します。

各インスタンスのリモート接続先は同じで、すべてのインスタンスで、各リモート接続先には同じREDO転送サービス、パフォーマンス関連設定、オンラインREDOログのローカル・アーカイブなどが設定されます。インスタンスの設定が異なる場合、ブローカはそのインスタンスに関して健全性チェックの警告を発行します。

REDO転送サービスに関連する設定は、ブローカ構成ファイルにプロパティとして保存されます。スタンバイ・データベース上のREDO転送関連のプロパティを更新すると、すべてのプライマリ・データベース・インスタンス上のLOG_ARCHIVE_DEST_n初期化パラメータに対しても、ブローカによって自動的に対応する変更が実行されます。プライマリ・データベース上で新規インスタンスが作成されると、ブローカは現在管理している全構成メンバーのREDO転送関連プロパティを使用して、新規インスタンス用のREDO転送サービスを設定します。新しいインスタンスがアクティビティに対して開かれた後、このインスタンスで生成されたすべてのアーカイブREDOログ・ファイルにより、構成のメンバーへの転送が開始されます。

関連項目:

LOG_ARCHIVE_DEST_n初期化パラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.4.8 転送ラグ

転送ラグは、スタンバイ・データベースまたは遠隔同期インスタンスへのREDOの転送がプライマリ・データベースでのREDOの生成からどの程度遅れているかを測定する尺度です。

スタンバイ・データベースまたは遠隔同期インスタンスで1つ以上のREDOギャップがある場合は、最初のREDOギャップの発生後にREDOは受信されなかったものとして、転送ラグが計算されます。

Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースまたは遠隔同期インスタンスごとにREDO転送ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに転送ラグが表示されます。DGMGRLクライアントでは、SHOW DATABASE出力に転送ラグが表示されます。プライマリ・データベースに対する転送ラグは表示されません。次に例を示します。

DGMGRL> show database 'South_Sales';
 
Database - South_Sales
 
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds (computed 0 seconds ago)
  Apply Lag:       0 seconds (computed 0 seconds ago)
  Apply Rate:      255.00 KByte/s
  Real Time Query: OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

Oracle Databaseリリース19c以上では、SHOW CONFIGURATION LAGコマンドによって、ブローカ構成のサマリーおよびすべてのスタンバイ・データベースの転送ラグが表示されます。

転送ラグにより、REDO転送サービスで発生する可能性のある問題を識別することができます。

構成可能なデータベース・プロパティTransportLagThresholdを設定すると、スタンバイ・データベースまたは遠隔同期インスタンスへのREDOデータの転送がプライマリ・データベース上でのREDOデータの生成より遅れる場合に健全性チェック警告を生成できます。

次のコマンドは、TransportLagThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportLagThreshold'=15;
Property TransportLagThreshold updated

さらに、構成可能なデータベース・プロパティTransportDisconnectedThresholdを設定すると、スタンバイまたは遠隔同期インスタンスがプライマリ・データベースとの間にいかなるREDO転送関連の通信も持っていないことを検出したときに健全性チェック警告を生成できます。プロパティのデフォルト値は30秒です。

次のコマンドは、TransportDisconnectedThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportDisconnectedThreshold'=15;
Property TransportDisconnectedThreshold updated

4.5 リカバリ・アプライアンスに対応したREDO転送サービスの管理

Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)に対するREDO転送サービスは、スタンバイ・データベースの場合と同じ方法で管理されます。

ブローカを使用して、構成内の任意のメンバーからリカバリ・アプライアンスへのREDO転送サービスを管理できます。たとえば、リカバリ・アプライアンスをブローカ構成に追加して有効化するには、次のステップを実行します。

1. リカバリ・アプライアンスをブローカ構成に追加します。

   DGMGRL> ADD RECOVERY_APPLIANCE EnterpriseRecoveryAppliance AS CONNECT IDENTIFIER IS
   EnterpriseRecoveryAppliance.example.com;
   Oracle Recovery Appliance "EnterpriseRecoveryAppliance" added
    
   DGMGRL> SHOW RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    Oracle Recovery Server - EnterpriseRecoveryAppliance
      Transport Lag: 0 seconds
     Redo Source: North_Sales
    
   Oracle Recovery Appliance Status:
   DISABLED
   

2. リカバリ・アプライアンスを有効にします。

   DGMGRL> ENABLE RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    
   DGMGRL> SHOW RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance';
    Oracle Recovery Server - EnterpriseRecoveryAppliance
      Transport Lag: 0 seconds
     Redo Source: North_Sales
    
   Oracle Recovery Appliance Status:
   SUCCESS
   

3. 転送ラグのしきい値を設定します。

   構成可能なデータベース・プロパティTransportLagThresholdを設定すると、リカバリ・アプライアンスへのREDOデータの転送がソース・データベース上でのREDOデータの生成より遅れる場合にヘルス・チェック警告が生成されます。このステップは省略可能ですが、転送ラグのしきい値を指定しないと、デフォルト値のゼロ(0)秒が使用されるので、転送ラグが存在しても警告は生成されません。

   次のコマンドは、TransportLagThresholdプロパティを15秒に設定します。

   DGMGRL> EDIT RECOVERY_APPLIANCE 'EnterpriseRecoveryAppliance'
   SET PROPERTY 'TransportLagThreshold'=15;
   Property TransportLagThreshold updated
   

例4-9 フィジカル・スタンバイからリカバリ・アプライアンスへのREDO転送の設定

プライマリ・データベース(North_Sales)、フィジカル・スタンバイ・データベース(South_Sales)およびリカバリ・アプライアンス(EnterpriseRecoveryAppliance)がある構成を考えます。プライマリがそのREDOをスタンバイとリカバリ・アプライアンスの両方に送信するのではなく、RedoRoutesプロパティを設定して、プライマリがREDOをフィジカル・スタンバイのみに送信し、フィジカル・スタンバイがそのREDOをリカバリ・アプライアンスに転送するようにできます。そのためには、RedoRoutesプロパティを次のように設定する必要があります。

• North_Salesデータベースでは、North_Salesがプライマリ・ロールである場合、同期転送モードを使用してSouth_SalesデータベースにREDOを送信するように、RedoRoutesプロパティを指定する必要があります。このルールにより、プライマリからリカバリ・アプライアンスEnterpriseRecoveryApplianceにREDOデータが直接送信されなくなります。

• South_Salesデータベースでは、North_Salesがプライマリ・ロールの場合、South_Salesが、North_Salesから受け取ったREDOをEnterpriseRecoveryApplianceに転送するように、RedoRoutesプロパティを指定する必要があります。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : South_Sales SYNC)';
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : EnterpriseRecoveryAppliance ASYNC)';

EnterpriseRecoveryAppliance接続先のREDOルート・ルールで、ASYNC REDO転送属性が明示的に指定されることで、その接続先へのREDOのリアルタイム・カスケーディングが有効にされたことに注意してください。

リカバリ・アプライアンスは、ブローカ構成に追加されると、プライマリ・データベースまたはスタンバイ・データベースからREDOを受け取ることができます。例4-9に、フィジカル・スタンバイ・データベースからREDOを受け取るようにリカバリ・アプライアンスを設定する方法を示します。

関連項目:

• REDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照

4.6 ログ適用サービスの管理

ログ適用に関連するデータベース・プロパティを使用して、フィジカルまたはロジカル・スタンバイ・データベース上のREDO ApplyおよびSQL Applyを管理できます。

ログ適用関連のデータベース・プロパティは次のとおりです。

• REDO ApplyおよびSQL Applyに共通のプロパティ

  • ApplyInstanceTimeout

  • DelayMins

  • PreferredApplyInstance

• REDO Applyに固有のプロパティ

  • ApplyParallel

  • ApplyInstances

• SQL Applyに固有のプロパティ

  • LsbyMaxEventsRecorded

  • LsbyPreserveCommitOrder

  • LsbyRecordSkipErrors

  • LsbyRecordSkipDdl

  • LsbyRecordAppliedDdl

  • LsbyMaxSga

  • LsbyMaxServers

  現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、「Oracle Data Guard Brokerのプロパティ」のSQL Apply関連のプロパティの情報を参照してください。

  データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。

4.6.1 遅延適用の管理

スタンバイ・データベースへのREDOの適用を遅延させるように適用サービスを設定できます。

これにより、スタンバイ・データベースとプライマリ・データベース間にずれが生じ、この期間中にユーザー・エラー(表の削除など)が発生した場合も、スタンバイ・データベースには正しいデータが含まれているため、それをプライマリ・データベースに転送してデータを修復できます。

デフォルトでは遅延は設定されておらず、REDOデータはできるかぎり速やかにスタンバイ・データベースに適用されます。スタンバイ・データベースでREDOログが構成されると、ブローカは、リアルタイム適用を有効化します。REDO ApplyおよびSQL ApplyがリアルタイムでREDOを適用する場合、REDOデータは、書き込まれると同時に、スタンバイREDOログ・ファイルから直接リカバリされます。つまり、スタンバイ・データベースは、アーカイブREDOログ・ファイルからREDOデータを適用するのにログ・ファイルがアーカイブされるのを待つ必要はありません。これにより、プライマリとスタンバイのトランザクション・ラグが最小限に抑えられます。

データベース・プロパティDelayMinsを使用して、スタンバイ・データベースにREDOデータが適用されるまでのログ適用サービスの待機時間(分)を指定します。スタンバイ・データベースへのログ適用サービスのみが遅延されることに注意してください。プライマリ・データベースのREDO転送サービスは遅延されないため、プライマリ・データベースのデータは引き続きスタンバイ・データベースにより適切に保護されます。

注意:

ブローカではスタンバイ・データベースへのリアルタイム適用が自動的に有効化されるため、フラッシュバック・データベースを使用するようにすべてのデータベースを構成することをお薦めします。

4.6.2 REDO Applyでのパラレル適用の管理

REDO Applyでは、データベース・プロパティApplyParallelを使用して、プライマリ・データベースから受け取ったREDOデータの適用に複数のパラレル・プロセスを使用するかどうかを構成できます。

並列性はデフォルトで有効化されています。つまり、REDO ApplyではシステムのCPUの数に基づいて最適なパラレル・プロセス数が自動的に選択されます。(これは、ApplyParallelプロパティをAUTOに設定することと同じです。)ApplyParallelプロパティをNOに設定することで並列性を無効化できます。

ノート:

パラレルREDO ApplyはマルチインスタンスREDO Applyとは異なります。パラレルREDO Applyとは、各インスタンスに複数のREDO Applyスレーブがあることを意味し、この値は、ブローカのApplyParallelプロパティで設定します。マルチインスタンスREDO Applyとは、複数のインスタンスがREDO Applyを実行していることを意味し、この値は、ブローカのApplyInstancesプロパティで設定します。適用がマルチインスタンス適用で実行されている各インスタンス上でREDO Applyスレーブを制御するには、2つのプロパティを同時に使用できます。ApplyParallelプロパティで指定するパラレル・スレーブの数は、マルチインスタンス適用構成内の各インスタンスで同一になります。

関連項目:

ApplyParallel

ApplyInstances

4.6.3 マルチインスタンスREDO Applyの管理

Oracle RACデータベースのREDO Applyについては、ApplyInstancesプロパティの値を使用して、リカバリに使用できるインスタンスの数を構成できます。

デフォルトでは、1つのインスタンスのみがリカバリ・アクティビティに関係します。ただし、ApplyInstancesプロパティを設定して、特定のインスタンス数を指定したり、値ALLですべてのインスタンスを指定することができます。リカバリが開始すると、設定された数のインスタンスがリカバリを開始できるかどうかがチェックされます。できない場合、ブローカはリカバリの開始を1分間遅らせて、他のインスタンスを起動してからリカバリを開始します。

定期的な健全性チェック時に、ブローカはリカバリに使用できる可能性のあるインスタンスが他に開始されていないかどうかをチェックします。該当する場合、ブローカはリカバリを停止して再開し、追加のインスタンスを使用します。

ApplyInstancesプロパティの値を変更すると、その新しい値を使用してリカバリが再開されます。

そのインスタンスをリカバリで使用するには、すべてのインスタンスを同じ状態(オープンまたはマウント済)にする必要があります。

4.6.4 Oracle RACデータベース環境での適用サービス

スタンバイ・データベースがOracle RACデータベースの場合、SQL ApplyおよびREDO Applyは適用インスタンスを利用します。

SQL Applyは、任意の時点でのOracle RACデータベースの1つのインスタンスのみで実行できます。このインスタンスを適用インスタンスと呼びます。

REDO Applyは一度にOracle RACデータベースのすべてのインスタンスで実行できますが、そのうちの1つのインスタンスのみが適用コーディネータであり、これはブローカが適用インスタンスとみなしたインスタンスです。この機能では、構成可能なデータベース・プロパティApplyInstances (フィジカル・スタンバイ・データベースでのみ有効)が0以外の値に設定する必要があります。「ApplyInstances」を参照してください。

適用インスタンスに障害が発生すると、ブローカは必要に応じて異なるインスタンスでSQL ApplyまたはREDO Applyコーディネータを自動的に再起動します。これは、適用インスタンスのフェイルオーバーと呼ばれます(「適用インスタンスのフェイルオーバー」を参照)。

4.6.4.1 適用インスタンスの選択

Oracle RACスタンバイ・データベースでどのインスタンスを適用インスタンスにしてもよい場合、ブローカが適用インスタンスを任意に選択します。特定のインスタンスを適用インスタンスとして選択するには、次の2つの方法があります。

ノート:

この項の情報は、スナップショット・スタンバイ・データベースまたは遠隔同期インスタンスには適用されません。

• 最初の方法は、PreferredApplyInstanceデータベース・プロパティの値を、適用インスタンスとして指定するインスタンスの名前(InstanceNameプロパティを参照)に設定することです。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、そのインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ1度も有効化していない場合、適用インスタンスに障害が発生したばかりで、ブローカが適用インスタンスをフェイルオーバーしようとしている場合、またはOracle RACデータベースが現在プライマリ・データベースとして稼働中で、スイッチオーバーの準備として適用インスタンスを指定する必要がある場合などです。適用インスタンスが選択されており、かつ、その適用インスタンスが実行中の場合は、PreferredApplyInstanceプロパティを変更しても、ブローカでは変更後の値が無視されます。

• 第2の方法では、選択され実行されている適用インスタンスを変更します。適用インスタンスを変更するには、特定の適用インスタンス引数を指定してDGMGRLのSET STATEコマンドを発行し、スタンバイ・データベースの状態をAPPLY-ONに設定します。SET STATEコマンドを実行すると、PreferredApplyInstanceプロパティが新しい適用インスタンスの値に更新されてから、ログ適用サービスが新規インスタンスに移動します。たとえば、DGMGRLのSHOWコマンドを使用してスタンバイ・データベースで使用可能なインスタンスを表示し、EDIT DATABASEコマンドを発行してログ適用サービスを新規インスタンスに移動します。

  DGMGRL> SHOW DATABASE 'South_Sales'
   
  Database - South_Sales
   
    Role:            PHYSICAL STANDBY
    Intended State:  APPLY-ON
    Transport Lag:   0 seconds (computed 1 second ago)
    Apply Lag:       0 seconds (computed 1 second ago)
    Apply Rate:      1017.00 KByte/s
    Real Time Query: OFF
    Instance(s):
      south_sales1   (apply instance)
      south_sales2
   
  Database Status:
  SUCCESS
  

  DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-ON' WITH APPLY INSTANCE='south_sales2';
  Succeeded.
  
  DGMGRL> SHOW DATABASE 'South_Sales' 'PreferredApplyInstance';
    PreferredApplyInstance = 'south_sales2'
  

  DGMGRL> SHOW DATABASE 'South_Sales'
   
  Database - South_Sales
   
    Role:            PHYSICAL STANDBY
    Intended State:  APPLY-ON
    Transport Lag:   0 seconds (computed 1 second ago)
    Apply Lag:       0 seconds (computed 1 second ago)
    Apply Rate:      1017.00 KByte/s
    Real Time Query: OFF
    Instance(s):
      south_sales1
      south_sales2   (apply instance)
   
  Database Status:
  SUCCESS
  

コマンドの発行時には、新規適用インスタンスが実行中であることを確認してください。それ以外の場合は、適用インスタンスが変更されません。

適用インスタンスの選択後、ブローカは適用インスタンス情報をブローカ構成ファイルに保存します。これにより、スタンバイ・データベースが停止されて再起動されても、ブローカは停止前と同じインスタンスを選択してログ適用サービスを起動できます。適用インスタンスは、ユーザーが変更するか、なんらかの原因で障害が発生してブローカが適用インスタンスのフェイルオーバーを実行すると決定するまで変更されません。

4.6.4.2 適用インスタンスのフェイルオーバー

適用インスタンスの障害に対するフォルト・トレラントを持たせるために、ブローカはログ適用サービスを異なるスタンバイ・インスタンスに自動的にフェイルオーバーすることで、Oracle RACスタンバイ・データベースの可用性を利用します。

ブローカが提供する適用インスタンスのフェイルオーバー機能により、データ保護が強化されます。

適用インスタンスのフェイルオーバーを設定するには、データベース・プロパティApplyInstanceTimeoutを設定してブローカの待機時間を指定します。この待機時間は、適用インスタンス障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの期間です。適切なタイムアウト値を選択するには、次のことを考慮する必要があります。

• クラスタに、障害が発生した適用インスタンスのリカバリを試みる他のメカニズムがあるかどうか(Oracle Clusterwareなど)。

• ビジネスで、REDOデータがスタンバイ・データベースに適用されないことを容認できる時間。

• ログ適用サービスを他のインスタンスに移動する操作に関連するオーバーヘッド。オーバーヘッドには、障害の発生した適用インスタンス上に累積されていて未適用のログ・ファイルすべてが、他のスタンバイ・インスタンスからアクセスできる共有ファイル・システムに保存されていない場合に、それをプライマリ・データベースから再転送する操作が含まれる場合があります。

ブローカのApplyInstanceTimeoutプロパティのデフォルト値は0秒です。これは、現在の適用インスタンスの障害検出後ただちに、適用インスタンスのフェイルオーバーが開始されることを示しています。

ブローカでは、適用インスタンスのフェイルオーバー開始後に、次のルールに従って新規の適用インスタンスが選択されます。PreferredApplyInstanceプロパティが現在実行中のインスタンスを示している場合は、それが新規の適用インスタンスとして選択されます。それ以外の場合は、現在実行中の任意のインスタンスが新規の適用インスタンスとして選択されます。

また、適用インスタンスの障害発生時にフィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作していた場合、Oracleリカバリ・クリーンアップの完了後、自動的にクローズされたインスタンスはすべてブローカによってオープンされます。障害の発生した適用インスタンスが唯一のオープン・インスタンスであった場合、リアルタイム問合せを再度有効にするため、適用サービスを開始する前に、新しい適用インスタンスとして選択されたインスタンスがオープンされます。

関連項目:

• リアルタイム問合せモードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

• Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。

4.6.5 適用ラグ

適用ラグは、REDOの伝播および適用の遅延により、スタンバイ・データベースまたは遠隔同期インスタンスのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。

Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースまたは遠隔同期インスタンスごとに適用ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに適用ラグが表示されます。DGMGRLクライアントでは、SHOW DATABASE出力に適用ラグが表示されます。プライマリ・データベースに対する適用ラグは表示されません。次に例を示します。

DGMGRL> SHOW DATABASE 'South_Sales';
Database - South_Sales
 
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds (computed 0 seconds ago)
  Apply Lag:       0 seconds (computed 0 seconds ago)
  Apply Rate:      255.00 KByte/s
  Real Time Query: OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

Oracle Databaseリリース19c以上では、SHOW CONFIGURATION LAGコマンドによって、ブローカ構成のサマリーおよびすべてのスタンバイ・データベースの適用ラグが表示されます。

適用ラグでは、REDO転送サービスとログ適用サービスで発生する可能性のある問題を識別することができます。

構成可能なデータベース・プロパティApplyLagThresholdを設定すると、スタンバイ・データベースまたは遠隔同期インスタンスがプライマリ・データベースのデータに遅れを取る場合に健全性チェック警告を生成できます。

次のコマンドは、ApplyLagThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ApplyLagThreshold'=15;
Property ApplyLagThreshold updated

4.7 データ保護モードの管理

ブローカを使用すると、様々なデータ保護モードでの構成を設定できます。

使用可能なデータ保護モードは、最大保護、最大可用性および最大パフォーマンスです。

この項では、構成の適切な保護に役立つ項目について説明します。

• 構成に対する保護モードの設定

• 保護モードによるブローカ操作への影響

4.7.1 構成に対する保護モードの設定

次に、構成の保護モードを設定するステップを示します。

• 保護モードの設定(タスク1): 使用するデータ保護モードの決定

• 保護モードの設定(タスク2): スタンバイREDOログ・ファイルの設定

• 保護モードの設定(タスク3): REDO転送モードの設定

• 保護モードの設定(タスク4): DGMGRLまたはCloud Controlの使用

4.7.1.1 保護モードの設定(タスク1): 使用するデータ保護モードの決定

各データ保護モードでは、データ保護、データ可用性およびデータベース・パフォーマンスが様々なバランスで提供されます。

ビジネス・ニーズに合うデータ保護モードを選択するには、データ保護の要件とユーザーが要求するパフォーマンスを慎重に考慮します。

ノート:

最大保護モードは、次の状況では使用できません。

• 構成の唯一のスタンバイ・データベースがスナップショット・スタンバイである場合

• 遠隔同期インスタンスが、プライマリ・データベースから同期モードでREDOを受け取っている唯一の構成メンバーである場合

最大可用性

この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。トランザクションのリカバリに必要なすべてのREDOデータがオンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで、トランザクションはコミットされません。プライマリ・データベースは、REDOストリームを少なくとも1つの同期化されたスタンバイ・データベースに書き込むことができない場合、REDOストリームを同期化されたスタンバイ・データベースに再び書き込めるようになるまで、最大パフォーマンス・モードにあるかのように動作してプライマリ・データベースの可用性を維持します。

このモードでは、プライマリ・データベースの障害発生時に、第2の障害が発生してもプライマリ・データベースから1つ以上のスタンバイ・データベースにREDOデータの完全なセットを送信できるときにのみ、データが消失しないことが保証されます。

保護モードが最大可用性の場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大パフォーマンス

この保護モードは、プライマリ・データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供します。これは、トランザクションによって生成されたすべてのREDOデータがオンライン・ログに書き込まれた直後に、そのトランザクションのコミットを可能にすることで実現されます。REDOデータは、1つ以上のスタンバイ・データベースにも書き込まれますが、トランザクション・コミットについて非同期で行われるため、プライマリ・データベースのパフォーマンスは、スタンバイ・データベースへのREDOデータの書込み遅延による影響を受けません。

この保護モードは、最大可用性モードに比べてデータ保護が若干弱く、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。

これはデフォルトの保護モードです。

保護モードが最大パフォーマンスの場合、ファスト・スタート・フェイルオーバーを有効化できます。

最大保護

この保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がないことを保証します。このレベルの保護を提供するには、トランザクションがコミットされる前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログおよび少なくとも1つの同期化されたスタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。少なくとも1つの同期化されたスタンバイ・データベースにREDOストリームを書き込むことができない場合は、データ消失が発生しないように、プライマリ・データベースは停止し、トランザクションの処理を続行しません。

Oracle Data GuardがREDOデータをスタンバイREDOログ・ファイルの永久記憶域に書き込むとすぐに、プライマリのトランザクションは保護されたものとみなされます。その後すぐにプライマリ・データベースに確認通知を戻し、次のトランザクションに進めるようにします。これによって、プライマリ・データベースでの同期転送スループットやレスポンス時間による影響を最小化できます。スタンバイ・データベースでの完全なOracle Data Guardの検証機能を最大限活用するには、必ずリアルタイムの適用モードで操作し、REDOの変更を受信と同時にスタンバイ・データベースに適用します。Oracle Data Guardは検出したすべての破損を通知するので、迅速な修正処理を実行できます。

このデータ保護モードは、プライマリ・データベースの可用性よりもデータ保護を優先するため、2つ以上のスタンバイ・データベースを使用して、最大保護モードで稼働するプライマリ・データベースを保護し、1つのスタンバイ・データベースの障害が原因でプライマリ・データベースが停止しないようにします。1つのスタンバイ・データベースのみが最大保護モードをサポートしている場合、Oracle Data Guard Brokerは適用インスタンスのシャットダウンを禁止します。これによりプライマリ・データベースはシャットダウンされなくなります。

保護モードが最大保護の場合、ファスト・スタート・フェイルオーバーを有効化できます。

関連項目:

• ファスト・スタート・フェイルオーバーの詳細は、「ファスト・スタート・フェイルオーバー」を参照

• データ保護モードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.7.1.2 保護モードの設定(タスク2): スタンバイREDOログ・ファイルの設定

使用している保護モードに関係なく、スタンバイREDOログ・ファイルをすべてのスタンバイ・データベースに追加する必要があります。

また、スイッチオーバーやフェイルオーバーに備えてプライマリ・データベース上にもスタンバイREDOログ・ファイルを追加する必要があります。ファスト・スタート・フェイルオーバーを有効にする場合は、プライマリ・データベース上にスタンバイREDOログ・ファイルが必要です。

Cloud Controlでは、構成内の1つ以上のスタンバイ・データベースを選択するように要求され、将来のロール変更に備えて、スタンバイ・データベースおよびプライマリ・データベース上にスタンバイREDOログ(SRL)ファイルが設定されます。

関連項目:

DGMGRLコマンドライン・インタフェースを使用する場合は、スタンバイREDOログ・ファイルを構成する際に、『Oracle Data Guard概要および管理』の指示に従ってください。

4.7.1.3 保護モードの設定(タスク3): REDO転送モードの設定

データ保護モードによって、スタンバイ・データベースのいずれかが使用しているREDO転送モードの変更が必要になる場合、各スタンバイ・データベース上でLogXptModeデータベース・プロパティを変更するか、プライマリ・データベース上、またはスタンバイ・データベースに直接接続している遠隔同期インスタンス上で、RedoRoutesプロパティを設定します。

REDO転送サービスの設定の詳細は、「REDO転送サービスの管理」を参照してください。表4-2では、保護モードおよび対応するREDO転送サービスを示します。

Cloud Controlでは自動的に、将来のスイッチオーバーに備えて、プライマリ・データベース上に適切なREDO転送サービスが設定されます。

表4-2 Oracle Data Guard保護モードと要件

保護モード	REDO転送	スタンバイREDOログ・ファイルの要否	ファスト・スタート・フェイルオーバーとの併用
MAXPROTECTION	SYNC	はい	はい
MAXAVAILABILITY	SYNC、FASTSYNC	はい	はい脚注1
MAXPERFORMANCE	ASYNC	はい	はい

^脚注1

FASTSYNC転送モードはLOG_ARCHIVE_DEST_nパラメータのNOAFFIRM属性を使用するため、データが失われる可能性があります。FASTSYNCを使用していて、スタンバイにREDOデータがない場合、ファスト・スタート・フェイルオーバーを開始できません。

4.7.1.4 保護モードの設定(タスク4): DGMGRLまたはCloud Controlの使用

次のステップは、DGMGRLコマンドまたはCloud Controlを使用して保護モードを設定する方法について説明します。

DGMGRLを使用する場合:

1. EDIT DATABASE(プロパティ)コマンドを使用して、設定する保護モードに対応するようにREDO転送サービスを変更する必要のあるスタンバイ・データベースを指定します。たとえば、Oracle Data Guard構成全体を最大可用性モードで動作するように設定する場合は、EDIT DATABASEコマンドを使用して、REDO転送サービスに対してSYNCモードを設定する必要があります。次に例を示します。

   DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode='SYNC';
   

   この確認を構成内のプライマリ・データベースまたは他のスタンバイ・データベースについても行い、選択した保護モードをスイッチオーバー後もサポートできることを確認します。

   次のように、RedoRoutesプロパティを使用することもできます。

   EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes = '(LOCAL : South_Sales SYNC)';
   

2. EDIT CONFIGURATION SET PROTECTION MODE AS protection-modeコマンドを使用して、構成全体の保護モードを設定します。次に例を示します。

   DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
   

保護モードの設定方法を示すDGMGRLの使用例については、「使用例4: 構成保護モードの設定」を参照してください。

Cloud Controlを使用する場合:

1. Oracle Data Guardの概要ページで、「保護モード」ラベルの右にあるリンクをクリックします。
2. 「最大保護」、「最大可用性」または「最大パフォーマンス」を選択して「続行」をクリックします。
3. プロンプトが表示される場合は、SYSDGまたはSYSDBA権限でデータベースにログインして「ログイン」をクリックします。
4. 選択した保護モードをサポートする1つ以上のスタンバイ・データベースを選択します。スタンバイREDOログ・ファイルが必要な場合は、ログ・ファイル名を確認します。「OK」をクリックします。
5. 「確認」ページで「はい」をクリックします。

ブローカでは、保護モードを最大パフォーマンス・モードから最大保護モードに直接アップグレードできません。まず最大パフォーマンスから最大可用性に変更し、その後で最大保護に変更する必要があります。

4.7.2 保護モードによるブローカ操作への影響

次のトピックでは、Oracle Data Guard構成の保護モードおよびREDO転送サービスが、スイッチオーバー、フェイルオーバー、および構成の無効化や有効化などの操作にどのような影響を与えるかについて説明します。

この項の内容は、次のとおりです。

• 現在の保護モードのアップグレードまたはダウングレード

• スイッチオーバー操作

• フェイルオーバー操作

• 無効化操作と有効化操作

• 構成からデータベースを削除する際の要件

• その他の操作要件

4.7.2.1 現在の保護モードのアップグレードまたはダウングレード

現在のOracle Data Guard保護モードを最大可用性モードにアップグレードする場合または現在のOracle Data Guard保護モードをダウングレードする場合、再起動は不要です。Oracle Data Guard保護モードのアップグレード時またはダウングレード時には、次の推奨事項に従ってください。

• 保護モードをアップグレードするときは、全体の保護モードをアップグレードする前にREDO転送サービスをアップグレードします。保護モードの変更時やスタンバイ・データベースのREDO転送サービスのリセット時に、ブローカは、必要なレベルの保護をサポートできるスタンバイ・データベースが構成内に少なくとも1つ存在していることを確認します。この条件が満たされない場合、保護モードは変更されず、エラーが戻されます。

• 保護モードをダウングレードするときは、最初に保護モードをダウングレードしてから、REDO転送サービスを変更します(必要な場合)。REDO転送サービスの変更によって現在の全体の保護モードが無効になる場合、ブローカはREDO転送サービスの変更を許可しません。

最大パフォーマンス・モードから保護モードをアップグレードする場合、ブローカは、直接、または、遠隔同期インスタンスを介して、SYNC転送を使用してREDOを受け取るスタンバイ・データベースが少なくとも1つあることを確認します。また、最大保護モードへのアップグレードの場合、ブローカは、スタンバイ・データベースのREDOデータにギャップがないことを確認します。これらの要件を満たすスタンバイ・データベースが構成内に存在していない場合、保護モードのアップグレード要求はエラーとなり拒否されます。

ファスト・スタート・フェイルオーバーが有効化されても、保護モードは変更されません。この例外として、ファスト・スタート・フェイルオーバーが最大保護モードで有効化されている場合は、最大可用性モードへのダウングレードが可能です。

4.7.2.2 スイッチオーバー操作

スイッチオーバーでは、全体のOracle Data Guard保護モードは変更されません。保護モードはスイッチオーバー前と同じです。

スイッチオーバーの完了後に現在の保護モードをサポートするために、適切に構成されているスタンバイ・データベースが必要です。これは、構成内の他のスタンバイ・データベースでも、スイッチオーバー完了後にスタンバイ・データベースとなる現行のプライマリ・データベースでもかまいません。

必要な場合は、スイッチオーバーを起動する前に、現行のプライマリ・データベース上または構成内の他のスタンバイ・データベース上に、スタンバイREDOログ・ファイルを追加して、REDO転送プロパティをOracle Data Guard保護モードのサポートに必要な転送モードに設定できます。その後スイッチオーバーが開始されると、次の処理が実行されます。

• ブローカでは、各スタンバイ・データベース上と現行のプライマリ・データベース上で、スタンバイREDOログ・ファイルが存在することとREDO転送サービスの設定が検証されます。

• ブローカは、ターゲット・スタンバイ・データベースに存在するREDOデータに差分がないことを検証します。

検証が正常終了した場合は、スイッチオーバーが続行されます。正常終了しなかった場合、スイッチオーバーは失敗し、データベース・ロールとブローカ構成ファイルは変更されません。

警告:

• スイッチオーバーのターゲットがフィジカル・スタンバイ・データベースの場合、ブローカはシャットダウンして、プライマリ・データベースを再起動します。

関連項目:

スイッチオーバーの詳細は、「スイッチオーバー」を参照

4.7.2.3 フェイルオーバー操作

保護モードが最大保護だった場合、手動フェイルオーバーを実行した後に、Oracle Data Guard保護モードが最大パフォーマンス・モードにダウングレードされます。必要な場合、保護モードは後でアップグレードできます。保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。スタンバイ・データベースのREDO転送サービスは変更されません。

ファスト・スタート・フェイルオーバーが実行された場合、ブローカにより、フェイルオーバー前に有効になっていた保護モードが保持されます。保護モードが最大保護であった場合、構成保護モードは保持されますが、新しいプライマリ・データベースは、インスタンスがオープンできるように最大可用性に設定されます。(元のプライマリ・データベースが回復されたか、構成内に別のスタンバイが存在するために)最大保護モードをサポートするスタンバイが使用可能になると、データベース保護モードは構成保護モード(最大保護)にあわせて引き上げられます。

関連項目:

手動フェイルオーバーおよびファスト・スタート・フェイルオーバーの詳細はそれぞれ、「手動フェイルオーバー」および「ファスト・スタート・フェイルオーバー」を参照

4.7.2.4 無効化操作と有効化操作

あるスタンバイ・データベースのブローカ管理を無効化すると、ブローカによって、残りのスタンバイ・データベースのいずれかが、全体の保護モードの要件を引き続き満たしているかがチェックされます。この条件が満たされない場合、無効化操作はブローカによって拒否されます。この条件が満たされる場合は、ファスト・スタート・フェイルオーバーが有効化されていないかぎり、無効化操作は続行されます。ファスト・スタート・フェイルオーバーが有効化されている場合でも、そのスタンバイ・データベースが、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースでなければ、無効化操作は続行されます。

警告:

ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。

ファスト・スタート・フェイルオーバーが有効化されていないかぎり、構成全体は保護モードに関係なく無効化できます。ファスト・スタート・フェイルオーバーが有効化されている場合は、構成を無効にできません。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」を参照してください。

構成全体のブローカ管理を有効化するときは、ブローカによって、有効化されるスタンバイ・データベースのREDO転送設定が保護モードの要件を満たしているかどうかが最初にチェックされます。この条件が満たされていない場合、有効化操作は失敗し、構成は無効のままになります。条件が満たされている場合は、有効化操作によって構成が正常に有効化され、ブローカは、ブローカ構成ファイルに保存されている設定を使用してデータベースを有効化します。

4.7.2.5 構成からデータベースを削除する際の要件

ブローカ構成からスタンバイ・データベースを削除するときは、ブローカによって、保護モードの要件が満たされているかどうかがチェックされます。次の場合、操作は失敗します。

• そのデータベースの削除により保護モードに影響がある場合

• ファスト・スタート・フェイルオーバーが有効化されているのに、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースを削除しようとした場合

• 削除する構成メンバーの構成可能なプロパティRedoRoutesがNullでない値に設定されている場合

ファスト・スタート・フェイルオーバーが有効化されていない場合は、いつでも構成を削除できます。

4.7.2.6 その他の操作要件

ブローカ構成で行われる一部の操作、特にREDO転送サービスに関連する操作は、全体の保護モードに影響を与える場合があります。次のような操作があります。

• プライマリ・データベースのREDO転送サービスを停止する操作

• 個々のスタンバイ・データベースへのREDO転送サービスを停止する操作

• 最大可用性モードまたは最大保護モードで動作している構成をサポートする唯一のスタンバイ・データベースで、REDO転送モードをSYNCからASYNCにダウングレードする操作

これらの操作の前には、ブローカによって、操作完了後にスタンバイ・データベースのREDO転送モード設定が保護モードをサポートするかどうかがチェックされます。この条件が満たされていない場合、操作は失敗し、エラーが戻されます。

4.8 遠隔同期インスタンスの管理

Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取るREDO転送先で、そのREDOを構成内の1つ以上のREDO接続先に転送します。

それは制御ファイルを持つ点でフィジカル・スタンバイ・データベースに類似しており、REDOをスタンバイREDOログ・ファイル(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログ(ARL)にアーカイブします。しかしスタンバイ・データベースとは異なり、遠隔同期インスタンスにはデータ・ファイルがなく、オープンすることもできず、受け取ったREDOを適用することもできません。これらの制限のために、ディスクと処理リソースの使用量が少なくなる利点があります。より重要なこととして、遠隔同期インスタンスは、同期転送モードを使用してREDOデータを受け取り、構成保護モードが最大可用性に設定されている場合、データ損失なしでターミナル・データベースにフェイルオーバーすることができます。

次の例は、ブローカ構成に遠隔同期インスタンスを追加する方法を示します。

DGMGRL> ADD FAR_SYNC FS1 AS CONNECT IDENTIFIER IS FS1.example.com;
Far Sync FS1 added
DGMGRL> ENABLE FAR_SYNC FS1;
Enabled.
DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
  North_Sales  - Primary database
    FS1        - Far Sync
    South_Sales - Physical standby database
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

遠隔同期インスタンスが構成に追加された後、REDO転送を設定して最大可用性をサポートし、その後で保護モードを次のようにアップグレードします。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS1 SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    FS1          - Far Sync
      South_Sales - Physical standby database
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

South_Salesがプライマリ・データベースの場合に、最大可用性保護モードを保持できるようにするには、スイッチオーバーまたはフェイルオーバー後に、2番目の遠隔同期インスタンスを構成に追加して、South_SalesがREDOを同期モードで送信できるようにし、ロール遷移後に新しいターミナル・データベースのNorth_Sales,にREDOが送信されるようにします。

次の例は、ブローカ構成に2番目の遠隔同期インスタンスを追加する方法を示します。

DGMGRL> ADD FAR_SYNC FS2 AS CONNECT IDENTIFIER IS FS2.example.com;
Far Sync FS2 added
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> ENABLE FAR_SYNC FS2;
Enabled.
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS2 SYNC)';
DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    FS1          - Far Sync
      South_Sales - Physical standby database
      FS2         - Far Sync (inactive)
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

遠隔同期インスタンスの可用性が、(たとえばOracle Restart、Oracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeのインストールにおいて) Oracle Clusterwareによって監視されている場合、SRVCTLユーティリティを使用して、デフォルトのオープン・マウント・モードを指定します。次のようなコマンドを使用できます。

srvctl modify database -d <db_unique_name> -startoption MOUNT

関連項目:

• 遠隔同期インスタンスの作成およびREDO転送の詳細は、『Oracle Data Guard概要および管理』を参照してください。

4.9 ファスト・スタート・フェイルオーバーの管理

ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定された1つ以上のターゲット・スタンバイ・データベースのリストにあるスタンバイ・データベースへのフェイルオーバーの開始が可能になります。

設定により、消失データなしでフェイルオーバーする場合と、構成可能なデータ量を消失する場合があります。また、フェイルオーバーが開始される条件やエラーも指定できます。DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでファスト・スタート・フェイルオーバーを要求できます。

ブローカ構成プロパティを使用して、ファスト・スタート・フェイルオーバーの動作を制御します。また、Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される条件を指定することもできます。

4.9.1 ファスト・スタート・フェイルオーバーをチューニングするプロパティの構成

各種プロパティを設定して、ファスト・スタート・フェイルオーバーの動作を調整できます。

ファスト・スタート・フェイルオーバーに関する構成可能なプロパティは、次のとおりです。

• FastStartFailoverThreshold

  FastStartFailoverThreshold構成プロパティを設定して、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。詳細および例は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。

• FastStartFailoverPmyShutdown

  FastStartFailoverPmyShutdown構成プロパティは、REDOの生成が停止され(V$DATABASEのFS_FAILOVER_STATUS列の値がSTALLED)、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われてから経過した時間がFastStartFailoverThreshold構成プロパティに指定された秒数を超過した場合、プライマリ・データベースを停止するかどうかを制御します。FastStartFailoverPmyShutdownのデフォルト値はTRUEです。

  ノート:

  ユーザーによる構成可能な条件が検出された場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーが開始された場合、プライマリ・データベースは常に停止します。

• FastStartFailoverLagLimit

  ファスト・スタート・フェイルオーバー機能は、最大パフォーマンス・モードで動作するデータベースで構成できます。ASYNCモードでREDOを受け取る宛先は、許容可能なファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースであり、これらの宛先はREDOの受取りおよび適用に関してプライマリより遅れる可能性があります。FastStartFailoverLagLimit構成プロパティを使用して、構成可能な時間ベースの制限を指定できます。スタンバイ・データベースでREDOが適用された時点がプライマリのREDO生成時点からこの秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。適用時点がこの制限よりも遅れていると、ファスト・スタート・フェイルオーバーは許可されません。

  FastStartFailoverLagLimit構成プロパティは、構成が最大可用性モードで動作しているときに、ファスト・スタート・フェイルオーバーが有効化されている場合も使用できます。構成が最大保護モードで稼働している場合は使用できません。FastStartFailoverLagLimitがゼロ以外の値に設定され、構成が最大可用性モードで動作している場合、データ消失がゼロのフェイルオーバーまたはデータ消失を伴うフェイルオーバーが行われる可能性があります。データ消失を伴うフェイルオーバーが実行された場合、データ損失の量はFastStartFailoverLagLimit構成プロパティで指定された秒数を超えることはありません。FastStartFailoverLagLimitプロパティにゼロ以外の値が指定され、保護モードが最大可用性モードの場合、ターゲット・スタンバイのREDO転送モードはSYNCまたはFASTSYNCの値に設定する必要があります。ASYNC宛先は、最大パフォーマンス・モードで動作している構成でのみ有効なファスト・スタート・フェイルオーバー・ターゲットです。保護モードまたはREDO転送モードをSYNCまたはFASTSYNCに変更する場合は、最初にファスト・スタート・フェイルオーバーを無効にする必要があります。同様に、最大可用性モードから最大パフォーマンス・モードに保護モードを変更する場合も、ファスト・スタート・フェイルオーバーを無効にしてから、REDOをプライマリとターゲット・スタンバイに送信するのに使用するREDO転送モードをASYNC.に変更する必要があります。元のプライマリの回復は、ASYNCターゲット・スタンバイへのファスト・スタート・フェイルオーバー後に可能になります。オブザーバは元のプライマリを再検出すると、自動的に元のプライマリを回復し、指定されたラグ以内で生成されたすべてのREDOが失われます。

  関連項目:

  詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

• FastStartFailoverAutoReinstate

  FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがクラッシュしたか、FastStartFailoverThresholdの秒数を超えて停止したためにファスト・スタート・フェイルオーバーが発生した場合、元のプライマリ・データベースを自動的に回復するかどうかを制御します。FastStartFailoverAutoReinstateのデフォルト値はTRUEです。

  フェイルオーバーの完了後に診断または修復作業を行う場合は、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定すると、自動回復を回避できます。

  ノート:

  ユーザーによる構成可能なファスト・スタート・フェイルオーバー条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースの自動回復は実行されません。

• FastStartFailoverTarget

  FastStartFailoverTarget構成プロパティは、このデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのターゲットになれるデータベースのDB_UNIQUE_NAME値を指定します。

• ObserverReconnect

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

• ObserverOverride

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

4.9.2 ファスト・スタート・フェイルオーバーの条件の構成

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

また、別の条件でファスト・スタート・フェイルオーバーを実行する必要がある場合もあります。

構成可能な条件は、データベースの健全性チェック・メカニズムによって検出されるものとOracleサーバーで発生するエラー(ORAエラーなど)によって検出されるものの2種類に分類されます。指定された条件が発生すると、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば、FastStartFailoverThresholdを超えるまで待機せずにファスト・スタート・フェイルオーバーを開始します。

各条件は、個別に有効化または無効化できます。Oracle Data Guard構成では、ユーザー指定のすべての構成可能なファスト・スタート・フェイルオーバー条件がブローカ構成ファイルに保持されます。

プライマリ・データベースが有効な健全性チェック条件のいずれかを示すと、オブザーバによって検出され、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーが開始されます。

Oracle ORAエラー条件が指定されている場合、エラーが示されるとプライマリ・データベースがオブザーバに通知し、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーを開始します。

ノート:

プライマリ・データベースは停止し、オブザーバは元のプライマリ・データベースの自動回復を試行しません。

関連項目:

• Cloud Controlオンライン・ヘルプ

• ENABLE FAST_START FAILOVER CONDITION

• DISABLE FAST_START FAILOVER CONDITION

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

DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。

「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください。

4.10 データベース変換の管理

DGMGRLのCONVERT DATABASEコマンドを使用すると、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できます。

スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。

フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。ただし、フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フラッシュバック・データベースを有効にする必要があります。次の例に、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換する方法を示します。

DGMGRL> CONVERT DATABASE 'South_Sales' TO SNAPSHOT STANDBY;

スナップショットを元のフィジカル・スタンバイに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを使用します。

DGMGRL> CONVERT DATABASE 'South_Sales' TO PHYSICAL STANDBY;

4.11 データベース・ステータス

通常、ブローカは、実際のデータベースの状態と設定がブローカ構成ファイル内の記述と一致することを検証し、データベースの健全性をチェックします。

そのためには、Oracle Data Guard構成のコンポーネントで正常に機能していないものがないかどうか(REDO転送サービスにエラーがないかどうかなど)、その他の必須のデータベースの設定が正しく行われているかどうか(サーバー・パラメータ・ファイルが使用可能かどうか、ARCHIVELOGモードがオンになっているかどうかなど)をチェックします。ここでは、ブローカによりプライマリ・データベース上とスタンバイ・データベース上でチェックされる項目を詳しく説明します。

プライマリ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

• データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

• データベースが正しいデータ保護モードであるかどうか。

• データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

• データベースがARCHIVELOGモードであるかどうか。

• データベース・ガードがオフになっているかどうか。

• 補助ロギングがオンになっているかどうか(構成にロジカル・スタンバイ・データベースが含まれている場合)。

• REDO転送サービスにエラーがあるかどうか。

• データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

• REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。

• 現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。

• プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。

スタンバイ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。

• データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。

• データベースでサーバー・パラメータ・ファイルが使用されているかどうか。

• データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。

• データベース・ガードがオンになっているかどうか(データベースがロジカル・スタンバイ・データベースの場合)。

• ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。

4.11.1 データベース・ステータスの問合せ

データベース・ステータスの問合せには、特定の監視可能なプロパティを使用できます。

次のプロパティには、DGMGRLコマンドライン・インタフェースを介して直接アクセスします。

• LogXptStatus

• InconsistentLogXptProps

  ノート:

  Cloud Controlでは、GUIで表示するためにこれらのプロパティの値が並べ替えられます。

SHOW DATABASE <db_unique_name>コマンドを使用して、データベースの簡単な説明(名前、ロールなど)、データベースの状態、および健全性チェックの問題に関する情報を入手できます。たとえば、次のSHOW DATABASEコマンドの出力は、一部のREDO転送サービス・エラーおよびREDO転送関連プロパティの不一致という2つの問題を示しています。

DGMGRL> SHOW DATABASE 'North_Sales';
 
Database - North_Sales
  Role: PRIMARY
  Intended State: TRANSPORT-OFF
  Instance(s):
    north_sales1
      Error: ORA-16737: the redo transport service for standby
        database "South_Sales" has an error
 
    north_sales2
      Error: ORA-16737: the redo transport service for standby
        database "South_Sales" has an error
      Warning: ORA-16715: redo transport-related property
        ReopenSecs of standby "South_Sales" is inconsistent
Database Status:
ERROR

データベースのステータスの詳細を確認するには、次の監視可能なプロパティを使用できます。

• LogXptStatus — プライマリ・データベースの全インスタンス上で検出されたログ転送エラーがすべて表示されます。

• InconsistentLogXptProps — ブローカ構成ファイルとREDO転送設定間で値が一致しない、スタンバイ・データベースのREDO転送関連プロパティがすべて表示されます。

次のSHOW DATABASEコマンドを発行して、問題の詳細を取得します。

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME  STANDBY_DATABASE_NAME  STATUS 
         north_sales1            South_Sales  ORA-12541: TNS:no listener
         north_sales2            South_Sales  ORA-12541: TNS:no listener
 
DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
 INSTANCE_NAME  STANDBY_NAME  PROPERTY_NAME  MEMORY_VALUE  BROKER_VALUE 
  north_sales2   South_Sales     ReopenSecs           600           300

関連項目:

データベース・プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照

4.11.2 ロール変更前のデータベース検証

VALIDATE DATABASEコマンドを使用して、ロール変更を実行する前に包括的なデータベース・チェックを実行できます。

このコマンドは、次の項目を確認します。

• スタンバイ・データベースに、失われたREDOデータがあるかどうか

• フラッシュバックが有効かどうか

• 構成されている一時表領域ファイルの数

• オンライン・データ・ファイルの移動が進行中かどうか

• フィジカル・スタンバイ・データベースの場合、オンラインREDOログがクリアされているかどうか

• プライマリ・データベースの場合、スタンバイREDOログがクリアされているかどうか

• オンライン・ログ・ファイル構成

• スタンバイ・ログ・ファイル構成

• 適用関連のプロパティ設定

• 転送関連のプロパティ設定

• 自動診断リポジトリにエラーがあるかどうか(制御ファイルの破損、システム・データ・ファイルの問題、ユーザー・データ・ファイルの問題など)

関連項目:

• コマンドの説明や様々な使用例のコマンド出力の例示は、「VALIDATE DATABASE」を参照してください

4.11.3 ロールの変更前のサーバー・パラメータ・ファイルの検証

VALIDATE DATABASE SPFILEコマンドを使用して、プライマリ・データベースとスタンバイ・データベースのサーバー・パラメータ・ファイル(SPFILE)の内容を比較します。

プライマリとスタンバイを比較すると、いずれかのデータベースのSPFILEに欠落しているパラメータがあるかどうか、またはエントリに異なる値が含まれているかどうかを判別できます。

関連項目:

• コマンドおよびコマンド出力を示す例の詳細は、「VALIDATE DATABASE SPFILE」を参照してください

4.11.4 ロールの変更前のネットワーク構成の検証

VALIDATE NETWORK CONFIGURATIONコマンドを使用して、構成のメンバー間のネットワーク接続性チェックを実行します。

ネットワークの接続性チェックを実行すると、ロールの変更が試行される前に潜在的なネットワーク構成の問題が特定されます。

関連項目:

• 「ロールの変更前のネットワーク構成の検証」

4.11.5 ロールの変更前の静的接続識別子の検証

DGMGRL CLIで、必要に応じてインスタンスを自動的に開始できるように(たとえば、スイッチオーバー後の新しいスタンバイの場合)、Oracle Restartが構成されていない単一インスタンス・データベースには、リスナーに登録された静的なサービスが必要です。

ブローカは、静的なサービスを使用するStaticConnectIdentifierプロパティにデフォルト値を設定します(db_unique_name_DGMGRLのデフォルト値が静的なサービス名に使用されている場合)。この接続識別子は、インスタンスの再起動に使用されます。

VALIDATE STATIC CONNECT IDENTIFIERコマンドを使用して、StaticConnectIdentifierプロパティで指定された接続識別子がインスタンスを再起動するために使用できることを確認します。このコマンドは、データベースを再起動するのではなく、接続識別子で指定されているサービスがリスナーに登録されていることをチェックします。

関連項目:

• コマンドおよびコマンド出力を示す例の詳細は、「VALIDATE STATIC CONNECT IDENTIFIER」を参照してください