6 DGMGRLコマンドライン・インタフェースの使用例

次の各使用例では、Oracle Data Guard Broker構成の作成、管理および使用を開始するために必要なものを例をあげて説明します。

Oracle Data Guardコマンドライン・インタフェース(DGMGRL)の使用を開始するための前提条件を知ることで、自身の事例に備えることができます。さらに、使用例を読んで、DGMGRLを使用してブローカ構成を作成、管理および監視する方法を理解してください。

6.1 初期使用の前提条件

DGMGRL使用の前提条件の1つは、1つのプライマリ・データベースと任意の数のスタンバイ・データベースが存在していることです。

構成内のすべてのデータベースについて、DG_BROKER_START初期化パラメータをTRUEに設定する必要があります。ブローカではサーバー・パラメータ・ファイルを使用する必要があります。

必要な場合は、プライマリ・データベースとスタンバイ・データベースの初期化パラメータ・ファイル(PFILE)をサーバー・パラメータ・ファイル(SPFILE)に変換します。次のSQL*Plusコマンドを使用します。

CREATE SPFILE='spfilename' FROM PFILE='pfilename';

サーバー・パラメータ・ファイルを使用してインスタンスが起動されていない場合は、そのインスタンスを停止し、サーバー・パラメータ・ファイルを使用して再起動する必要があります。

Oracleインスタンスの起動後に、SQLのALTER SYSTEM文を使用してDG_BROKER_START=TRUE初期化パラメータを設定します。パラメータ値は、サーバー・パラメータ・ファイルに保存されます。Oracleインスタンスの次回起動時にブローカが自動的に起動されるため、SQLのALTER SYSTEM文の再発行は不要です。

これらの使用例では、次を前提としています。

  • プライマリ・データベースとスタンバイ・データベースへの接続にTCP/IPが使用されていること。

  • プライマリ・データベースの制御ファイルとデータファイルのバックアップから、スタンバイ・データベースが作成されていること(詳細は『Oracle Data Guard概要および管理』を参照)

  • 使用例は、次のブローカ構成を前提としています。

    • 構成名はDRSolutionです。

    • プライマリ・データベースの一意名(DB_UNIQUE_NAME)はNorth_Salesです。

    • リモート・スタンバイ・データベースの一意名(DB_UNIQUE_NAME)はSouth_Salesです。

    • 保護モードは最大パフォーマンス・モードです。

    • プライマリ・データベースおよびスタンバイ・データベースの両方にスタンバイREDOログ・ファイルが構成されます。両方のデータベースの転送モードはASYNCです。

    • スタンバイ・データベースはフィジカル・スタンバイ・データベースです。

6.2 使用例1: 構成の作成

これらの例では、North_SalesおよびSouth_Salesという名前のプライマリ・データベースおよびスタンバイ・データベースを含むDRSolutionという名前のブローカ構成を作成します。

構成を作成してフィジカル・スタンバイ・データベースを1つ追加するには、次のタスクを実行します。

6.2.1 構成の作成(タスク1): DGMGRLの起動

DGMGRLを起動するには、Oracle Data Guardがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrlと入力します。

$ dgmgrl

DGMGRLプロンプトが表示されます。

DGMGRL>

6.2.2 構成の作成(タスク2): プライマリ・データベースへの接続

任意のコマンド(HELPEXITまたはQUIT以外)を指定する前に、まずDGMGRL CONNECTコマンドを使用してプライマリ・データベースに接続する必要があります。

データベースへの接続に使用するアカウント(この例ではSYS)には、プライマリ・データベースとスタンバイ・データベースでのSYSDGまたはSYSDBA権限が必要です。

注意:

CONNECTコマンドのデフォルト設定であるため、AS SYSDBAを指定する必要はありません。

次の例は、CONNECTコマンドの2つのバリエーションを示しています。例6-1に、ローカル・システム上のデフォルト・データベースに接続する方法を示し、例6-2に、リモート・システムにあるデータベースに接続するためのOracle Net Services接続識別子(North_Sales.example.com)を示します。この2つの例ではどちらもパスワードの入力を要求されます。

例6-1 ローカル・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sysdg;
Password: password
Connected to "North_Sales"
Connected as SYSDG.

例6-2 リモート・システム上のプライマリ・データベースへの接続

DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected to "North_Sales"
Connected as SYSDG.

6.2.3 構成の作成(タスク3): 追加するスタンバイおよび遠隔同期インスタンス上での既存のリモートREDO転送先のクリア。

スタンバイ・データベースおよび遠隔同期インスタンス上でリモートREDO転送先をすべてクリアしてからでないと、そのスタンバイ・データベースおよび遠隔同期インスタンスを構成に追加できません。

リモートのREDO転送先がクリアされていない場合、構成を作成しようとすると、次のエラー・メッセージが返されます。

ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added
 
Failed.

LOG_ARCHIVE_DEST_n設定をクリアするには、SQL*PlusコマンドALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" "を使用します。

プライマリ上のリモートREDO転送先(REGISTER属性またはNOREGISTER属性のどちらがあるか)は、そのままでかまいません。

6.2.4 構成の作成(タスク4): ブローカ構成の作成

ブローカ構成は最初にプライマリ・データベースで作成されます。

この例では、プライマリはNorth_Salesと呼ばれます。後のコマンドで、スタンバイ・データベースSouth_Salesを追加します。

注意:

プライマリ・データベース名とスタンバイ・データベース名では、それぞれのデータベースの一意名が一致する必要があります。これらの一意名は、次のコマンドを使用してDB_UNIQUE_NAME初期化パラメータからフェッチします。

SQL> SHOW PARAMETER DB_UNIQUE_NAME;

CREATE CONFIGURATIONコマンドを使用し、DRSolution構成を作成してプライマリ・データベースNorth_Salesを定義します。

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
>  PRIMARY DATABASE IS 'North_Sales'
>  CONNECT IDENTIFIER IS North_Sales.example.com;
  

DGMGRLは次の情報を戻します。

Configuration "DRSolution" created with primary database "North_Sales"

名前North_Salesは、このデータベースのDB_UNIQUE_NAME初期化パラメータの値です。

6.2.5 構成の作成(タスク5): 構成情報の表示

SHOW CONFIGURATIONコマンドを使用して、構成に関する簡単なサマリーを表示します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales - Primary database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
DISABLED

6.2.6 構成の作成(タスク6): 構成へのスタンバイ・データベースの追加

DRSolution構成にスタンバイ・データベースを追加するには、 ADD DATABASEコマンドを使用します。

次のコマンドは、スタンバイ・データベースとしてSouth_Salesを定義しています。これは、プライマリ・データベースNorth_Salesに関連付けられているスタンバイ・データベースです。

DGMGRL> ADD DATABASE 'South_Sales' AS
>  CONNECT IDENTIFIER IS South_Sales.example.com;

DGMGRLは次の情報を戻します。

Database "South_Sales" added

名前South_Salesは、データベースのDB_UNIQUE_NAME初期化パラメータの値です。

SHOW CONFIGURATIONコマンドを使用して、South_SalesデータベースがDRSolution構成に追加されたことを確認します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      South_Sales  - Physical standby database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
DISABLED
 
DGMGRL>

6.3 使用例2: データベース・プロパティの設定

DGMGRLを使用して構成を作成した後は、いつでもデータベース・プロパティを設定できます。

たとえば、次の文は、South_Salesスタンバイ・データベースのデータベース・プロパティLogArchiveFormatおよびStandbyArchiveLocationを設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';
Property "LogArchiveFormat" updated.

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

データベースのすべてのプロパティとその値を表示するには、SHOW DATABASE VERBOSEコマンドを使用します。次の例は、South_Salesデータベースのプロパティを示しています。

DGMGRL> SHOW DATABASE VERBOSE 'South_Sales'

Database - South_Sales

  Role:               PHYSICAL STANDBY
  Intended State:     OFFLINE
  Transport Lag:      (unknown)
  Apply Lag:          (unknown)
  Average Apply Rate: (unknown)
  Active Apply Rate:  (unknown)
  Maximum Apply Rate: (unknown)
  Real Time Query:    OFF
  Instance(s):
    south_sales1

  Properties:
    DGConnectIdentifier             = 'South_Sales.example.com'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    RedoRoutes                      = ''
    DelayMins                       = '0'
    Binding                         = 'OPTIONAL'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '0'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = 'AUTO'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '5'
    LogArchiveMinSucceedDest        = '1'
    DataGuardSyncLatency            = '0'
    DbFileNameConvert               = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
    LogFileNameConvert              = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    PreferredObserverHosts          = ''
    StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=south_sales1.example.com)(PORT=2879))
(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
    StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
    AlternateLocation               = ''
    LogArchiveTrace                 = '255'
    LogArchiveFormat                = 'db2r_%d_%t_%s_%R.arc'
    TopWaitEvents                   = '(monitor)'

  Log file locations:
    Unknown

Database Status:
DISABLED

データベースのブローカ管理が有効な場合は、データベース・プロパティ値を設定すると、対応するデータベースの基礎となるパラメータ値が変更され、変更されたパラメータの値がサーバー・パラメータ・ファイルに反映されます。したがって、データベースがOracle Enterprise Manager Cloud Control (Cloud Control)およびDGMGRL以外(SQL*Plusインタフェースなど)から停止および再起動された場合は、更新されたサーバー・パラメータ・ファイルの新規パラメータ値がデータベースの起動時に使用されます。ただし、SQL文を使用してREDO転送サービスの初期化パラメータを変更しないでください。それを行うと、データベースとブローカ間の一貫性が失われます。

注意:

通常、データベース・プロパティは、対応する初期化パラメータ、SQL文またはPL/SQLプロシージャ(通常は大文字)と視覚的に区別しやすいように、大/小文字混合表記(LogArchiveFormatなど)で表示されます。ただし、プロパティ管理コマンドでは大/小文字は区別されないため、大文字、小文字または混合表記でコマンドを発行できます。

プロパティは、データベースが有効な場合でも無効な場合でも変更できます。ただし、プロパティの変更時にデータベースが無効な場合、変更結果はデータベースが有効化されるまで有効になりません。

6.4 使用例3: 構成とデータベースの有効化

これまでDRSolution構成は無効化されており、Data Guard Brokerの制御下にはありませんでした。

ブローカ構成に対するデータベースの構成および必要なデータベース・プロパティの設定を完了した後に、構成を有効化してData Guard Brokerで管理できるようにする必要があります。

次のいずれかを有効化できます。

  • すべてのデータベースを含む構成全体

  • スタンバイ・データベース

構成全体の有効化

次のコマンドを使用すると、すべてのデータベースを含む構成全体を有効化できます。

DGMGRL> ENABLE CONFIGURATION;
Enabled.

構成を表示します

SHOWコマンドを使用して、構成とそのデータベースが正常に有効化されていることを確認します。

DGMGRL> SHOW CONFIGURATION;

DGMGRLは次の情報を戻します。

Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      South_Sales  - Physical standby database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

データベースの有効化

この手順は、前にDISABLE DATABASEコマンドを使用してスタンバイ・データベースを無効化している場合にのみ実行します。通常は、構成を有効化するとスタンバイ・データベースも有効化されます。

DGMGRL> ENABLE DATABASE 'South_Sales';
Enabled.

データベースの表示

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:       1.54 MByte/s
  Real Time Query:  OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

6.5 使用例4: 構成保護モードの設定

構成の保護モードはいつでも変更できます。

注意:

保護モードを最大パフォーマンス・モードから最大保護モードへは変更できません。まず保護モードを最大可用性に変更してから、最大保護モードに変更します。

保護モードを変更する場合、プライマリ・データベースの再起動は不要です。

この使用例では、構成の保護モードをMAXAVAILABILITYモードに設定します。この保護モードに設定するには、少なくとも1つのスタンバイ・データベースをスタンバイREDOログ・ファイルを使用するように構成し、同期またはFASTSYNCモードを介してREDOを受け取る必要があります。スタンバイが遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTYSYNCモードでREDOを受け取り、スタンバイはASYNCモードで遠隔同期インスタンスからREDOを受け取る必要があります。

  1. スタンバイREDOログ・ファイルを構成します(必要な場合)。

    保護モードをMAXAVAILABILITYモードに設定するため、スタンバイ・データベースに十分なスタンバイREDOログ・ファイルが構成されていることを確認する必要があります。REDO転送の設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

  2. REDO転送モードを適切に構成します。

    スタンバイがプライマリ・データベースから直接REDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るようにスタンバイを構成します。スタンバイが遠隔同期インスタンスを介してプライマリREDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように遠隔同期インスタンスを構成し、遠隔同期インスタンスからASYNCモードでREDOを受け取るようにスタンバイを構成します。次に例を示します。

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

    スタンバイREDOログ・ファイルを使用するように構成されたスタンバイ・データベースが構成内に含まれていないかぎり、このコマンドは正常終了しません。

  3. 構成全体の保護モードを変更します。

    EDIT CONFIGURATIONコマンドを使用して、ブローカ構成の保護モードをMAXAVAILABILITYにアップグレードします。

    DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
    Succeeded.
    

    このコマンドを入力したときに構成が無効な場合、実際の保護モードの変更は、ENABLE CONFIGURATIONコマンドで構成が有効化されるまで適用されません。保護モードの要件をサポートできるスタンバイ・データベースが構成内に存在しない場合、構成は有効化できません。

  4. 保護モードが変更されたことを確認します。

    SHOW CONFIGURATIONコマンドを使用して構成の現在の保護モードを表示します。

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

6.6 使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定

プライマリ・データベースとスタンバイ・データベースが地理的に遠すぎて同期転送モードが実用的でない場合、遠隔同期インスタンスを最大可用性保護モードで使用することができます。

このトピックの例は、遠隔同期インスタンスを構成に追加し、構成のすべてのメンバーに対してRedoRoutesプロパティを設定する方法を示しています。遠隔同期インスタンスに対してRedoRoutesプロパティを設定すると、North_SalesデータベースとSouth_Salesデータベースのいずれかプライマリである方に基づいてREDOデータを送信できます。

  1. ブローカ構成にFSという名前の遠隔同期インスタンスを追加するには、次のコマンドを発行します。
    DGMGRL> ADD FAR_SYNC 'FS' AS CONNECT IDENTIFIER IS FS.EXAMPLE.COM;
    DGMGRL> ENABLE FAR_SYNC 'FS';
    DGMGRL> SHOW CONFIGURATION;
      
    Configuration - DRSolution
     
      Protection Mode: MaxPerformance
      Members:
      North_Sales - Primary database
        South_Sales - Physical standby database
        FS - Far Sync
     
    Fast-Start Failover: DISABLED
     
    Configuration Status:
    SUCCESS
    

    この出力で、South_SalesFSは、North_Salesの配下にインデントされています。これは、プライマリがREDOデータをSouth_SalesFSの両方に送信していることを示します。

  2. 次のコマンドを発行して、North_Salesがプライマリである場合、現在のプライマリ(North_Sales)が遠隔同期インスタンスだけにREDOデータを送信し、遠隔同期インスタンスがREDOデータをSouth_Salesに送信するようにします。
    DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes='(LOCAL : FS SYNC)';
    DGMGRL> EDIT FAR_SYNC 'FS' SET PROPERTY RedoRoutes='(North_Sales : South_Sales');
    DGMGRL> SHOW CONFIGURATION;
     
    DGMGRL> SHOW CONFIGURATION;
     
    Configuration - DRSolution
     
      Protection Mode: MaxPerformance
      Members:
      North_Sales - Primary database
        FS - Far Sync
          South_Sales - Physical standby database
     
    Fast-Start Failover: DISABLED
     
    Configuration Status:
    SUCCESS
    

    上の出力のインデント方式は、North_SalesがREDOデータをFSに送信し、FSがREDOデータをSouth_Salesに送信することを示しています。

  3. 保護モードを最大可用性にアップグレードするには、次のコマンドを発行します。
    DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
    DGMGRL> SHOW CONFIGURATION;
     
    Configuration - DRSolution
     
      Protection Mode: MaxAvailability
      Members:
      North_Sales - Primary database
        FS - Far Sync
          South_Sales - Physical standby database
     
    Fast-Start Failover: DISABLED
     
    Configuration Status:
    SUCCESS

    South_Salesがプライマリに、North_Salesが遠隔同期インスタンス(FS)からREDOデータを受け取るスタンバイ・データベースになったことがある場合、RedoRoutesプロパティをSouth_Salesに設定する必要があります。さらに、South_Salesがプライマリ・データベースである場合にNorth_SalesにREDOデータを送信できるようにするには、FSRedoRoutesプロパティに新しいルールを含める必要があります。

    これらのルールが作成されていない場合、North_SalesはREDOログを受信できなくなります。適切なルールが設定されているかどうかを確認するには、SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用して、South_Salesがプライマリ・データベースであった場合にREDO転送構成がどのようになるかを確認します。次に例を示します。

    DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';
     
    Configuration when South_Sales is primary - DRSolution
     
      Members:
      South_Sales  - Primary database
        FS     - Far Sync 
          North_Sales  - Physical standby database 
     
      Members Not Receiving Redo:
      North_FS - Physical standby database
      Warning: ORA-16685: database does not receive redo data
    

    このエラーを修正するには、次のようにSouth_SalesおよびFSRedoRoutesプロパティを設定します。

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

    South_SalesおよびFSRedoRoutesプロパティを変更した後、SHOW CONFIGURATION WHEN PRIMARY ISコマンドを使用して、エラーがクリアされたことを確認します。

    DGMGRL> SHOW CONFIGURATION WHEN PRIMARY IS 'South_Sales';
     
    Configuration when South_Sales is primary - DRSolution
     
      Members:
      South_Sales  - Primary database
        FS     - Far Sync 
          North_Sales  - Physical standby database 

6.7 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動

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

ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。この項では、ファスト・スタート・フェイルオーバーを有効化し、構成の保護モードが最大可用性モードに設定されるオブザーバを起動する手順を説明します。

  1. スタンバイREDOログがプライマリ・データベースおよびターゲット・スタンバイ・データベースで構成されていることを確認します。スタンバイREDOログを構成する前に、ログ適用サービスを停止する必要があります。

    関連項目:

    スタンバイREDOログ・ファイルの構成方法は、『Oracle Data Guard概要および管理』を参照してください。

  2. 遠隔同期インスタンスを介してではなく直接REDOを受け取る場合、プライマリ・データベースとスタンバイ・データベースを、SYNCまたはFASTSYNCモードでREDOを受け取るように構成します。いずれかのデータベースが遠隔同期インスタンスを介してREDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように遠隔同期インスタンスを構成し、遠隔同期インスタンスからASYNCモードでREDOを受け取るようにデータベースを構成します。次に例を示します。
    DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';
    Property "LogXptMode" updated
    
    DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
    Property "LogXptMode" updated
    

    データベースがスタンバイREDOログ・ファイルで構成されていないかぎり、ブローカではこれらのコマンドが正常終了しません。

  3. 2つ以上のスタンバイ・データベースがある場合、プライマリ・データベースのFastStartFailoverTarget構成プロパティを設定して目的のターゲット・スタンバイ・データベースを指定します。ファスト・スタート・フェイルオーバーが実際に有効化される際、ブローカにより、今度は反対にターゲット・スタンバイ・データベースのこのプロパティが将来のターゲット・スタンバイ・データベースとしてプライマリ・データベースを指すように設定されます。このプロパティは自動的に設定されるため、ターゲット・スタンバイ・データベースでこのプロパティを設定する必要はありません。次に例を示します。
    DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
    Property "FastStartFailoverTarget" updated
    
  4. 保護モードのアップグレードが必要な場合、次のDGMGRL EDIT CONFIGURATIONコマンドを使用します。次に例を示します。
    DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
    
  5. プライマリ・データベースおよびスタンバイ・データベースでまだ有効化されていない場合、各データベース上で次の文を発行し、「データベースをフラッシュバック」を有効にします。
    ALTER SYSTEM SET UNDO_RETENTION=3600 SCOPE=SPFILE;
    ALTER SYSTEM SET UNDO_MANAGEMENT='AUTO' SCOPE=SPFILE;
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    SHOW PARAMETER UNDO;
    ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;
    ALTER DATABASE ARCHIVELOG;
    ALTER SYSTEM SET db_recovery_file_dest_size=<size>;
    ALTER SYSTEM SET db_recovery_file_dest=<directory-specification>;
    ALTER DATABASE FLASHBACK ON;
    ALTER DATABASE OPEN;
    

    長時間の停止後でも回復が可能となるように、UNDO_RETENTIONおよびDB_FLASHBACK_RETENTION_TARGET初期化パラメータが十分に大きな値に設定されていることを確認します。

  6. オブザーバ(最大3つ)を起動するには、オブザーバ・コンピュータにログインし、DGMGRLを実行します。SYSDGまたはSYSDBA権限を持つユーザーとして構成に接続し、START OBSERVERコマンドを発行します。このコマンドでは戻り値がない点に注意してください。つまり、コマンドを発行してもDGMGRLプロンプトを取得しません。
    DGMGRL> CONNECT sysdg@North_Sales.example.com;
    Password: password
    Connected to "North_Sales"
    Connected as SYSDG.
    
    DGMGRL> START OBSERVER observer1 IN BACKGROUND
    > FILE IS /net/sales/dat/oracle/broker/fsfo.dat
    > LOGFILE IS /net/sales/dat/oracle/broker/observer.log
    > CONNECT IDENTIFIER IS North_Sales
    Submitted command "START OBSERVER" using connect identifier "North_Sales"
    

    セキュリティ上の理由から、このコマンド形式の使用をお薦めします。資格証明は表示されません。この処理により、システムの他のユーザーがユーティリティ(UNIXのpsユーティリティなど)を使用して接続資格証明を表示することを回避できます。また、クリアテキストのパスワードがユーザーの端末に表示されるのを防ぐことができます。

    スクリプトからオブザーバを起動する場合、データベース接続資格証明をスクリプト内に埋め込まなくてすむように、「connect/」をサポートする方法を使用することをお薦めします。クライアント側のOracleウォレットをセキュアな外部パスワード・ストアとして使用する場合(『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照)、プライマリ・データベースおよびファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースの資格証明を追加する必要があります。各データベースの資格証明を追加するとき、指定するデータベース接続文字列は、データベース・プロパティObserverConnectIdentiferまたはDGConnectIdentifierと一致している必要があります。

    複数のオブザーバを起動する場合、ファスト・スタート・フェイルオーバーが有効化されると、1つのオブザーバがマスター・オブザーバに、残りのオブザーバがバックアップ・オブザーバになります。Data Guard Brokerでファスト・スタート・フェイルオーバーを調整できるのはマスター・オブザーバのみです。プライマリ・データベースとターゲット・スタンバイ・データベースの間の接続が維持された状態でマスター・オブザーバからの接続が失われた場合、ブローカは、バックアップ・オブザーバを新しいマスター・オブザーバに指定しようとします。

  7. ファスト・スタート・フェイルオーバーを有効にします。ブローカ構成のデータベースに接続されている間は、ファスト・スタート・フェイルオーバーを有効化できます。次に例を示します。
    DGMGRL> ENABLE FAST_START FAILOVER;
    Enabled.
    
  8. ファスト・スタート・フェイルオーバー構成を検証します。SHOW FAST_START FAILOVERコマンドを使用して、ファスト・スタート・フェイルオーバーの設定を表示します。
    DGMGRL> SHOW FAST_START FAILOVER;
     
    Fast-Start Failover: DISABLED
     
      Threshold: 30 seconds
      Target: South_Sales
      Observer: observer.example.com
      Lag Limit: 30 seconds (not in use)
      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)
    

    次のコマンドは、ファスト・スタート・フェイルオーバーが有効化された後、相互に指定しあうようにFastStartFailoverTargetプロパティが設定されることを示しています。最初のコマンドは現在のプライマリ・データベースNorth_Salesに対して発行されており、FastStartFailoverTargetプロパティの値として現在のターゲット・スタンバイSouth_Salesを指定しています。2つめのコマンドはターゲット・スタンバイSouth_Salesに対して発行されており、プライマリとして引き継ぐ際、ターゲット・スタンバイの将来のターゲット・スタンバイとして現在のプライマリNorth_Salesを指定しています。

    DGMGRL> SHOW DATABASE 'North_Sales' FastStartFailoverTarget;
     FastStartFailoverTarget='South_Sales';
     
    DGMGRL> SHOW DATABASE 'South_Sales' FastStartFailoverTarget;
     FastStartFailoverTarget='North_Sales';

6.8 使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化

ファスト・スタート・フェイルオーバーのターゲットが、遠隔同期インスタンスからREDOデータを受け取る論理またはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。

遠隔同期インスタンスを使用してREDOデータをスタンバイ・データベースに送信している場合にファスト・スタート・フェイルオーバーを有効にするには、次のようにして、先にプライマリおよびターゲット・スタンバイ・データベース上でFastStartFailoverTargetプロパティを設定する必要があります。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales';
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY FastStartFailoverTarget='North_Sales';

その場合、次のようにしてファスト・スタート・フェイルオーバーを有効化できます。

DGMGRL> ENABLE FAST_START FAILOVER;

遠隔同期インスタンス・データベースが、North_SalesSouth_Salesのファスト・スタート・フェイルオーバー・ターゲットとして指定されていない点に注意してください。

6.9 使用例8: 定期的な管理タスクの実施

1つ以上のデータベースの定期的なメンテナンスを実行するために、ブローカ構成に含まれるデータベースの状態やプロパティの変更が必要になる場合があります。

また、構成に含まれるデータベースのブローカ管理を一時的に無効化する必要が生じる場合もあります。

6.9.1 プロパティと状態の変更

構成の監視中に、データベースやそのプロパティの状態を動的に変更する操作が必要になる場合があります。

次の各トピックで、構成内のデータベースの状態またはプロパティを変更する方法について説明します。

6.9.1.1 データベース・プロパティの変更

データベース・プロパティの値は、データベースが有効か無効かに関係なくいつでも変更できます。

次の例は、EDIT DATABASEコマンドを使用してNorth_Salesデータベースのデータベース・プロパティLogXptModeを値ASYNCに変更する方法を示しています。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'=ASYNC;

DGMGRLは次のメッセージを戻します。このメッセージは、LogXptModeプロパティがData Guard構成ファイル内で正常に更新されたことを示します。

Property "LogXptMode" updated 

構成が現在無効の場合は、ENABLE CONFIGURATIONコマンドでブローカ構成を有効化するまで、データベースで新規プロパティ値が使用されません。

6.9.1.2 デフォルト値へのプロパティのリセット

データベースや構成が有効/無効のいずれの場合も、構成や設定可能なプロパティを、いつでもそのデフォルト値にリセットできます。

次の例は、EDIT DATABASEコマンドを使用してLogXptModeデータベースの設定可能なプロパティをNorth_Salesデータベースのデフォルト値にリセットする方法を示しています。

EDIT DATABASE 'North_Sales' RESET PROPERTY LogXptMode;

次の例は、EDIT CONFIGURATIONコマンドを使用してTraceLevel構成プロパティをデフォルト値にリセットする方法を示しています。

EDIT CONFIGURATION RESET PROPERTY TraceLevel;
6.9.1.3 スタンバイ・データベースの状態変更

フィジカル・スタンバイのREDO Applyを一時的に停止できます。

スタンバイ・データベースの状態をAPPLY-OFFに変更するには、次の例のようにEDIT DATABASEコマンドを入力します。

DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-OFF';
Succeeded.

フィジカル・スタンバイ・データベースをAPPLY-OFF状態にしても、REDOデータは引き続き受信されます。

6.9.1.4 プライマリ・データベースの状態変更

スタンバイ・データベースへのREDOデータの転送を停止できます。

これに対応してプライマリ・データベースの状態を変更するには、次のコマンドを使用します。

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

プライマリ・データベースの状態をTRANSPORT-ONに戻すには、次のコマンドを使用します。

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

6.9.2 構成とデータベースの無効化

ブローカ構成またはそのデータベースのいずれかを無効化すると、それらのブローカによる管理が無効化されるため、DGMGRLを使用してそれらを管理および監視できなくなります。

ただし、ブローカによるブローカ構成の管理を無効にしても、基礎となるOracle Data Guard構成またはデータベースの実際の操作には影響しません。たとえば、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは、管理できなくなりますが、そのまま機能し続けます。

6.9.2.1 構成の無効化

プライマリ・データベースを含むブローカ構成全体の管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。

次に例を示します。

DGMGRL> DISABLE CONFIGURATION;

プライマリ・データベースのブローカ管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。DISABLE DATABASEコマンドで無効化されるのは、スタンバイ・データベースの管理のみです。同様に、DISABLE FAR_SYNCコマンドは、遠隔同期インスタンスの管理のみを無効にします。

注意:

スタンバイ・データベースまたは遠隔同期インスタンスへの接続時に構成の管理を無効化する場合、構成を再び有効化するには、プライマリ・データベース(制御ファイルのロールがプライマリであるデータベース)に接続する必要があります。

構成メンバーのブローカの管理を無効にしても、そのメンバーはブローカ構成ファイルから削除されません。該当するENABLE CONFIGURATIONまたはENABLE DATABASE コマンドを入力すると、DGMGRL (またはCloud Control)によるメンバー管理機能を再び有効化できます。

6.9.2.2 スタンバイ・データベースの無効化

ブローカによるスタンバイ・データベースの管理と監視が一時的に不要になった場合は、DISABLE DATABASEコマンドを使用します。

構成の他の部分が有効な場合は、スタンバイ・データベースが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、スタンバイ・データベースSouth_Salesを無効化する方法を示しています。

DGMGRL> DISABLE DATABASE 'South_Sales';
Disabled.

注意:

構成内のスタンバイ・データベースを無効にするとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは無効化できません。

注意:

スタンバイ・データベースへの接続中にそのスタンバイ・データベースの管理を無効化した場合は、スタンバイ・データベースのブローカ管理を再び有効化するために、プライマリ・データベースまたは別の有効化されたスタンバイ・データベースに接続する必要があります。

警告:

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

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを無効化できません。

6.9.2.3 遠隔同期インスタンスの無効化

ブローカによる遠隔同期インスタンスの管理と監視が一時的に不要になった場合は、DISABLE FAR_SYNCコマンドを使用します。

構成の他の部分が有効な場合は、遠隔同期インスタンスが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、遠隔同期インスタンスを無効化する方法を示しています。

DGMGRL> DISABLE FAR_SYNC 'FS';
Disabled.

注意:

遠隔同期インスタンスを無効にすると、次の制約が適用されます。

  • 他の構成メンバーのRedoRoutesプロパティで指定されている遠隔同期インスタンスは無効化できません。

  • 遠隔同期インスタンスに接続している間にその遠隔同期インスタンスの管理を無効にした場合、遠隔同期インスタンスのブローカ管理を再び有効化するには、プライマリ・データベースまたは別の有効なスタンバイ・データベースに接続する必要があります。

注意:

ブローカ構成で遠隔同期インスタンスのブローカ管理を無効にした場合、他の構成メンバーのRedoRoutesプロパティで、その遠隔同期インスタンスを指定することはできません。

6.9.3 構成、スタンバイ・データベースまたは遠隔同期インスタンスの削除

REMOVE CONFIGURATIONREMOVE DATABASE、またはREMOVE FAR_SYNCコマンドを使用すると、ブローカ構成ファイルから構成、スタンバイ・データベースまたは遠隔同期インスタンスが実質的に削除され、Oracle Data Guard Brokerを使用してそれらを管理できなくなります。

削除操作でPRESERVE DESTINATIONS句を使用した場合、実際のOracle Data Guard構成は削除されず、実際のOracle Data Guard構成とそのデータベースの操作には影響しません。

注意:

REMOVE CONFIGURATIONREMOVE DATABASEまたはREMOVE FAR_SYNCコマンドを使用した後で、削除したオブジェクトを再作成することに決めた場合、当初発行したコマンドを再び発行する必要があります。必要な場合は「使用例1: 構成の作成」の手順に従って、DGMGRL (またはCloud Control)で管理できるブローカ構成を作成する必要があります。

注意:

次の制限があります。

  • 構成内のスタンバイ・データベースを削除するとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは削除できません。

  • スタンバイ・データベースまたは遠隔同期インスタンスが、構成に含まれる他のメンバーのRedoRoutesプロパティで指定されている場合、それらを削除することはできません。

6.9.3.1 構成からのスタンバイ・データベースの削除

REMOVE DATABASEコマンドを使用すると、ブローカによるデータベースの管理と監視が停止され、データベースがブローカ構成ファイルから削除されます。

South_Salesスタンバイ・データベースを削除する前の構成を示します。

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

DGMGRLのREMOVE DATABASEコマンドを発行して、South_Salesデータベース情報をData Guard構成ファイルから削除します。

DGMGRL> REMOVE DATABASE 'South_Sales';
Removed database "South_Sales" from the configuration

South_Salesスタンバイ・データベースを削除した後の構成を示します。

DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      FS - Far Sync
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS

最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを削除できません。

6.9.3.2 構成からの遠隔同期インスタンスの削除

Oracle Data Guard構成ファイルから遠隔同期インスタンス情報を削除するには、REMOVE FAR_SYNCコマンドを使用します。

たとえば、次のコマンドを使用して、FS遠隔同期インスタンス情報を削除します。

DGMGRL> REMOVE FAR_SYNC 'FS';
Removed far sync instance "FS" from the configuration

FS遠隔同期インスタンスを削除した後の構成を示します。

DGMGRL> SHOW CONFIGURATION;
 
Configuration - DRSolution
 
Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
SUCCESS
6.9.3.3 ブローカ構成の削除

DGMGRL REMOVE CONFIGURATIONコマンドを使用すると、構成全体がブローカによって管理および監視されなくなります。

次に例を示します。

DGMGRL> REMOVE CONFIGURATION;

注意:

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

DGMGRLは次のメッセージを戻します。このメッセージは、コマンドによりData Guard構成ファイルからすべての構成情報が正常に削除されたことを示します。

Removed configuration
 
DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard broker configuration does not exist
 
Configuration details cannot be determined by DGMGRL

6.10 使用例9: スイッチオーバー操作の実行

プライマリ・データベースとスタンバイ・データベースのロールは、SWITCHOVERコマンドを使用して切り替えることができます。

SWITCHOVERコマンドを発行する前に、次のことを確認する必要があります。

  • プライマリ・データベースとスタンバイ・データベースの状態がそれぞれTRANSPORT-ONおよびAPPLY-ONであること。

  • 関係するすべてのデータベースが健全な状態で、エラーや警告がないこと。

  • スタンバイ・データベースのプロパティがプライマリ・データベース上で設定されていること。これにより、プライマリ・データベースはスタンバイ・データベースへ遷移するときに正常に機能できます(次の例の太字表記を参照してください)。

  • プライマリ・データベースでスタンバイREDOログ・ファイルが構成されています。

  • 構成が最大可用性モードの場合、現在のプライマリは、新しいプライマリから直接REDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように構成されます。遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTSYNCモードでREDOを受け取るように構成され、現在のプライマリはASYNCモードでREDOを受け取るように構成されます。構成が最大保護モードの場合、現在のプライマリは、SYNCモードでREDOを受け取るように構成されます。

  • ファスト・スタート・フェイルオーバーが有効化されている場合は、ターゲット・スタンバイ・データベースとして指定されたスタンバイ・データベースへのスイッチオーバーのみ実行できる。

SWITCHOVERコマンドを使用してスイッチオーバーを実行するために必要なタスクは次のとおりです。

6.10.1 SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック

SHOW DATABASE VERBOSEコマンドを使用して、プライマリ・データベースの状態、健全性およびプロパティをチェックします。

次に例を示します。

SHOW DATABASE VERBOSE 'North_Sales';

Database - North_Sales

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

  Properties:
    DGConnectIdentifier             = 'North_Sales.example.com'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    RedoRoutes                      = ''
    DelayMins                       = '0'
    Binding                         = 'optional'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyLagThreshold               = '0'
    TransportLagThreshold           = '0'
    TransportDisconnectedThreshold  = '0'
    ApplyParallel                   = 'AUTO'
    ApplyInstances                  = '0'
    StandbyFileManagement           = 'AUTO'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '5'
    LogArchiveMinSucceedDest        = '1'
    DataGuardSyncLatency            = '0'
    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'
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    PreferredObserverHosts          = ''
    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)))'
    StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
    AlternateLocation               = ''
    LogArchiveTrace                 = 255
    LogArchiveFormat                = 'db1r_%d_%t_%s_%R.arc'
    TopWaitEvents                   = '(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

特に、プライマリ・データベースの太字のプロパティおよび現在のステータスをチェックする必要があります。

6.10.2 SWITCHOVERコマンドの使用(タスク2): スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック

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: 1.44 MByte/s
  Real Time Query: OFF
  Instance(s):
    south_sales1
 
Database Status:
SUCCESS

6.10.3 SWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認

ロール変更を実行する前に、VALIDATE DATABASEコマンドを使用して、データベースがロール変更に即時対応可能かどうかを確認する、一連の徹底チェックを実行することができます。

この手順に示す例では、DRSolution構成の3つのデータベース(プライマリ、ロジカル・スタンバイおよびフィジカル・スタンバイの各データベース)すべてにVALIDATE DATABASEコマンドを使用しています。構成は次のようになります。

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

例: プライマリ・データベースの検証

DGMGRL> VALIDATE DATABASE 'North_Sales';
 
  Database Role:    Primary database
 
  Ready for Switchover:  Yes

例: ロジカル・スタンバイ・データベースの検証

次のようにしてロジカル・スタンバイ・データベースを検証します。

DGMGRL> VALIDATE DATABASE 'West_Sales';
 
  Database Role:     Logical standby database
  Primary Database:  North_Sales
 
  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)
    Warning: Physical and snapshot standby databases will
    be disabled if a role change is performed to this database

例: フィジカル・スタンバイ・データベースの検証

次のようにしてフィジカル・スタンバイ・データベースを検証します。

DGMGRL> VALIDATE DATABASE 'South_Sales';
 
  Database Role:     Physical standby database
  Protection Mode:   MaxAvailability
    Error: Switchover to this standby is not possible since there
    are no other standbys that can support the protection mode
 
  Primary Database:  North_Sales
 
  Ready for Switchover:  No
  Ready for Failover:    Yes (Primary Running)
 
  Transport-Related Property Settings:
    Property                        North_Sales Value        South_Sales Value
    LogXptMode                      ASYNC                    SYNC

構成保護は最大可用性モードに設定されており、データベースSouth_Salesのみ、LogXptModeプロパティがSYNCに設定されているため、スイッチオーバーできないことを示すエラーが表示されます。データベースが、RedoRoutesプロパティが転送モードに構成されているデータベースまたは遠隔同期インスタンスからREDOを受け取る場合、そのモードがLogXptModeで指定されている転送モードを上書きする点に注意してください。

6.10.4 SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行

SWITCHOVERコマンドを発行して、プライマリ・データベースとスタンバイ・データベースのロールを交換します。

次の例では、ブローカが、元のプライマリ・データベースの停止および再起動を、スイッチオーバーの一部として自動的に実行する方法を示します。(DGMGRLによってプライマリ・データベースとスタンバイ・データベースが自動的に再起動されるようにブローカ環境を設定する方法は、DGMGRLコマンドの使用上の注意を参照してください。)

DGMGRL> SWITCHOVER TO 'South_Sales';
Performing switchover NOW, please wait...
Operation requires a connection to instance "south_sales1" on database "South_Sales"
Connecting to instance "south_sales1"...
Connected as SYSDBA.
New primary database "South_Sales" is opening...
Operation requires startup of instance "north_sales1" on database "North_Sales"
Starting instance "north_sales1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "South_Sales"

スイッチオーバーの完了後、SHOW CONFIGURATIONおよびSHOW DATABASEコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。

6.10.5 SWITCHOVERコマンドの使用(タスク5): 構成の表示

SHOW CONFIGURATIONコマンドを使用して、スイッチオーバーが正常終了したことを確認します。

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

6.11 使用例10: 手動フェイルオーバー操作の実行

フェイルオーバー操作は、緊急時(通常はプライマリ・データベースにアクセスできない場合または使用できない場合)の対応策として起動します。

フェイルオーバー前にターゲット・スタンバイ・データベースの選択を参照し、どのスタンバイ・データベースをフェイルオーバーのターゲットにするかを判断してください。次の使用例では、リモート・データベースSouth_Salesへのフェイルオーバーについて説明します。

注意:

ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーのターゲットとして指定されているスタンバイ・データベースにかぎり、またオブザーバが実行中で現在スタンバイ・データベースと接続されている場合のみ、手動フェイルオーバーを実行できます。

ファスト・スタート・フェイルオーバーのターゲットではないスタンバイ・データベースへの手動フェイルオーバーを実行する場合は、まずフェイルオーバー先のスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にする必要があります。FORCEオプションの詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。

  1. (オプション)ターゲット・スタンバイの準備状況の確認。

    ターゲット・スタンバイ・データベースを検証し、新しいプライマリ・データベースになる準備ができていることを確認するには、次の例に示すように、VALIDATE DATABASEコマンドを使用します。

    DGMGRL> VALIDATE DATABASE 'South_Sales';
     
    Database Role: Physical standby database
    Primary Database: South_Sales
     
    Ready for Switchover: Yes
    Ready for Failover: Yes
    
  2. フェイルオーバー操作を実行するには、SYSDGまたはSYSDBA権限を持つユーザーとしてフェイルオーバー先のスタンバイ・データベースに接続する必要があります。次に例を示します。
    DGMGRL> CONNECT sysdg@South_Sales.example.com;
    Password: password
    Connected to "South_Sales"
    Connected as SYSDG.
    
  3. フェイルオーバー・コマンドを発行すると、ターゲットのスタンバイ・データベースを構成の新しいプライマリ・データベースにできます。
    DGMGRL> FAILOVER TO 'South_Sales';
    Performing failover NOW, please wait...
    Failover succeeded, new primary is "South_Sales"
    

    フェイルオーバーの完了後は、「ロール変更後の無効化されたデータベースの再有効化」の説明に従って回復または再作成しないかぎり、元のプライマリ・データベースは新しいプライマリ・データベースのスタンバイ・データベースとして使用できないことに注意してください。

  4. SHOW CONFIGURATIONコマンドを発行してフェイルオーバーを確認します。
    DGMGRL> SHOW CONFIGURATION;
     
    Configuration - DRSolution
     
      Protection Mode: MaxAvailability
      Members:
        South_Sales  - Primary database
          Warning: ORA-16629: database reports a different protection level from the protection mode
     
          North_Sales - Physical standby database (disabled)
            ORA-16661: the standby database needs to be reinstated
     
    Fast-Start Failover: DISABLED
     
    Configuration Status:
    WARNING
    

    この例では、構成は最大可用性モードで動作していました。フェイルオーバーの後、保護モードは保持されました。構成では、警告ステータスも表示されています。新しいプライマリのSHOW DATABASEコマンドにより、有効なフィジカル・スタンバイ・データベースがないために警告が発生したことがわかります。その結果、警告ステータスは、構成の保護レベルと構成済のモードが同じでないことを示しています。

  5. 新しいプライマリ・データベースを表示します。
    DGMGRL> SHOW DATABASE South_Sales;
    Database - South_Sales
     
      Role:            PRIMARY
      Intended State:  TRANSPORT-ON
      Instance(s):
        south_sales1
     
      Database Warning(s):
        ORA-16629: database reports a different protection level from the protection mode
     
    Database Status:
    WARNING
    
  6. SHOW DATABASEコマンドを発行し、フェイルオーバーの結果として(障害が発生した)元のプライマリ・データベースがブローカにより無効化されたことを確認します。これは、「ロール変更後の無効化されたデータベースの再有効化」で説明されている手順に従って回復する必要があります。
    DGMGRL> SHOW DATABASE 'North_Sales';
    Database - North_Sales
     
      Role: PHYSICAL STANDBY
      Intended State: APPLY-ON
      Transport Lag: (unknown)
      Apply Lag: (unknown)
      Apply Rate: (unknown)
      Real Time Query: OFF
      Instance(s):
        north_sales1
     
    Database Status:
    ORA-16661: the standby database needs to be reinstated

6.12 使用例11: 障害が発生したプライマリ・データベースの回復

前のプライマリ・データベースがフラッシュバック・データベースを使用して構成された場合は、障害が発生したプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとしてすぐに回復できます。

障害が発生したプライマリ・データベースは、元のスタンバイ・データベースと同じスタンバイ・タイプとして回復します。たとえば、フィジカル・スタンバイ・データベースへのフェイルオーバーであった場合、元のプライマリはフィジカル・スタンバイ・データベースとして回復されます。

障害が発生したプライマリ・データベースを回復するには、データベースを起動してマウントされた状態にします。次に、DGMGRLを実行し、新しいプライマリ・データベースに接続して元のプライマリ・データベースを回復します。

  1. 元のプライマリ・データベースの再起動
    % dgmgrl connect sysdg
    Password: password
    Connected to "North_Sales"
    Connected as SYSDG.
    
    DGMGRL> startup mount;
    ORACLE instance started.
    Database mounted.
    
  2. 元のプライマリ・データベースを回復します。
    % dgmgrl connect sysdg
    Password: password
    Connected to "North_Sales"
    Connected as SYSDG.
    
    DGMGRL> REINSTATE DATABASE 'North_Sales';
    Reinstating database "North_Sales", please wait...
    Reinstatement of database "North_Sales" succeeded
     
    Database dismounted.
    ORACLE instance shut down.
    Operation requires startup of instance "north_sales1" on database "North_Sales"
    Starting instance "north_sales1"...
    ORACLE instance started.
    Database mounted.
    Continuing to reinstate database "North_Sales" ...
    Reinstatement of database "North_Sales" succeeded
    

    プライマリの回復が完了したら、SHOW CONFIGURATIONコマンドおよびSHOW DATABASEコマンドを発行して、元のプライマリが正常に回復したことを確認してください。

  3. 構成および構成メンバーを表示します。
    DGMGRL> SHOW CONFIGURATION
     
    Configuration - DRSolution
     
      Protection Mode: MaxAvailability
      Members:
        South_Sales  - Primary database
          North_Sales  - Physical standby database
     
    Fast-Start Failover: DISABLED
     
    Configuration Status:
    SUCCESS
    
    DGMGRL> SHOW DATABASE 'South_Sales';
     
    Database - South_Sales
     
      Role:            PRIMARY
      Intended State:  TRANSPORT-ON
      Instance(s):
        south_sales1
     
    Database Status:
    SUCCESS
     
    DGMGRL> SHOW DATABASE 'North_Sales'
     
    Database - 'North_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: 0 Byte/s
      Real Time Query: OFF
      Instance(s):
        north_sales1
     
    Database Status:
    SUCCESS

6.13 使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換

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

データベースがスナップショット・スタンバイ・データベースとして動作中の間は、REDOデータはデータベースで引き続き受信されますが、スナップショット・スタンバイ・データベースが元のフィジカル・スタンバイ・データベースに変換されるまでREDOデータは適用されません。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フィジカル・スタンバイ・データベースをファスト・リカバリ領域で構成する必要があります。これは、変換プロセス中に作成される保証付きリストア・ポイントにファスト・リカバリ領域が必要であるためです。

DGMGRL> convert database 'South_Sales' to snapshot standby;
Converting database "South_Sales" to a Snapshot Standby database, please wait...
Database "South_Sales" converted successfully

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

データベースを元のフィジカル・スタンバイ・データベースに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを再び使用します。スナップショット・スタンバイ・データベースとして動作中にデータベースに加えられた更新はすべて破棄されます。データベースが元のフィジカル・スタンバイ・データベースに変換されると、REDO Applyサービスによって、すべての累積REDOデータが適用されます。

DGMGRL> CONVERT DATABASE 'South_Sales' to PHYSICAL STANDBY;
 
Converting database "South_Sales" to a Physical Standby database, please wait...
Operation requires shutdown of instance "south_sales1" on database "South_Sales"
Shutting down instance "south_sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "south_sales1" on database "South_Sales"
Starting instance "south_sales1"...
ORACLE instance started.
Database mounted.
Continuing to convert database "South_Sales" ...
Database "South_Sales" converted successfully

6.14 使用例13: Data Guard構成の監視

次の手順では、SHOWコマンドとデータベースの監視可能なプロパティを使用し、障害状況を識別して解決するために必要なタスクを示します。

6.14.1 構成の監視(タスク1): 構成のステータス・チェック

ブローカ構成のステータスは、ブローカ構成のすべてのデータベースとインスタンスのステータスが集計されたものです。

最初に構成ステータスをチェックすると、さらに処置が必要かどうかを判断できます。構成ステータスがSUCCESSの場合は、ブローカ構成全体が正常に動作しています。一方、WARNINGまたはERRORステータスが表示される場合は、構成の一部に問題があることを意味します。

たとえば、次の例は、プライマリ・データベースに複数の警告があることを示しています。

DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
 
  Protection Mode: MaxPerformance
  Members:
    North_Sales  - Primary database
      Warning: ORA-16809: multiple warnings detected for the database
 
      South_Sales  - Physical standby database
 
Fast-Start Failover: DISABLED
 
Configuration Status:
WARNING

6.14.2 構成の監視(タスク2): データベースのステータス・チェック

プライマリ・データベースの警告を確認するには、SHOW DATABASEコマンドを使用してステータスを表示します。

次に例を示します。

DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales
 
  Role:            PRIMARY
  Intended State:  TRANSPORT-ON
  Instance(s):
    north_sales1
      Warning: ORA-16737: the redo transport service for standby "South_Sales" has an error
      Warning: ORA-16714: the value of property LogArchiveTrace is inconsistent with the database setting
      Warning: ORA-16715: redo transport-related property ReopenSecs of standby
 database "South_Sales" is inconsistent

Database Status:
WARNING

6.14.3 構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック

手順2のSHOW DATABASEの出力には、エラーORA-16737の警告が示されています。

正確な転送エラーを確認するには、監視可能なプロパティLogXptStatusを使用します。

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

出力は、フィジカル・スタンバイ・データベースのリスナーが実行されていないことを示しています。このエラーを修正するには、フィジカル・スタンバイ・データベースSouth_Salesのリスナーを起動します。

6.14.4 構成の監視(タスク4): 監視可能なプロパティInconsistentPropertiesのチェック

手順2のSHOW DATABASEの出力には、エラーORA-16714の警告が示されています。正確なエラーを確認するには、監視可能なプロパティInconsistentPropertiesを使用します。

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentProperties';
INCONSISTENT PROPERTIES
 INSTANCE_NAME  PROPERTY_NAME   MEMORY_VALUE SPFILE_VALUE BROKER_VALUE
 north_sales1   LogArchiveTrace 511          255          255

現在のデータベース・メモリー値(511)が、サーバー・パラメータ・ファイル(SPFILE)の値(255)ともOracle Data Guard Brokerのプロパティ値(255)とも異なっています。データベース・メモリー値が正しいと判断した場合は、次のコマンドを使用してOracle Data Guard Brokerのプロパティ値を更新できます。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'=511;
Property "LogArchiveTrace" updated

このコマンドを発行すると、LogArchiveTraceの値の一貫性が保たれるようにサーバー・パラメータ・ファイル(SPFILE)の値が更新されます。

6.14.5 構成の監視(タスク5): 監視可能なプロパティInconsistentLogXptPropsのチェック

REDO転送のデータベース・プロパティReopenSecsについて一貫性のない値を識別するには、監視可能なプロパティInconsistentLogXptPropsを使用します。

これは、たとえば手順2のSHOW DATABASEの出力に示された警告がORA-16715の場合に役立ちます。

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

現行のデータベース・メモリー値(600)は、Oracle Data Guard Brokerのプロパティ値(300)と一致しません。ブローカのプロパティ値が正しいと判断した場合は、次の例に示すように、スタンバイ・データベースのプロパティを同じ値で再編集して一貫性のある値にできます。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ReopenSecs'=300;
Property "ReopenSecs" updated

スタンバイ・データベースを再び有効化するか、プライマリ・データベースの状態をTRANSPORT-ONにリセットして、非一貫性を解決することもできます。

6.15 使用例14: ブローカ構成へのリカバリ・アプライアンスの追加

これらの手順では、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)をブローカ構成に追加する方法について説明します。

関連項目:

リカバリ・アプライアンスをフィジカル・スタンバイのREDO接続先として設定する方法の例は、「例4-6」を参照

  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