日本語PDF
  1. 高可用性概要およびベスト・プラクティス
  2. Oracle Data Guardのベスト・プラクティス
  3. Oracle Data Guard構成の監視

16 Oracle Data Guard構成の監視

Oracle Data Guard構成を監視するには、次のOracle MAAベスト・プラクティスの推奨事項を使用します。

ブローカを使用したOracle Data Guard構成ヘルスの監視

Oracle Data Guard Brokerは、ヘルス・チェックを1分に1回発行し、構成ステータスを更新します。ヘルス・チェックをすぐに強制的に実行するには、コマンドshow configuration verboseを実行します。

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

  • データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
  • データベースが正しいデータ保護モードであるかどうか。
  • データベースでサーバー・パラメータ・ファイル(SPFILE)が使用されているかどうか
  • データベースがARCHIVELOGモードであるかどうか。
  • REDO転送サービスにエラーがあるかどうか。
  • データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
  • REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。
  • 現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。
  • プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。

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

  • データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
  • データベースでサーバー・パラメータ・ファイル(SPFILE)が使用されているかどうか
  • データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
  • ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。

構成全体の警告を確認するには、SHOW CONFIGURATIONコマンドを使用してステータスを表示します。 

DGMGRL> show configuration;

Configuration – dg

  Protection Mode: MaxPerformance
  Members:
  tin - Primary database
    can - Physical standby database 

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 18 seconds ago)

構成ステータスがSUCCESSの場合は、ブローカ構成全体が正常に動作しています。

一方、WARNINGまたはERRORステータスが表示される場合は、構成の一部に問題があることを意味します。追加のエラー・メッセージは、現在の問題を特定するのに使用するWARNINGステータスまたはERRORステータスを伴います。

次のステップでは、構成内の各データベースを調べて、特定のエラーに関連する内容を絞り込みます。

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

DGMGRL> show database tin

Database – tin

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

Database Status:
SUCCESS

データベース・ステータスがSUCCESSの場合、データベースは正常に動作しています。

一方、WARNINGまたはERRORステータスが表示される場合は、データベースの一部に問題があることを意味します。追加のエラー・メッセージは、現在の問題を特定するのに使用するWARNINGステータスまたはERRORステータスを伴います。

スタンバイ・データベースで同じSHOW DATABASEコマンドを繰り返し、エラー・メッセージを評価します。

前述のコマンドに加えて、ブローカにはVALIDATE DATABASEコマンドもあります。 

DGMGRL> validate database tin

  Database Role:    Primary database
  Ready for Switchover:  Yes

DGMGRL> validate database can;

  Database Role:     Physical standby database
  Primary Database:  tin

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

  Capacity Information:
    Database  Instances        Threads        
    tin       2                2              
    can       1                2              
    Warning: the target standby has fewer instances than the
    primary database, this may impact application performance

  Standby Apply-Related Information:
    Apply State:      Not Running
    Apply Lag:        Unknown
    Apply Delay:      0 minutes

VALIDATE DATABASEは、SUCCESSステータスまたはWARNINGステータスを提示しないため、アクションを実行する必要があるかどうかを判断するための調査が必要になります。

ブローカ構成の作成後、およびロール・トランジション操作の前後に、VALIDATE DATABASEコマンドを実行することをお薦めします。

VALIDATE DATABASEコマンドにより、次のチェックが実行されます。

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

Oracle Data Guard Brokerを使用した転送または適用ラグの検出

十分なリソース(特にネットワーク帯域幅)があれば、Oracle Data Guardスタンバイは非常に高いワークロードを維持できます。リソースが制約されている場合、スタンバイが遅れ始め、転送または適用ラグが発生する可能性があります。

転送ラグとは、スタンバイがプライマリから受信していない、時間で測定されたデータ量です。

適用ラグとは、最後に適用された変更がスタンバイで表示可能になってから、同じ変更がプライマリで最初に表示可能になるまでの時間の差(経過時間)です。

Data Guard Brokerを使用する場合、次に示すように、SHOW DATABASEコマンドを使用してスタンバイ・データベースを参照することで、転送または適用ラグを表示できます。 

DGMGRL> show database orclsb

Database – orclsb

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 792.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    orclsb1 (apply instance)
    orclsb2

Database Status:
SUCCESS

ブローカのTransportDisconnectedThresholdデータベース・プロパティ(Oracle Database 11.2ではデフォルトは0、Oracle Database 12.1以降のリリースでは30秒)は、プライマリ・データベースからの最後の通信がプロパティによって指定された値を上回ったときに、スタンバイについて警告ステータスを生成するために使用できます。プロパティ値を表す単位は秒です。

切断が発生した場合の警告の例を次に示します。

DGMGRL> show database orclsb;

Database – orclsb

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 981 seconds ago)
  Apply Lag:          0 seconds (computed 981 seconds ago)
  Average Apply Rate: 12.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    orclsb1 (apply instance)
    orclsb2

  Database Warning(s):
    ORA-16857: member disconnected from redo source for longer than specified threshold

ブローカには、転送または適用ラグがユーザー定義の値を上回ったっときに警告を生成するために使用できる、次の構成可能なデータベース・プロパティもあります。

  • ApplyLagThresholdプロパティは、データベースの適用ラグがプロパティで指定された値を上回ったときに、ロジカルまたはフィジカルのスタンバイについて警告ステータスを生成します。

    プロパティ値を表す単位は秒です。値が0秒の場合、適用ラグが存在しても警告を生成しません。ベスト・プラクティスとして、ApplyLagThresholdを15分以上に設定することをお薦めします。

  • TransportLagThresholdプロパティは、データベースの転送ラグがプロパティで指定された値を上回ったときに、ロジカル、フィジカルまたはスナップショットのスタンバイについて警告ステータスを生成するために使用できます。

    プロパティ値を表す単位は秒です。値が0秒の場合、転送ラグが存在しても警告を生成しません。ベスト・プラクティスとして、TransportLagThresholdを15分以上に設定することをお薦めします。

SQLを使用したOracle Data Guard構成ヘルスの監視

次の表の問合せを使用すると、プライマリ・データベースおよびスタンバイ・データベースのData Guard構成全体のヘルスを評価できます。

表16-1 プライマリ・データベースの問合せ

目標 問合せ 予想される結果

リモート・スタンバイ・アーカイブ先でエラーが発生していないかどうかをチェックします

すべてのリモート・スタンバイ・アーカイブ先が有効(VALID)かどうかをチェックします

 
select sysdate,status,error
 from gv$archive_dest_status
 where type='PHYSICAL'
 and status!='VALID'
 or error is not null;

正常なヘルス = 行が返されません

問合せで行が返された場合は、返されたデータを使用してアラートを生成します。

前日にプライマリ・データベースでNOLOGGINGアクティビティが発生したかどうかをチェックします 

select file#, name, unrecoverable_change#, unrecoverable_time
 from v$datafile
 where unrecoverable_time > (sysdate - 1);

正常なヘルス = 行が返されません

問合せで行が返された場合は、スタンバイ・データベースが脆弱であり、出力にリストされているファイルをスタンバイでリフレッシュする必要があります。

スタンバイ・データベースのギャップを検出します

 
select sysdate,database_mode,recovery_mode, gap_status
 from v$archive_dest_status
 where type='PHYSICAL'
 and gap_status !='NO GAP';

正常なヘルス = 行が返されません

問合せで行が返された場合は、プライマリ・データベースとスタンバイ・データベースの間にギャップがすでに存するため、スタンバイ・データベースで同じ問合せを実行する必要があります。

プライマリとスタンバイの出力が同一の場合、アクションは不要です。

スタンバイの出力がプライマリの出力と一致しない場合は、スタンバイのデータファイルをリフレッシュする必要があります。

前日に重大なData Guardイベントが発生したかどうかを評価します

 
select *
 from v$dataguard_status
 where severity in ('Error','Fatal')
 and timestamp > (sysdate -1);

正常なヘルス = 行が返されません

問合せで行が返された場合は、返された出力を使用してアラートを生成します。

同期環境の場合のみ:

最大可用性モードで実行されており、構成が同期しているかどうかを評価します

 
select sysdate,protection_mode, synchronized, synchronization_status
 from v$archive_dest_status
 where type='PHYSICAL'
 and synchronization_status !='OK';

正常なヘルス = 行が返されません

問合せで行が返された場合は、返された出力を使用してアラートを生成します。

表16-2 フィジカル・スタンバイ・データベースの問合せ

目標 問合せ 予想される結果

転送ラグがあるかどうかを確認します

 
select name,value,time_computed,datum_time
 from v$dataguard_stats
 where name='transport lag'
 and value > '+00 00:01:00';

正常なヘルス = 行が返されません

行が返されない場合は、転送ラグがないことを意味します

適用ラグがあるかどうかを確認します

 
select name,value,time_computed,datum_time
 from v$dataguard_stats
 where name='apply lag'
 and value > '+00 00:01:00';

正常なヘルス = 行が返されません

行が返されない場合は、適用ラグがないことを意味します

スタンバイ・データ・ファイル・チェック(オフライン・ファイルまたはアクセスできないファイル)

 
select *
 from v$datafile_header
 where status ='OFFLINE'
 or ERROR is not null;

正常なヘルス = 行が返されません

返される行には、I/Oまたはリカバリの問題があるファイルがリストされます

メディア・リカバリ・プロセスが現在実行中であることを確認します

 
select *
 from v$managed_standby
 where process like 'MRP%';

正常なヘルス = 行が返されます

行が返されない場合、MRPプロセスは実行されていません

前日に重大なData Guardイベントが発生したかどうかを評価します

 
select *
 from v$dataguard_status
 where severity in ('Error','Fatal')
 and timestamp > (sysdate -1);

正常なヘルス = 行が返されません

問合せで行が返された場合は、返された出力を使用してアラートを生成します

Oracle Data Guard Brokerの診断情報

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

  • データベース・ステータスの情報

  • Oracleアラート・ログ・ファイル

    ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。

  • Oracle Data Guard Brokerのログ・ファイル

    ブローカ構成内の各データベースのインスタンスごとに、ブローカのDMONプロセスにより、重要な動作およびステータス情報がブローカ・ログ・ファイルに記録され、このファイルは、Oracle Data Guardの障害を診断する際に役立ちます。TraceLevel構成プロパティを設定して、ブローカ・ログ・ファイルでレポートされる診断情報のレベルを指定します。ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

  • Oracle Data Guardコマンドライン(DGMGRL)のlogfileオプション

    DGMGRLコマンドライン・インタフェースを、-logfileオプション・パラメータを付けて開始すると、結果として生じるログ・ファイルに、過去の操作およびエラー条件に関する、役に立つ記録が含まれる場合があります。

データ破損の検出および監視

破損データがディスクに書き込まれた場合、または正常なデータの書込み後にコンポーネント障害によってそのデータが破損した場合は、破損したブロックをできるだけ早く検出することが重要です。

データベースのエラーおよびアラートを監視するには、次のことを行います。

  • ブロック破損が検出または修復されると自動的に更新される、V$DATABASE_BLOCK_CORRUPTIONビューを問い合せます。

  • データ障害の自動診断、適切な修復オプションの判別と提供、およびリクエストに応じた修復操作の実行が行われるように、データ・リカバリ・アドバイザを構成します。

    データ・リカバリ・アドバイザはOracle Enterprise Manager Support Workbench (サポート・ワークベンチ)、ヘルス・モニターおよびRMANと統合されています。

  • Data Guardを使用して、物理破損を検出し、書込みの欠落を検出します。

    Data Guardは、REDOストリームで破損ブロックのために適用プロセスが停止した場合、または書込みの欠落を検出した場合に、物理破損を検出します。

    Data Guard構成の管理および監視にはEnterprise Managerを使用します。

    自動ブロック・メディア・リカバリを利用することで、プライマリ・データベースまたはフィジカル・スタンバイ・データベースのどちらかで検出された破損ブロックは、Active Data Guardオプションが使用されていると自動的に修正できます。

  • SQL*Plusを使用して、データファイル破損およびブロック間破損を検出します。

    次のSQL*Plus文を実行します。

    sqlplus> ANALYZE TABLE table_name VALIDATE STRUCTURE CASCADE;

    破損の検出後は、表を再作成するか、他のアクションを行うことができます。

  • Recovery Manager (RMAN)のバックアップおよびリカバリ計画では、物理ブロック破損を検出できます。

    次のコマンドを使用したさらに徹底的なRMANチェックでは、論理ブロック破損を検出できます。

    RMAN> BACKUP VALIDATE CHECK LOGICAL;