15 Oracle Data Guardのチューニングおよびトラブルシューティング

REDO転送、REDO適用またはロール・トランジションが想定した要件を満たしていない場合は、次のガイドラインを使用してデプロイメントをチューニングおよびトラブルシューティングします。

Oracle Data Guardのチューニングおよびトラブルシューティングの概要

Oracle Data Guard構成から最適なパフォーマンスを得るには、監視、アセスメントおよびパフォーマンス・チューニングに次のOracle MAAベスト・プラクティスを使用します。

• Oracle DatabaseおよびOracle Data Guard構成ベスト・プラクティスが適用されていることを確認します。

  評価およびチューニング時の前提は、Oracle DatabaseおよびData Guardのすべての構成ベスト・プラクティスがすでに環境に統合されていることです。チューニングを実行する前に、これらのベスト・プラクティスへの準拠を評価します。

• REDO転送サービスの評価およびチューニング

  Oracle Data Guardでは、パフォーマンスを最適化するために、REDO転送を自動的にチューニングします。ただし、パフォーマンスの問題が発生した場合は、REDO転送サービスを監視およびチューニングできます。

  最大パフォーマンス・データ保護モードでの非同期REDO転送が、デフォルトのOracle Data Guard構成です。非同期REDO転送のチューニングでは、主に、プライマリ、スタンバイおよびネットワーク・リソースがワークロードを処理するのに十分であることを確認し、それらのリソースのボトルネックを確実に監視するようにします。

  同期REDO転送では、データ損失ゼロのパフォーマンスが幾分低下しますが、MAA推奨の適切な方法を使用すると、影響を監視して評価し、リソースを適切に分散させることができます。

• REDO適用の評価およびチューニング

  ほとんどの場合、スタンバイが常に最新の状態であれば、デフォルトのOracle設定で良好なメディア・リカバリのパフォーマンスを実現できます。ただし、アプリケーションおよびデータベースのサイズとスループットが増えた場合は、メディア・リカバリ操作をさらにチューニングすると、スタンバイ・データベースでリカバリ時間またはREDO適用スループットをいっそう最適化できます

• ロール・トランジションの評価およびチューニング

  適切な計画と実装に基づいたOracle Data GuardおよびActive Data Guardのロール・トランジションにより、停止時間を効果的に最小化し、ビジネスへの影響を最小限に抑えながらデータベース環境をリストアできます。フィジカル・スタンバイ・データベースおよびOracle Maximum Availability Architecture (MAA)ベスト・プラクティスを使用してパフォーマンスをテストしたところ、スイッチオーバーおよびフェイルオーバーを数秒に短縮できました。

REDO転送のトラブルシューティングおよびチューニング

Oracle Data Guard REDO転送のパフォーマンスは、プライマリ・システムとスタンバイ・システム、それらを接続するネットワークおよびI/Oサブシステムのパフォーマンスに直接依存します。

ほとんどのOracle Data Guard構成では、REDO転送のトラブルシューティングおよびチューニングを行うことで、データ損失をゼロまたは最小限に抑えることができます。

ここに示すガイダンスでは、MAA構成のベスト・プラクティスに従っていることを前提としています。前提条件として、Oracle Data Guardの構成ベスト・プラクティスが実装されていることを確認します。

転送を全体的に向上させるには、次のトピックで説明するデータ収集およびトラブルシューティングの方法を活用します。この方法では、実際にREDO転送の問題があるかどうかを評価するために必要なデータの収集、およびREDO転送スループットを最適化するためにチューニングできることをガイドします。

• トポロジ情報の収集
• 転送ラグの検証およびREDO転送構成の理解
• 転送ラグのトラブルシューティングのための情報の収集
• プライマリでのREDO生成率履歴の比較
• 転送ネットワークの評価およびチューニング
• システム・リソースの収集および監視
• 高度なトラブルシューティング: 非同期REDO転送を使用したネットワーク時間の決定
• 同期REDO転送のチューニングおよびトラブルシューティング

トポロジ情報の収集

Oracle Data Guard構成のトポロジとData Guardのパフォーマンスとの関連性を理解すると、Data Guardアーキテクチャに起因すると誤って判断されることがよくあるインフラストラクチャの脆弱性を排除するのに役立ちます。

次の上位レベルのアーキテクチャ情報の概要をまとめることをお薦めします。

• プライマリ・データベース・システムおよびスタンバイ・データベース・システムの説明(Oracle RACクラスタ内のノード数、データベース・ノードごとのCPUおよびメモリー、ストレージI/Oシステム)
• プライマリ・システムとスタンバイ・システムを接続するネットワーク・トポロジの説明
  • プライマリとスタンバイの間のネットワーク・コンポーネント/デバイス
  • ネットワーク帯域幅および待機時間

対称のハードウェアおよび構成を持つスタンバイ・データベースで、ネットワーク構成が適切にチューニングされている場合、転送ラグは10秒未満であり、ほとんどの場合1秒未満となります。

転送ラグの検証およびREDO転送構成の理解

スタンバイ・データベースにラグがあるかどうか、およびこれが転送ラグまたは適用ラグかどうかを判断するには、V$DATAGUARD_STATSビューを問い合せます。

SQL> select name,value,time_computed,datum_time from v$dataguard_stats where name=’%lag’;

DATUM_TIME列は、メトリックの計算に使用されたデータを受信した、スタンバイ・データベースでのローカル時刻です。ラグ・メトリックは、プライマリ・データベースから定期的に受信されるデータに基づいて計算されます。複数の問合せにおいてこの列の値が変化しない場合は、スタンバイ・データベースがプライマリ・データベースからデータを受信していないことを示している。このシナリオで考えられるデータ損失は、V$DATAGUARD_STATSの最終データ時刻からスタンバイの現在時刻までになります。

スタンバイ・インスタンスが最後に起動されてからの転送ラグまたは適用ラグの値の履歴を示すヒストグラムを取得するには、V$STANDBY_EVENT_HISTOGRAMビューを問い合せます。

SQL> select * from v$standby_event_histogram where name like '%lag' and count >0;

ある期間にわたって転送ラグまたは適用ラグを評価するには、その期間の開始時のV$STANDBY_EVENT_HISTOGRAMのスナップショットを取得し、その期間の終了時に取得したスナップショットと比較します。

SQL> col NAME format a10
SQL> select NAME,TIME,UNIT,COUNT,LAST_TIME_UPDATED from V$STANDBY_EVENT_HISTOGRAM where
 name like '%lag' and count >0 order by LAST_TIME_UPDATED;

NAME             TIME UNIT                  COUNT LAST_TIME_UPDATED

---------- ---------- ---------------- ---------- --------------------

transport lag      41 seconds                   3      01/05/2022 16:30:59

transport lag     245 seconds                   1      01/05/2022 16:31:02

transport lag     365 seconds                   2      01/05/2022 16:31:03

transport lag     451 seconds                   2      01/05/2022 16:31:04

REDO転送ラグが高いことを確認した場合は、「転送ラグのトラブルシューティングのための情報の収集」を使用して、このREDO転送の調査を続行します。転送ラグはないものの、REDO適用ラグが高い場合は、「REDO適用のトラブルシューティングおよびチューニング」の方法を使用して適用ラグに対処します。

転送ラグのトラブルシューティングのための情報の収集

許容できないREDO転送ラグが発生した場合は、次の情報を収集し、質問について調査します。

• 転送ラグはいつ発生しましたか。V$DATAGUARD_STATSおよびV$STANDBY_EVENT_HISTOGRAMのデータを記録して、ラグがいつ開始したか、およびラグが時間の経過とともにどのように変化しているかを示します。
• 転送ラグは、日次バッチ操作では毎日午前0時、大規模バッチ操作では毎月、四半期末では毎四半期など、特定の期間中に発生しますか。
• 有効なOracle Data Guard転送ではLOG_ARCHIVE_DEST設定を確認し、REDO COMPRESSIONまたはENCRYPTIONが有効かどうかを確認します。送信前にREDOを圧縮または暗号化し、スタンバイでの受信時に圧縮解除または暗号化解除する必要があるため、REDO転送スループット全体に悪影響を及ぼす可能性があります。その変更が最新かどうか、およびこれらの設定属性の無効化をテストできるかどうかを確認します。
• Oracle Net設定をチェックして、Oracle Net暗号化が有効になっているかどうかを評価します。Oracle Net暗号化が有効な場合、いつ、どのレベルで有効化されましたか。REDOは送信前に暗号化され、スタンバイでのREDOの受信時に暗号化解除されるため、Oracle Netの暗号化によってREDOスループットが大幅に低下する可能性があります。オプションで、暗号化レベルを無効化または低減して、REDO転送ラグが減少するかどうかを確認します。

プライマリでのREDO生成率履歴の比較

大規模なバッチ・ジョブ、データ・ロード、データ・ポンプ操作、CREATE TABLE AS SELECT、PDML操作、または月末、四半期末、年度末のバッチ更新など、短期間についてプライマリ・データベースのREDO生成率が例外的に高くなる場合があります。

プライマリ・データベースからREDO生成履歴を取得し、REDO転送時またはREDO適用ラグの開始時と比較します。新しいプラガブル・データベースや新しいアプリケーション・サービスの追加など、追加ワークロードが原因で、REDO生成率が例外的に高いのかどうかを確認します。これにより、この追加のロードに対応するためにさらにチューニングが必要になる場合があります。

トラブルシューティングの一環として、次の情報を収集するか、次の質問に対処します。

• この問合せを使用して、プライマリ・データベースのREDO生成率の日次履歴を収集します。

  SQL> select trunc(completion_time) as "DATE", count(*) as "LOG SWITCHES", round(sum(blocks*block_size)/1024/1024) as "REDO PER DAY (MB)" 
  from v$archived_log 
  where dest_id=1 
  group by trunc(completion_time) order by 1;

• REDOラグまたは転送ラグが開始する6時間前以降の、ログごとのREDO生成率を収集します。

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

• REDOラグまたは転送ラグが開始する6時間前の自動ワークロード・リポジトリ(AWR)レポートから、REDO生成率の毎時のスナップショットを収集します。

  デフォルトでは、Oracle Databaseによりスナップショットが1時間ごとに自動生成されますが、スナップショットを手動で作成して、自動生成されるスナップショットとは異なるタイミングで統計を取得することが必要になる場合があります。既存のスナップショットの情報を表示するには、DBA_HIST_SNAPSHOTビューを使用します。

  AWRおよびスナップショットおよびAWRレポートの生成の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のスナップショットの作成に関する項を参照してください。

• このプライマリREDO生成率は、以前の履歴と比較して例外的に高いですか。

• 可能な場合は、高いREDO生成率に対応するワークロードを特定し、それが一時的かどうか、またはチューニング可能かどうかを評価します。

  たとえば、大規模なパージ操作では、REDO生成ボリュームを減らすためにパーティション操作を切り捨てるか、または削除することを検討してください。

転送ネットワークの評価およびチューニング

REDO転送は、スタンバイ・データベースのバックグラウンド・プロセスにREDOを送信するプライマリ・データベース・インスタンスのバックグラウンド・プロセスで構成されます。ネットワークがOracle Data Guard REDO転送用に最適化されているかどうかを評価できます。

非同期REDO転送が構成されている場合、REDOデータは、大規模なパケットで非同期的に、スタンバイにストリーミングされます。ネットワークを介した非同期REDO転送をチューニングするには、単一プロセスのネットワーク転送を最適化する必要があります。

同期REDO転送が構成されている場合、次のREDO書込みに進む前に、各REDO書込みをプライマリ・データベースとスタンバイ・データベースで確認する必要があります。LOG_ARCHIVE_DEST設定の一部としてFASTSYNC属性を使用することで、スタンバイ同期転送を最適化できますが、ネットワーク待機時間が長いと(5ミリ秒を超えるなど)、REDO転送スループット全体に影響を及ぼします。

続行する前に、まず「ネットワーク・パフォーマンスの評価および最適化」を参照して、次のことを実行します。

• プライマリのREDO生成率をサポートするのに十分なネットワーク帯域幅があるかどうかを評価する

• REDO転送をチューニングするための最適なTCPソケット・バッファ・サイズを決定する

• REDO転送をチューニングするために、ソケット・バッファ・サイズに対するオペレーティング・システムの制限をチューニングする

• REDO書込みサイズの最適なMTU設定を決定する

• REDO転送のネットワーク・スループットを向上させるためのMTUをチューニングする

ネットワーク構成がチューニングされている場合は、転送ラグ(「転送ラグの検証およびREDO転送構成の理解」を参照)が許容レベルまで小さくなっているかどうかを評価します。その場合は、目標を達成したので終了できます。それ以外の場合は、残りのチューニングおよびトラブルシューティングに関する項に進みます。

システム・リソースの収集および監視

Oracle Linux OSwatcherまたはOracle Exadata ExaWatcherのデータを収集して、システム・リソースを分析します。

OSWatcher (oswbb)は、パフォーマンス問題の診断のサポートを支援するために、オペレーティング・システムおよびネットワークのメトリックを収集およびアーカイブすることを目的としたUNIXシェル・スクリプトのコレクションです。ベスト・プラクティスとして、実行中のOracleインスタンスが存在するすべてのノードでOSWatcherをインストールして実行する必要があります。パフォーマンスに関する問題の場合、Oracleサポートはこのデータを使用して、データベースの外部で発生する可能性のあるパフォーマンスに関する問題を診断できます。

OSWatcherは、OSWatcher (Doc ID 301137.1)からダウンロードできます。

ExaWatcherは、Exadataシステムのストレージ・サーバーおよびデータベース・サーバーのパフォーマンス・データを収集するユーティリティです。収集されるデータには、iostat、セル統計(cellsrvstat)、ネットワーク統計などのオペレーティング・システム統計情報が含まれます。

詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』のExaWatcherチャートを使用したExadata Database Machineのパフォーマンスの監視に関する項を参照してください。

Data Guardのリソース要件を満たすためのチューニング

REDO転送は、次の場合に影響を受ける可能性があります。

• プライマリ・データベースまたはスタンバイ・データベースが完全にCPUバウンドである
• プライマリ・データベースまたはスタンバイ・データベースのI/Oシステムが飽和状態である
• ネットワーク・トポロジでREDO生成率をサポートできない

プライマリ・データベース・システムに次のものがあるかどうかを評価します。

• ログ・ライター・プロセス(LGWR)がフォアグラウンドを効率的にポストするのに十分なCPU使用率
• ローカル・ログ書込みでピーク時のI/O待機時間を低く保つために十分なI/O帯域幅
• 同じインタフェースの他のネットワーク・アクティビティと組み合せてピークREDO率ボリュームを処理できるネットワーク・インタフェース
• チューニングおよびトラブルシューティングのためにプライマリ・データベースから収集された自動ワークロード・リポジトリ(AWR)、アクティブ・セッション履歴(ASH)およびOSwatcherまたはExawatcherデータ

スタンバイ・データベース・システムに次のものがあるかどうかを評価します。

• スタンバイ・データベースでREDOを受信するOracle Data Guardプロセスであるリモート・ファイル・サーバー(RFS)がスタンバイREDOログに効率的に書き込むのに十分なCPU使用率
• ローカル・ログ書込みでピーク時のI/O待機時間を低く保つために十分なI/O帯域幅
• 同じインタフェースの他のネットワーク・アクティビティと組み合せてピークREDO率ボリュームを受信できるネットワーク・インタフェース

• チューニングおよびトラブルシューティングのためにスタンバイ・データベースから収集されたAWR、ASHおよびOSwatcherまたはExawatcherデータ

ノート:

スタンバイ・データベースで発生する最大の問題は、I/O帯域幅が十分でないためにスタンバイ・ログ書込みの待機時間が長くなることです。この問題は、Data Guard遠隔同期を使用することで軽減できます。

システム構成がチューニングされ、前述のリソース制約が解除されている場合は、転送ラグ(「転送ラグの検証およびREDO転送構成の理解」を参照)が許容レベルまで小さくなっているかどうかを評価します。その場合は、目標を達成しました。

高度なトラブルシューティング: 非同期REDO転送を使用したネットワーク時間の決定

続行する前に、まず「ネットワーク・パフォーマンスの評価および最適化」を参照してください。

十分なリソース(特にネットワーク帯域幅)がある場合、非同期REDO転送では、非常に高いワークロードを維持できます。リソースが制約される場合、非同期REDO転送が遅れ始めると、スタンバイ・データベースで転送ラグが増大します。

非同期REDO転送(ASYNC)は、REDOデータをトランザクション・コミットに対して非同期で転送します。トランザクションは、そのトランザクションによって生成されたREDOがリモート・スタンバイ・データベースに正常に送信されたことを確認するのを待機せずにコミットできます。ASYNCを使用すると、制限された帯域幅によって前のトランザクションのREDOがスタンバイ・データベースに即時に送信できなくても、プライマリ・データベースのログ・ライター・プロセス(LGWR)は、コミット成功を引き続き確認します(水が排出されるよりも速く、シンクが水でいっぱいになる様子を想像してください)。

ASYNCでは、TT00プロセスを使用して、プライマリ・データベースのログ・バッファから直接REDOを送信します。TT00プロセスが速度を維持できず、REDOをスタンバイ・データベースに転送する前にログ・バッファがリサイクルされる場合、TT00プロセスは、ディスク上のオンラインREDOログ・ファイル(ORL)からの読取りおよび送信に自動的に遷移します。TT00送信が現在のREDO生成に追い付くと、ログ・バッファからの直接読取りおよび送信に自動的に戻ります。

TT00が元のORLの送信を完了する前に2つ以上のログ・スイッチが存在する場合でも、TT00は、現在のオンライン・ログ・ファイルの内容の読取りに遷移して戻ります。元のORLと現在のORLの間にアーカイブされたすべてのORLは、Oracle Data GuardのREDOギャップ解消プロセスを使用して自動的に送信されます。

プライマリ・データベースとスタンバイ・データベースの両方における、ネットワーク帯域幅、CPU、メモリー、ログ・ファイルI/Oなどの十分なリソースは、非同期Data Guard構成のパフォーマンスにとって重要です。

非同期転送を制約しているリソースを特定するには、プライマリ・データベースとスタンバイ・データベースの両方でイベント16421を設定することで有効にできるkrsb統計を使用します。

alter session set events ‘16421 trace name context forever, level 3’;

このイベントは非常に軽量であり、プライマリ・データベースまたはスタンバイ・データベースのパフォーマンスには影響しません。

この動的イベントは、すべてのプライマリ・インスタンスおよびスタンバイ・インスタンスに設定する必要があり、指定された順序の送信が完了すると、TT00またはリモート・ファイル・サーバー(RFS)のトレース・ファイルに統計が書き込まれます。トレース・ファイルを調べると、krsb_end統計はファイルの先頭と末尾に示されます。ファイルの末尾にある統計では、どこで非同期送信に時間がかかったかについての見通しが得られます。たとえば:

krsb_end: Begin stats dump for T-1.S-593
  max number of buffers in use             10
  Operation elapsed time (micro seconds)   474051333
  File transfer time (micro seconds)       474051326
  Network Statistics
   LOG_ARCHIVE_DEST_2 : OCI REQUEST
    Total count  : OCI REQUEST             2748
    Total time   : OCI REQUEST             81374
    Average time : OCI REQUEST             29
   LOG_ARCHIVE_DEST_2 : NETWORK SEND
    Total count  : NETWORK SEND            2748
    Total time   : NETWORK SEND            286554724
    Average time : NETWORK SEND            104277
    Total data buffers queued              9644
    Total data buffers completed           9644
    Total bytes written                    9885272064
    Total bytes completed synchronously    9885272064
    Average network send size (blocks)     7025
    Average network send buffers           3.51
    Average buffer turnaround time         240889
    Throughput (MB/s)                      19.89
   Total network layer time                286636098
   Percentage of time in network           60.47
  Disk Statistics
    Total count  : DISK READ               11531
    Total time   : DISK READ               12335132
    Average time : DISK READ               1069
    Read-ahead blocks                      14151680
    Log buffer blocks                      266915
    Disk stall blocks                      4888576
    Total count  : BUFFER RELEASE          9643
    Total time   : BUFFER RELEASE          7229
    Average time : BUFFER RELEASE          0
   Total disk layer time                   12342361
   Percentage of time in disk layer        2.60
  Data Guard Processing Statistics
    Total count  : SLEEP                   198
    Total time   : SLEEP                   172351312
    Average time : SLEEP                   870461
   Total DG layer time                     175072867
   Percentage of time in DG layer          36.93
  Remote Server-Side Network Statistics
   LOG_ARCHIVE_DEST_2 : NETWORK GET
    Total count  : NETWORK GET             8242
    Total bytes  : NETWORK GET             9885272064
    Total time   : NETWORK GET             453233790
    Average time : NETWORK GET             54990
   Total server-side network layer time    453233790
   Percentage of time in network           95.61
  Remote Server-Side Disk Statistics
   LOG_ARCHIVE_DEST_2 : DISK WRITE
    Total count  : DISK WRITE              9644
    Total time   : DISK WRITE              8731303
    Average time : DISK WRITE              905
   LOG_ARCHIVE_DEST_2 : DISK NOSTALL REAP
    Total count  : DISK NOSTALL REAP       9644
    Total time   : DISK NOSTALL REAP       579066
    Average time : DISK NOSTALL REAP       60
   LOG_ARCHIVE_DEST_2 : BUFFER GET
    Total count  : BUFFER GET              9644
    Total time   : BUFFER GET              3607
    Average time : BUFFER GET              0
   Total server-side disk layer time       9313976
   Percentage of time in disk layer        1.96
  Remote Server-Side Data Guard Processing Statistics
   LOG_ARCHIVE_DEST_2 : PUBLISH RTA BOUNDARY
    Total count  : PUBLISH RTA BOUNDARY    8948
    Total time   : PUBLISH RTA BOUNDARY    3665841
    Average time : PUBLISH RTA BOUNDARY    409
   LOG_ARCHIVE_DEST_2 : VALIDATE BUFFER
    Total count  : VALIDATE BUFFER         9644
    Total time   : VALIDATE BUFFER         1403088
    Average time : VALIDATE BUFFER         145
   Total Server-Side DG layer time         11503560
   Percentage of time in DG layer          2.43
krsb_end: End stats dump

前述の出力は、転送ラグが発生し始めたばかりのテスト実行から取得したものです。ネットワークの輻輳が増加し、ネットワーク・レイヤーで待機する時間が50%を超えて増加したことによる遅延を確認できます。転送ラグが圧縮または暗号化の結果である場合、Data Guardレイヤーに費やされる時間の割合がその大部分となります。

krsb統計を無効にするには、イベント16421をレベル1に設定します。

alter session set events ‘16421 trace name context forever, level 1’;

同期REDO転送のチューニングおよびトラブルシューティング

続行する前に、まず「ネットワーク・パフォーマンスの評価および最適化」を参照してください。

次のトピックでは、同期REDO転送を評価する方法について説明します。

• 同期トランスポートでデータの整合性を確保する方法の理解
• 同期REDO転送環境でのパフォーマンスの評価
• log file sync待機イベントが誤解を招く理由
• 外れ値の原因の理解
• 同期REDO転送リモート書込みの影響
• 同期REDO転送パフォーマンスのトラブルシューティングの例

同期トランスポートでデータの整合性を確保する方法の理解

次のアルゴリズムにより、Oracle Data Guard同期REDO転送構成でデータの整合性を確保できます。

• プライマリ・データベースのオンラインREDOログに対するログ・ライター・プロセス(LGWR)のREDO書込みと、スタンバイREDOログに対するData Guardネットワーク・サービス・サーバー(NSS)のREDO書込みは同一です。

• スタンバイ・データベースのData Guard Managed Recovery Process (MRP)は、REDOがプライマリ・データベースのオンラインREDOログに書き込まれていないかぎり、REDOを適用できません。ただし、唯一の例外がData Guardフェイルオーバーの操作中です(プライマリが停止している場合)。

  REDOの同期送信に加えて、NSSおよびLGWRは、スタンバイ・リカバリがスタンバイREDOログ(SRL)から適用できる安全なREDOブロック境界に関する情報を交換します。これにより、スタンバイが受信しても、まだプライマリがオンラインREDOログにコミットされたことを確認していないREDOがスタンバイによって適用されることが回避されます。

次のような障害シナリオが考えられます。

• プライマリ・データベースのLGWRがオンラインREDOログに書き込むことができない場合、LGWRおよびインスタンスはクラッシュします。インスタンスまたはクラッシュ・リカバリは、オンラインREDOログ内の最後にコミットされたトランザクションにリカバリし、コミットされていないすべてのトランザクションをロールバックします。現在のログが完了し、アーカイブされます。

• スタンバイでは、一部のスタンバイREDOログが、対応するオンラインREDOログとサイズが一致する正しい値で完了します。スタンバイREDOログから欠落しているREDOブロックは、(REDOログ全体を再送信しないで)転送されます。

• プライマリ・データベースがクラッシュして自動または手動によるデータ損失ゼロのフェイルオーバーが発生した場合は、Data Guardフェイルオーバー操作の一部がターミナル・リカバリを実行し、現在のスタンバイREDOログを読み取ってリカバリします。

  リカバリでスタンバイREDOログ内のすべてのREDOの適用が終了すると、新しいプライマリ・データベースが起動し、新しく完了したログ・グループがアーカイブされます。新規および既存のすべてのスタンバイ・データベースが、オンラインREDOログ内のREDOを破棄し、一貫性のあるシステム変更番号(SCN)にフラッシュバックして、新しいプライマリ・データベースからのアーカイブのみを適用します。再度、Data Guard環境が(新しい)プライマリ・データベースと同期します。

同期REDO転送環境でのパフォーマンスの評価

Oracle Data Guard同期REDO転送環境(SYNC)でパフォーマンスを評価する場合、様々な待機イベントが相互にどのように関連しているかを把握することが重要です。同期REDO転送を有効にした場合の影響は、アプリケーションによって異なります。

その理由を理解するために、コミットが発行されたときにログ・ライター・プロセス(LGWR)が実行する作業の次の説明を考慮してください。

1. フォアグラウンド・プロセスは、コミットのためにLGWRをポストします(ログ・ファイル同期が開始されます)。同時コミット・リクエストがキューに入っている場合、LGWRは未処理のすべてのコミット・リクエストをまとめてバッチ処理して、連続的なREDOストランドを生成します。
2. LGWRがCPUを待機します。
3. LGWRがREDO書込みを開始します(REDO書込み時間が開始されます)。
4. Oracle RACデータベースの場合、LGWRが現在の書込みを他のインスタンスにブロードキャストします。
5. 事前処理後、SYNCスタンバイがある場合、LGWRはリモート書込みを開始します(SYNCリモート書込みが開始されます)。
6. LGWRがローカル書込み(ログ・ファイル・パラレル書込み)を発行します。
7. SYNCスタンバイがある場合、LGWRはリモート書込みの完了を待機します。
8. I/Oステータスの確認後、LGWRはREDO書込み時間/SYNCリモート書込みを終了します。
9. Oracle RACデータベースの場合、LGWRはブロードキャストackを待機します。
10. LGWRがディスク上のSCNを更新します。
11. LGWRがフォアグラウンドをポストします。
12. フォアグラウンドがCPUを待機します。
13. フォアグラウンドがログ・ファイル同期を終了します。

次の方法を使用してパフォーマンスを評価します。

• バッチ・ロードの場合、これらのプロセスのほとんどが固定された期間内に完了する必要があるため、経過時間を監視することが最も重要な要因となります。これらの操作のデータベース・ワークロードは、通常のOLTPワークロードとは大きく異なります。たとえば、書込みのサイズが大幅に大きくなる可能性があるため、ログ・ファイル同期平均を使用しても、正確に把握または比較できません。

• OLTPワークロードの場合、AWRレポートから1秒当たりのトランザクション・ボリューム(自動ワークロード・リポジトリ(AWR)から)およびREDO率(1秒当たりのREDOサイズ)を監視します。この情報により、同期REDO転送を有効にすることで、アプリケーションのスループットとその影響を明確に把握できます。

log file sync待機イベントが誤解を招く理由

通常、プライマリ・データベースのlog file sync待機イベントは、管理者が同期REDO転送(SYNC)を有効にした場合の影響を評価するときに最初に参照する場所です。

SYNCを有効にする前の平均log file sync待機が3ミリ秒で、後の平均が6ミリ秒であった場合、SYNCがパフォーマンスに100パーセント影響を与えたと想定します。SYNCの影響を測定するためにlog file sync待機時間を使用することはお薦めしません。これは、平均は非常に誤解を招きやすいためであり、また、レスポンス時間およびスループットに対するSYNCの実際の影響はイベントが示す値よりもはるかに低くなる可能性があるためです。

ユーザー・セッションがコミットすると、ログ・ライター・プロセス(LGWR)はCPUを取得し、I/Oを送信し、I/Oの完了を待機してから、CPUに戻って、コミットが完了したフォアグラウンド・プロセスをポストします。この期間全体がlog file sync待機イベントでカバーされます。LGWRが自身の作業を実行している間、ほとんどの場合、コミット中の他のセッションがあり、それらのセッションはLGWRの終了を待ってからそれぞれのコミットを処理する必要があります。待機しているセッションのサイズと数は、アプリケーションが持つセッションの数と、それらのセッションがコミットされる頻度によって決まります。コミットをこのようにバッチ処理することを一般にアプリケーション同時実行性と呼びます。

たとえば、通常、ログ書込み(log file parallel write)の実行に0.5msかかり、サービス・コミット(log file sync)の実行に1 msかかり、平均ではコミットごとに100個のセッションを処理しているとします。ストレージ層の異常によって1つのコミットのログ書込みI/Oの完了に20ミリ秒かかった場合、log file parallel writeに起因する長い待機は1つのみであるのに、最大2,000個のセッションがlog file syncで待機する可能性があります。1つの長い外れ値で多数のセッションが待機していると、log file syncの平均が大幅に偏ることがあります。

次の表は、特定の期間のlog file sync待機イベントに対するV$EVENT_HISTOGRAMからの出力を示しています。

表15-1 ログ・ファイル同期待機イベントのV$EVENT_HISTOGRAM出力

ミリ秒	待機数	合計待機に対する割合
1	17610	21.83%
2	43670	54.14%
4	8394	10.41%
8	4072	5.05%
16	4344	5.39%
32	2109	2.61%
64	460	0.57%
128	6	0.01%

この出力は、log file sync待機時間の92%が8ミリ秒未満で、大部分が4ミリ秒(86%)未満であることを示しています。8ミリ秒を超える待機は外れ値であり、待機時間全体に占める割合がわずか8%ですが、それらの外れ値で待機しているセッションの数のため(コミットのバッチ処理のため)、平均が偏ります。SYNCの影響を評価するメトリックとしてlog file sync平均待機時間が使用されている場合、偏った平均が誤解を招く可能性があります。

外れ値の原因の理解

プライマリ・データベースまたはスタンバイ・データベースでのI/Oの中断やネットワーク待機時間のスパイクがあると、同期REDO転送でlog file syncの外れ値が高くなる可能性があります。この影響は、スタンバイ・システムのI/Oサブシステムがプライマリ・システムのI/Oサブシステムよりも劣る場合に確認できます。

多くの場合、管理者がスタンバイ・システムに開発やテストなど複数のデータベースをホストするため、I/Oレスポンスが妨げられることがあります。iostatを使用してI/Oを監視し、ディスクが最大IOPSに達しているかどうかを確認することが重要です。これは、このことがSYNC書込みのパフォーマンスに影響するためです。

ログ・スイッチが頻繁に発生することは、外れ値の重大な原因です。次のように、プライマリでログ・スイッチが発生したときにスタンバイで何が起こるかを考慮してください。

1. スタンバイのリモート・ファイル・サーバー(RFS)プロセスで、スタンバイREDOログ・ヘッダーの更新を終了する必要があります。

2. 次に、RFSは追加のヘッダー更新を使用して新しいスタンバイREDOログに切り替えます。

3. ログを切り替えると、スタンバイで強制的に完全なチェックポイントが実行されます。

   これにより、バッファ・キャッシュ内のすべての使用済バッファがディスクに書き込まれ、書込みI/Oでスパイクが発生します。スタンバイ・ストレージ・サブシステムのパフォーマンスがプライマリ・データベースのパフォーマンスと同一でない非対称の構成では、I/O待機時間が長くなります。

4. 前のスタンバイREDOログをアーカイブして、読取りI/Oと書込みI/Oの両方を増やす必要があります。

同期REDO転送リモート書込みの影響

同期REDO転送(SYNC)を有効にすると、コミット処理の通常のローカル書込みに加えて、リモート書込み(スタンバイREDOログへのリモート・ファイル・サーバー(RFS)書込み)が導入されます。

このリモート書込みでは、ネットワーク待機時間およびリモートI/O帯域幅に応じて、コミット処理時間を増やすことができます。コミット処理には時間がかかるため、ログ・ライター・プロセス(LGWR)がその作業を終了してコミット・リクエストの作業を開始するまで待機しているセッションが増えます。つまり、アプリケーション同時実行性が増大しています。データベース統計および待機イベントを分析することで、アプリケーション同時実行性の増大を確認できます。

次の表の例を考えてみます。

表15-2 同期転送によるアプリケーション同時実行性増大の影響

SYNC	REDO率	ネットワーク待機時間	AWRからのTPS	ログ・ファイル同期平均(ミリ秒)	ログ・ファイル・パラレル書込み平均(ミリ秒)	RFS random I/O	SYNCリモート書込み平均(ミリ秒)	REDO書込みサイズ(KB)	REDO書込み
遅延	25MB	0	5,514.94	0.74	0.47	NA	NA	10.58	2,246,356
あり	25MB	0	5,280.20	2.6	.51	.65	.95	20.50	989,791
影響	0	-	-4%	+251%	+8.5%	NA	NA	+93.8%	-55.9%

前述の例では、SYNCを有効にすると、REDO書込みの数は減りますが、各REDO書込みのサイズは大きくなります。REDO書込みのサイズが増加するため、I/O (ローカルとリモートの両方)の実行に費やされる時間が長くなる可能性があります。1回の待機当たりの作業量が増えるため、log file sync待機時間が長くなります。

ただし、アプリケーション・レベルでは、コミットごとに処理されるセッションが増加しても、トランザクション率またはトランザクション・レスポンス時間への影響がほとんど変化しない場合があります。このため、データベース待機イベントに完全に依存するのではなく、アプリケーション・レベルでSYNCの影響を測定することが重要となります。また、これはSYNCがアプリケーションに与える実際の影響を把握する上でlog file sync待機イベントがなぜ誤解を招く指標であるかを示す好例でもあります。

同期REDO転送パフォーマンスのトラブルシューティングの例

同期REDO転送のパフォーマンスを調べるには、次に示すように、ローカルREDO書込み待機時間、書込み当たりの平均REDO書込みサイズおよびREDO書込み全体の待機時間を計算します。

次の待機イベントを使用して計算を行います。

• ローカルREDO書込み待機時間= 'log file parallel write'

• リモート書込み待機時間= 'SYNC remote write'

• 書込み当たりの平均REDO書込みサイズ= 'redo size' / 'redo writes'

• フォアグラウンド別に表示される平均コミット待機時間=「ログ・ファイル同期」

次の表に、Oracleデータベースの自動作業リポジトリ(AWR)レポートからの統計を示します。SYNCが無効になっているベースラインとパフォーマンスの影響を比較するために、ネットワーク待機時間が1ミリ秒のローカル・スタンバイに対して同期REDO転送(SYNC)が有効化されています。

表15-3 Oracle Databaseでの同期REDO転送のパフォーマンスの評価

メトリック	ベースライン(SYNCなし)	SYNC	影響
REDO率(MB/秒)	25	25	変化なし
ログ・ファイル同期	0.68	4.60	+576%
ログ・ファイル・パラレル書込み平均(ミリ秒)	0.57	0.62	+8.8%
TPS	7,814.92	6224.03	-20.3%
RFS random I/O	NA	2.89	NA
SYNCリモート書込み平均(ミリ秒)	NA	3.45	NA
REDO書込み	2,312,366	897,751	-61,2%
REDO書込みサイズ(KB)	10.58	20.50	+93.8%

前述の例では、SYNCを有効にした後、log file sync待機平均が大幅に増加していることがわかります。ローカル書込みはほぼ一定していますが、log file sync増加の最大要因はSYNCリモート書込みが追加されたことでした。SYNCリモート書込みのうち、ネットワーク待機時間はゼロであるのため、スタンバイREDOログへのリモート書込みに焦点を当てると、平均時間は2.89ミリ秒になります。プライマリとスタンバイが同じハードウェアを使用し、SYNCリモート書込み平均時間がプライマリのlog file parallel write平均時間と類似していることを考えると、これは緊急危険信号です。

前述の例では、スタンバイREDOログは複数のメンバーを持ち、低パフォーマンスのディスク・グループに配置されています。スタンバイREDOログのメンバーを1つに減らして高速のディスク・グループに配置すると、次の表に示すような結果が得られます。

表15-4 スタンバイREDOログのメンバーを1つに減らして高速のディスク・グループに配置した後のSYNCパフォーマンス

メトリック	ベースライン(SYNCなし)	SYNC	影響
REDO率(MB/秒)	25	25	変化なし
ログ・ファイル同期	0.67	1.60	+139%
ログ・ファイル・パラレル書込み	0.51	0.63	+23.5%
TPS	7714.36	7458.08	-3.3%
RFS random I/O	NA	.89	NA
SYNCリモート書込み平均(ミリ秒)	NA	1.45	NA
REDO書込み	2,364,388	996,532	-57.9%
REDO書込みサイズ(KB)	10.61	20.32	+91.5%

REDO適用のトラブルシューティングおよびチューニング

ほとんどのOracle Data Guard構成では、REDO適用のトラブルシューティングとチューニングを行うことで、適用ラグを最小化できます。REDO適用のパフォーマンスは、スタンバイ・システムのパフォーマンスに直接依存します。

ここに示すガイダンスでは、MAA構成のベスト・プラクティスに従っていることを前提としています。前提条件として、Oracle Data Guardの構成ベスト・プラクティスが実装されていることを確認します。

適用パフォーマンスを全体的に向上させるには、次のトピックで説明するデータ収集およびトラブルシューティングの方法を使用します。

REDO適用およびREDO適用のパフォーマンス期待値の理解

スタンバイ・データベース・リカバリは、DMLおよびDDLのすべての操作をリプレイするプロセスです。プロセスの概要は次のとおりです。

1. REDOはプライマリ・データベースから受信され、スタンバイREDOログ(SRL)に書き込まれます。データベースがOracle RACデータベースの場合、各スレッド(インスタンス)は割り当てられたSRLに格納されます。
2. ログ・マージ・プロセスは、リカバリ・コーディネータとも呼ばれ、REDOのスレッドをマージし、結果の変更ベクトルをメモリー・バッファに配置します。
3. リカバリ・ワーカー・プロセスは、必要なデータ・ブロックを特定し、バッファ・キャッシュに読み込みます(まだ存在しない場合)。次に、ワーカー・プロセスは、バッファ・キャッシュ内のブロックに変更ベクトルを適用します。
4. チェックポイント時間に、データベース・ライター・プロセスは検証済バッファ変更をデータ・ファイルに書き込み、システム・コミット番号(SCN)と呼ばれるデータベースのチェックポイント・タイムスタンプを拡張します。チェックポイントは、リカバリ・プロセスで最も広範囲に及ぶI/O負荷となる可能性があります。

REDO適用パフォーマンスの期待値

パフォーマンスおよび結果の適用率は、主に、リカバリ中のワークロードのタイプと、リカバリのために割り当てられ、使用可能なシステム・リソースによって異なります。

プライマリ・データベース・システムとスタンバイ・データベース・システムを対称にすること(同等のI/Oサブシステム、メモリー、CPUリソースなど)をお薦めします。このようにお薦めする主な理由は、どちらのデータベースがプライマリ・データベースであるかに関係なく、アプリケーションのパフォーマンスが同じレベルになるようにするためですが、REDO適用のパフォーマンスにも、プライマリ・データベースとスタンバイ・データベースを対称にすることで大きな利点がもたらされます。データ保護(DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUM、DB_LOST_WRITE_PROTECT)などの機能には、Oracle Active Data Guardを使用したスタンバイ・データベースのレポートと同様に、CPUおよびI/Oリソースが必要です。

ほとんどの場合、REDO適用パフォーマンスはREDO生成率に遅れずについていく必要があり、その結果、対称的なシステム・リソースで適用ラグがほぼゼロになります。ワークロードのピーク時には、ワークロードが通常のレベルに戻ると自然にほぼゼロまで減少するREDO適用ギャップが、若干存在することがあります。

OLTPワークロード

オンライン・トランザクション処理(OLTP)ワークロードは数多くの異なるブロックに対してわずかな変更を行うため、OLTPワークロードのリカバリは、非常にI/O集中型となる場合があります。これにより、リカバリ中に、小さいランダム・ブロックのバッファ・キャッシュへの読込みが大量に発生します。その後、データベース・ライターは、書込みI/Oの大規模なバッチを実行してバッファ・キャッシュを維持し、データベースのチェックポイントを定期的に実行します。したがって、OLTPワークロードのリカバリでは、最適な率を実現するために、ストレージ・サブシステムで1秒当たりのI/O (IOPS)を多数処理する必要があります。これが、プライマリ・データベース・システムとスタンバイ・データベース・システムを対称にすることをお薦めするもう1つの理由です。

リソース・ボトルネックのないOracle Exadata Database Machineクオータ・ラック・システムのswingbenchによって生成されたOLTPワークロードのリカバリ・テストでは、約150 MB/秒の適用率を達成しました。より大規模なExadataシステムでは、単一インスタンスのREDO適用で200 MB/秒を超える速度が顧客によって確認されています。Exadata以外のシステムでは、I/Oおよびネットワークのスループットが低くなるため、このような速度を達成することはより困難です。

バッチ・ワークロード

OLTPワークロード・リカバリとは対照的に、バッチ・ワークロードのリカバリは、バッチ・ワークロードが大量の順次読取りおよび書込みで構成されるため、より効率的です。より多くのREDO変更が発生するものの、読取りおよび変更するデータ・ブロックが大幅に減少するため、OLTPワークロードと比較してREDO適用率が大幅に向上します。また、バッチ直接ロード操作リカバリの最適化により、効率が高まり、リカバリ速度もさらに向上します。

妨げとなるシステム・リソースのボトルネックを伴わないバッチ・ロードまたはパラレルDML (PDML)ワークロードを使用すると、小規模なExadata Database Machineクオータ・ラック・システムでの内部REDO適用テストで、適用率は約200-300 MB/秒となります。より大規模なExadataシステムのバッチ・ワークロードでは、単一インスタンスのREDO適用で600 MB/秒を超える適用率が顧客によって確認されています。これらの率はExadata以外のシステムで実現できますが、このような要求の高いワークロードを処理するには、システム・リソースの容量とスケーラブルなネットワークおよびI/Oサブシステムが必要です。

混合ワークロード

様々なOLTPワークロードとバッチ・ワークロードが混在するアプリケーションにおいて、プライマリ・データベースのREDO生成率が類似していてもスタンバイ・データベースのリカバリ速度が異なるのは、OLTPとバッチのリカバリ・パフォーマンス・プロファイルが異なり、システムの形状が異なるためです。様々なExadataシステムの様々な混合ワークロードで、100-1100 MB/秒のREDO適用率が、顧客により達成されています。これらの率はExadata以外のシステムで実現できますが、このような要求の高いワークロードを処理するには、システム・リソースの容量とスケーラブルなデータベース・コンピュート、ネットワークおよびI/Oサブシステムが必要です。このような極端なREDO適用率は、Exadata以外のシステムではほとんど実現されません。

REDO適用パフォーマンスの期待値のキャッチ・アップ

リアルタイムのREDO適用と比較すると、キャッチ・アップ期間中のREDO適用では、さらにシステム・リソースが必要になる場合があります。大きなREDOギャップがある場合、推奨事項については、「非常に大きいREDO適用ギャップの対処」を参照してください。

適用ラグの検証

リカバリ・パフォーマンスは、プライマリ・データベースのワークロード・タイプおよびREDO生成率によって異なります。適用率が低いからといって、必ずしもリカバリ・パフォーマンスに関する問題を示すわけではありません。ただし、永続的または増加する適用ラグ(不随する転送ラグなし)は、リカバリ・パフォーマンスのボトルネックを示す最適な目安となります。

適用ラグおよび転送ラグを識別して定量化するには、スタンバイ・データベースのV$DATAGUARD_STATSビューを問い合せます。

SQL> select name, value, time_computed, datum_time from v$dataguard_stats where name=’%lag’;

DATUM_TIME列は、メトリックの計算に使用されたデータを受信した、スタンバイ・データベースでのローカル時刻です。ラグ・メトリックは、プライマリ・データベースから定期的に受信されるデータに基づいて計算されます。複数の問合せにおいてこの列の値が変化しない場合は、スタンバイ・データベースがプライマリ・データベースからデータを受信していないことを示している。このシナリオで考えられるデータ損失は、V$DATAGUARD_STATSの最終データ時刻からスタンバイの現在時刻までになります。

スタンバイ・インスタンスが最後に起動されてからの転送ラグまたは適用ラグの値の履歴を示すヒストグラムを取得するには、V$STANDBY_EVENT_HISTOGRAMビューを問い合せます。

 SQL> select * from v$standby_event_histogram where name like '%lag' and count >0;

ある期間にわたって転送ラグまたは適用ラグを評価するには、その期間の開始時のスタンバイ・データベースにおけるV$STANDBY_EVENT_HISTOGRAMのスナップショットを取得し、その期間の終了時に取得したスナップショットと比較します。

SQL> col NAME format a10
SQL> select NAME,TIME,UNIT,COUNT,LAST_TIME_UPDATED from V$STANDBY_EVENT_HISTOGRAM
 where name like '%lag' and count >0 order by LAST_TIME_UPDATED;

出力例:

NAME       TIME   UNIT       COUNT LAST_TIME_UPDATED

---------- ------ ---------- ----- -------------------
apply lag      23 seconds    3     02/05/2022 16:30:59
apply lag     135 seconds    1     02/05/2022 16:31:02
apply lag     173 seconds    2     02/05/2022 16:32:03
apply lag     295 seconds    2     02/05/2022 16:34:04

転送ラグによって適用ラグが発生する場合があります。転送ラグがほぼゼロで高い適用ラグが確認される場合は、「情報の収集」でこのREDO適用の調査を続行します。

高い転送ラグが確認された場合は、まず「REDO転送のトラブルシューティングおよびチューニング」の方法を使用して、転送ラグに対処します。

情報の収集

許容できない適用ラグが発生した場合は、次の情報を収集します。

• 適用ラグはいつ発生しましたか。

  15分から30分ごとにV$DATAGUARD_STATSおよびV$STANDBY_EVENT_HISTOGRAMのデータを記録して、ラグがいつ開始され、過去24時間に時間の経過とともにラグがどのように変化したかを確認します。

  SQL>select name, value, time_computed, datum_time from v$dataguard_stats where name=’%lag’;

  SQL>select * from v$standby_event_histogram where name like '%lag' and count >0;

• 適用ラグは、日次バッチ操作では毎日午前0時、大規模バッチ操作では毎月、四半期末では毎四半期など、特定の期間に発生しますか。

• スタンバイ自動作業リポジトリ(AWR)レポートV$RECOVERY_PROGRESSからデータを収集し、適用ラグの前および期間中に30分間隔で複数のスタンバイAWRスナップショットを取得します。

  How to Generate AWRs in Active Data Guard Standby Databases (Doc ID 2409808.1)を参照してください。

  たとえば:

  SQL> set lines 120 pages 99
  SQL> alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';
  SQL> select START_TIME, ITEM, SOFAR, UNITS from gv$recovery_progress;

  サンプル出力:

  START_TIME          ITEM                                  SOFAR UNITS
  ------------------- -------------------------------- ---------- ---------
  2022/02/28 23:02:36 Log Files                                 8 Files
  2022/02/28 23:02:36 Active Apply Rate                     54385 KB/sec
  2022/02/28 23:02:36 Average Apply Rate                    12753 KB/sec
  2022/02/28 23:02:36 Maximum Apply Rate                    65977 KB/sec
  2022/02/28 23:02:36 Redo Applied                           2092 Megabytes
  2022/02/28 23:02:36 Last Applied Redo                         0 SCN+Time
  2022/02/28 23:02:36 Active Time                              41 Seconds
  2022/02/28 23:02:36 Apply Time per Log                        1 Seconds
  2022/02/28 23:02:36 Checkpoint Time per Log                   0 Seconds
  2022/02/28 23:02:36 Elapsed Time                            168 Seconds
  2022/02/28 23:02:36 Standby Apply Lag                         2 Seconds

REDOボリュームに関してアプリケーションのスループットを判断する最も簡単な方法は、通常およびピークのワークロード中にプライマリ・データベースで自動ワークロード・リポジトリ(AWR)レポートを収集し、本番データベースによって生成される1秒当たりのREDOデータのバイト数を確認することです。その後、REDOの生成速度をV$RECOVERY_PROGRESSビューのActive Apply Rate列と比較して、スタンバイ・データベースがその速度を維持できるかどうかを確認できます。

適用ラグが想定を上回る場合は、V$RECOVERY_PROGRESSビューを問い合せてREDO適用のパフォーマンスを評価します。このビューには、次の表で説明する列が表示されます。

Average Apply RateにはREDOの到着の待機に費やされたアイドル時間が含まれていて適用パフォーマンスが的確に示されないため、最も有用な統計はActive Apply Rateです。

表15-5 V$RECOVERY_PROGRESSビューの列

列	説明
Average Apply Rate	適用済REDO/経過時間には、REDOのアクティブな適用に費やされた時間およびREDOの到着の待機に費やされた時間が含まれます
Active Apply Rate	REDO適用時間/アクティブ時間は過去3分間の移動平均で、率には、REDOの到着の待機に費やされた時間は含まれません
Maximum Apply Rate	REDO適用時間/アクティブ時間は、過去3分間の移動平均で達成されたピーク測定スループットまたは最大率です。率には、REDOの到着の待機に費やされた時間は含まれません
Redo Applied	適用されたデータの合計量(バイト)
Last Applied Redo	適用された最後のREDOのシステム変更番号(SCN)およびタイムスタンプ。これはREDOストリームに格納される時間であるため、プライマリを基準にしてスタンバイ・データベースの場所を比較するために使用できます。
Apply Time per Log	ログ・ファイルでREDOをアクティブに適用するために費やされた平均時間。
Checkpoint Time per Log	ログ境界チェックポイントに費やされた平均時間。
Active Time	REDOを適用する合計期間(REDOの待機は含まれません)
Elapsed Time	REDOを適用する合計期間(REDOの待機が含まれます)
Standby Apply Lag	REDO適用が適用されていない秒数。スタンバイがプライマリに遅れている可能性があります。
Log Files	現在までに適用されたログ・ファイルの数。

アクティブ・セッション履歴

スタンバイAWRが使用できない場合、またはスタンバイ・データベースがオープン読取り専用モードでない場合は、V$ACTIVE_SESSION_HISTORYビューを使用して上位の待機を収集できます。スタンバイAWRは、提供される追加情報および詳細のためにお薦めしますが、場合によっては次の問合せが役立ちます。

過去30分間の上位10件の待機を選択する場合(30を現在の時間からさかのぼる他の分数に置き換えます):

select * from (
select a.event_id, e.name, sum(a.time_waited) total_time_waited
from v$active_session_history a, v$event_name e
where a.event_id = e.event_id and a.SAMPLE_TIME>=(sysdate-30/(24*60)) 
group by a.event_id, e.name order by 3 desc)
where rownum < 11;

2つのタイムスタンプ間の待機を選択する場合(例では、2021/01/01 00:00:00から2021/01/01 03:00:00までの3時間の期間を示しています):

select * from (
select a.event_id, e.name, sum(a.time_waited) total_time_waited
from v$active_session_history a, v$event_name e
where a.event_id = e.event_id 
and a.SAMPLE_TIME 
between to_date('2021/01/01 00:00:00','YYYY/MM/DD HH24:MI:SS') and to_date('2021/01/01 03:00:00','YYYY/MM/DD HH24:MI:SS')
group by a.event_id, e.name 
order by 3 desc)
where rownum < 11
/

プライマリでのREDO生成率履歴の比較

大規模なバッチ・ジョブ、データ・ロード、データ・ポンプ操作、CREATE TABLE AS SELECT、PDML操作、または月末、四半期末、年度末のバッチ更新など、短期間についてプライマリ・データベースのREDO生成率が例外的に高くなる場合があります。

プライマリ・データベースからREDO生成履歴を取得し、REDO転送時またはREDO適用ラグの開始時と比較します。新しいプラガブル・データベース(PDB)や新しいアプリケーション・サービスの追加など、追加ワークロードが原因で、REDO生成率が例外的に高いのかどうかを確認します。この追加のロードに対応するためにさらにチューニングが必要になる場合があります。

トラブルシューティングの一環として、次の情報を収集するか、次の質問に対処します。

• この問合せを使用して、プライマリ・データベースのREDO生成率の日次履歴を収集します。

  SQL> select trunc(completion_time) as "DATE", count(*) as "LOG SWITCHES", round(sum(blocks*block_size)/1024/1024) as "REDO PER DAY (MB)" 
  from v$archived_log 
  where dest_id=1 
  group by trunc(completion_time) order by 1;

• REDOラグまたは転送ラグが開始する6時間前以降の、ログごとのREDO生成率を収集します。

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

• このプライマリREDO生成率は、以前の履歴と比較して例外的に高いですか。

• 可能な場合は、高いREDO生成率に対応するワークロードを特定し、それが一時的かどうか、またはチューニング可能かどうかを評価します。

  たとえば、大規模なパージ操作では、REDO生成ボリュームを減らすためにパーティション操作を切り捨てるか、または削除することを検討してください。

単一インスタンスREDO適用のチューニング

単一インスタンスREDO適用(SIRA)のチューニングは、反復プロセスであり、マルチインスタンスREDO適用(MIRA)の評価よりさらに前の必須の前提条件です。反復プロセスは次で構成されます

1. システム・リソース・ボトルネックの評価と対処

2. 上位スタンバイ・データベースの待機イベントに基づくチューニング

システム・リソース・ボトルネックの評価

まず、CPU使用率やI/Oサブシステムなどのシステム・リソースを評価します。topやiostatなどのユーティリティまたはOSwatcherやExaWatcherの統計を使用して、これらのリソースに競合があるかどうかを判断します。リソースのボトルネックに対処してREDO適用に必要なリソースを解放すると、適用パフォーマンスを改善できます。

REDO適用は、次の場合に影響を受ける可能性があります。

• 管理対象リカバリ・ノードが完全にCPUバウンドである

• スタンバイ・データベースのI/Oシステムが飽和状態である

• スタンバイ・データベースSGA (特にバッファ・キャッシュ)が、プライマリ・データベースと同じサイズ(またはそれ以上)でない

最適なリカバリ・パフォーマンスのためには、スタンバイ・データベース・システムに次のものが必要です。

• リカバリ・コーディネータ(PR00)およびリカバリ・ワーカー(PRnn)に十分なCPU使用率

• 最大速度時に短いI/O待機時間を維持するために十分なI/O帯域幅

• 同じインタフェースの他のネットワーク・アクティビティに加えて、ピークREDO率ボリュームを受信できるネットワーク・インタフェース

• 対称SGAおよびバッファ・キャッシュに対応するために十分なメモリー。ログ・バッファおよびバッファ・キャッシュのサイズは、通常、REDO適用パフォーマンスに最も影響を及ぼします

収集内容と収集方法は、次のとおりです。

• スタンバイ自動作業リポジトリ(AWR)レポートを30分以下の間隔で収集します。

  『Oracle Databaseパフォーマンス・チューニング・ガイド』のActive Data Guardスタンバイ・データベースでの自動ワークロード・リポジトリの管理に関する項を参照してください

• よりリアルタイムで詳細な待機については、アクティブ・セッション履歴(ASH)データを収集します。

  『Oracle Databaseパフォーマンス・チューニング・ガイド』のアクティブ・セッション履歴レポートの生成に関する項を参照してください

• Oracle Linux OSwatcherまたはOracle Exadata ExaWatcherのデータを収集して、システム・リソースを分析します。

  Exadataシステムについては、『Oracle Exadata Database Machineメンテナンス・ガイド』のExaWatcherチャートを使用したExadata Database Machineのパフォーマンスの監視に関する項を参照してください

• topプロセス情報を収集し、topまたはpsコマンドを使用して、リカバリ・コーディネータ(PR00)がCPUバウンドかどうかをチェックします。

リソース・ボトルネックの一般的なインジケータおよび原因は次のとおりです。

• CPUアイドル時間が少ない場合は、システムがCPUバウンドであることを示している可能性があります

• ディスクまたはフラッシュのサービス時間が長いか、またはIOPSが高い場合は、I/Oの競合または飽和を示している可能性があります

• 多数のアクティブ・データベースを持つサイズ不足のシステムおよび共有システムでは、これらのリソースの競合が発生する可能性があります

• Active Data Guardスタンバイでワークロードをレポートする場合も、競合が発生する可能性があります

データベース待機イベントの評価によるREDO適用のチューニング

システム・リソース・ボトルネックがないことを確認したら、次に、スタンバイ自動作業リポジトリ(AWR)レポートを参照して、スタンバイ・データベースの待機イベントを評価します。

データベース待機イベントを評価する前に、リカバリに関連するプロセス・フロー中に待機が発生する場所を理解することが重要です。

1. REDOは、リモート・ファイル・サーバー(RFS)プロセスによってスタンバイで受信されます。

   RFSプロセスは、スレッドごとに新しく受信したREDOをそのスレッドの現在のスタンバイREDOログに書き込みます。RFS書込み操作は、rfs random I/O待機イベントによって追跡されます。

2. REDOが書き込まれると、リカバリ・コーディネータ・プロセス(pr00)がスレッドごとにスタンバイREDOログ(またはアーカイブ・ログ)からREDOを読み取ります。

   この読取りI/Oは、log file sequential read待機イベントによって追跡されます。

3. リカバリ・コーディネータは、すべてのスレッドのREDOをマージして、リカバリ・ワーカーのメモリー・バッファに配置します。

   リカバリ・メモリー・バッファへの書込みおよび読取りの待機イベントは、parallel recovery read buffer free待機イベントおよびparallel recovery change buffer free待機イベントによって追跡されます。

4. リカバリ・プロセスは、メモリー・バッファからREDOまたは変更ベクトルを取得し、変更をデータ・ブロックに適用するプロセスを開始します。

   まず、リカバリ・ワーカーがリカバリを必要とするデータ・ブロックを判別し、そのブロックがバッファ・キャッシュにまだ存在しない場合には読み込みます。

   リカバリ・ワーカーによるこの読取りI/Oは、recovery read待機イベントによって追跡されます。

5. いずれかのスレッドのプライマリでログが切り替えられると、スタンバイは同時にそのスレッドのスタンバイREDOログのスイッチを調整します。

   以前のバージョンでは、スタンバイでログ・スイッチを実行すると、チェックポイント全体が強制的に実行されて、バッファ・キャッシュからスタンバイのデータ・ファイルにすべての使用済バッファがフラッシュされます。Oracle Database 18c以降では、チェックポイントも定期的に発生するため、すべてのフェーズにわたってチェックポイントI/Oが償却されます。

   チェックポイントでは、複数のデータベース・ライター・プロセス(DBWR)は、db file parallel write待機イベントによって追跡される書込み時間とともに、データ・ファイル・ブロックをデータ・ファイルに書き込みます。チェックポイントが完了するまでの合計時間は、checkpoint complete待機イベントでカバーされます。

適用フェーズでは、通常、単一のCPUでリカバリ・コーディネータ・プロセス(pr00)の使用率が高くなりますが、チェックポイント・フェーズでは、DBライター・プロセス(dbwn)のCPU使用率が増加し、データファイルへの書込みI/Oの増加が示されます。

次の表は、リカバリ・プロセスに関連する待機イベントの説明とチューニングのアドバイスを示しています。

表15-6 リカバリ・プロセスの待機イベント

列	説明	チューニングに関する推奨事項
ログ・ファイル順次読取り	パラレル・リカバリ・コーディネータは、オンラインREDOログ、スタンバイREDOログまたはアーカイブREDOログからのI/Oを待機しています。	アーカイブ・ログ、スタンバイREDOログまたはオンラインREDOログが存在するASMディスク・グループまたはストレージ・サブシステムのI/O帯域幅をチューニングするか、拡大します。
Parallel recovery read buffer free	このイベントは、すべての読取りバッファがワーカーによって使用されていることを示し、通常はリカバリ・ワーカーがコーディネータに遅れていることを示します。	_log_read_buffersを最大の256に増やします
Parallel recovery change buffer free	パラレル・リカバリ・コーディネータは、リカバリ・ワーカーがバッファを解放するのを待機しています。このイベントも、リカバリ・ワーカーがコーディネータに遅れていることを示します。	データ・ファイルが存在するASMディスク・グループまたはストレージ・サブシステムのI/O帯域幅をチューニングするか、拡大します。
Data file init write	パラレル・リカバリ・コーディネータは、ファイルの自動拡張などによるファイルのサイズ変更が終了するのを待機しています。	これはチューニング不可能なイベントですが、プライマリ・データベースのワークロードを評価して、データ・ファイルのサイズ変更操作が非常に多い理由を把握します。オプションで、AUTOEXTENDが有効な場合に、より大きなNEXTサイズを使用します
Parallel recovery control message reply	パラレル・リカバリ・コーディネータは、すべてのリカバリ・ワーカーが同期制御メッセージに応答するまで待機しています。	N/A。これはアイドル・イベントです。
Parallel recovery slave next change	パラレル・リカバリ・ワーカーは、コーディネータから変更が転送されるのを待機しています。このイベントは、実質的にはリカバリ・ワーカーのアイドル・イベントです。リカバリ・ワーカーが使用するCPU時間を特定するには、このイベントの経過時間を起動済ワーカーの数で割り、その値を合計経過時間から引きます。	N/A。これはアイドル・イベントです。
DB File Sequential Read	パラレル・リカバリ・ワーカー(またはシリアル・リカバリ・プロセス)は、同期データ・ブロックのバッチ読取りが完了するのを待機しています。	データ・ファイルが存在するASMディスク・グループまたはストレージ・サブシステムのI/O帯域幅をチューニングするか、拡大します。
Checkpoint completed	リカバリは、チェックポイントの完了を待機しており、REDO適用は現時点で変更を適用していません。	データ・ファイルが存在するASMディスク・グループまたはストレージ・サブシステムのI/O帯域幅をチューニングするか、拡大します。 また、checkpoint completed待機イベントがdb file parallel write待機イベントより低くなるまで、db_writer_processesの数を増やします。 プライマリおよびスタンバイでのオンライン・ログ・ファイル・サイズを増やして、ログ・スイッチの境界における完全なチェックポイントの数を減らすことも検討します。
Recovery read	パラレル・リカバリ・ワーカーは、バッチ・データ・ブロックI/Oを待機しています。	データ・ファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。
Recovery apply pending and/or recovery receive buffer free (MIRA)	Recovery apply pending = 適用ワーカーがすべての保留中の変更を特定のSCNまで適用するのを、logmergerプロセスが待機した時間(センチ秒単位)。 Recovery receive buffer free = インスタンス上の受信者のプロセスが、受信したバッファを次の変更に備えて解放できるように、適用ワーカーが受信済バッファから変更を適用するのを待機するために費やした時間(センチ秒単位)。	_mira_num_local_buffersおよび_mira_num_receive_buffersを増やします これらのパラメータは、それ自体の値(MB)に適用インスタンスの数を乗算した合計に等しい共有プールの領域を使用します。

スタンバイ・データベースでのAWRの生成の詳細は、How to Generate AWRs in Active Data Guard Standby Databases (Doc ID 2409808.1)を参照してください。

必要に応じたマルチインスタンスREDO適用の有効化

マルチインスタンスREDO適用(MIRA)には、スタンバイ・データベースのOracle RACデータベース・インスタンス全体で複数のリカバリ・コーディネータおよびREDO適用(ワーカー)プロセスを実行することで、REDO適用を改善できる可能性があります。MIRAはOracle Databaseの以降のリリース向けに最適化されており、REDO適用の利点はワークロードによって異なります。

MIRAを考慮する際の前提条件

• 単一インスタンスREDO適用(SIRA)は完全にチューニングされており、I/Oバウンドではありません。

• リカバリ・コーディネータ(PR00)はCPUバウンドです。

  1時間にわたり、リカバリ・コーディネータ/ログ・マージ・プロセスora_pr00_<SID>のCPU使用率を確認します。その時間の大部分で、コーディネータ・プロセスのCPU使用率%が70%を超える場合、ボトルネックが発生している可能性があり、MIRAによりリカバリ・パフォーマンスを改善できます。

  次に、pr00のCPU使用率を示す、topコマンドからの出力例を2つ示します。

  
  図sira_well_tuned.pngの説明
  図sira_poorly_tuned.pngの説明

  リカバリ・コーディネータのCPU使用率が数回の短時間のスパイクのみで70%を大幅に下回る場合、CPUバウンドではありません。リソースに問題があるか、追加のチューニングによってパフォーマンスが改善する可能性があります。リカバリ・コーディネータがCPUバウンドでない場合は、SIRAのチューニングに戻ります。

• ほとんどのMIRA最適化はOracle Database 19cに実装されており、以前のデータベース・リリースでは使用できません。実際に、Oracle Database 19.13以降のデータベース・リリースを使用することをお薦めします。これは、このリリースには一部の重要な修正が含まれるためです(29924147、31290017、31047740、31326320、30559129、31538891、29785544、29715220、29845691、30421009、30412188、30361070、32486528、33821145、28389153など)。

• InfiniBandネットワーク・ファブリックまたはRDMA over Converged Ethernet (RoCE)ネットワーク・ファブリックに基づくすべてのOracle Exadata Database Machineシステムには、次の表に示すように、プライマリ・データベースで追加のステップが必要です。

  表15-7 MIRAを有効にするためのOracle Exadata Database Machineの前提条件

  Exadataシステム	データベース・リリース	ステップ
  永続メモリー(PMEM)のあるExadataストレージ・セル	19.13以降	追加ステップはありません
  PMEMなし	19.13以降	すべてのインスタンスに対して動的パラメータ_cache_fusion_pipelined_updates_enable=FALSEを設定します
  任意のExadataシステム	19.12以前	1. パッチ31962730を適用します 2. すべてのインスタンスに対して動的パラメータ_cache_fusion_pipelined_updates_enable=FALSEを設定します

ノート:

MIRAでは、動的パラメータ_cache_fusion_pipelined_updates_enableまたは静的パラメータ_cache_fusion_pipelined_updatesをFALSEに設定して生成されたREDOのみをリカバリできます。

マルチインスタンスREDO適用およびチューニングの有効化

1. マルチインスタンスREDO適用(MIRA)を有効にするには、適用インスタンスの数を指定します。

   以前の単一インスタンスREDO適用(SIRA)のチューニング変更はすべてそのままにします。MIRAに対するMAAの推奨事項は、すべてのスタンバイ・データベース・インスタンスを適用に使用することです。

2. 次のいずれかの方法を使用して、MIRAを有効にします。

   • Oracle Data Guard Brokerプロパティを設定します

     ‘ApplyInstances’=<#|ALL>

   • または、次を実行します

     SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION INSTANCES ALL;

3. MIRAのチューニング後にシステム・リソースの競合を確認します。

   「システム・リソース・ボトルネックの評価」で説明されている同じプラクティスに従います。

4. ここで説明されている待機イベントに基づいてMIRAをチューニングします。

   「データベース待機イベントの評価によるREDO適用のチューニング」の方法に従います。

   recovery apply pendingまたはrecovery receive buffer freeが待機イベントの上位にある場合は、次のようにします。

   • この待機イベントを減らすには、_mira_num_receive_buffersおよび_mira_num_local_buffersを100ずつ増分的に増やします。

     これらのパラメータは、インスタンス間でブロックを渡すための追加のバッファ領域を提供します。追加のバッファ領域に対応するためにSGAに十分なメモリーがあるかどうかを評価します。

     関連する各MIRA Oracle RACインスタンスの追加メモリー要件 = (_mira_num_receive_buffers + _mira_num_local_buffers) * (RACインスタンスの数 * 2) MB

     例: _mira_num_receive_buffers=500および_mira_num_local_buffers=500の場合、(500+500) *(4-node RAC *2) = SGAからの8000MB

   • _mira_rcv_max_buffers=10000を設定します

非常に大きいREDO適用ギャップの対処

適用ラグが24時間を超える場合は、すべてのREDOを適用するのではなく、スタンバイ・ロールフォワードの方法を使用してギャップをスキップすることを検討してください。How to Roll Forward a Standby Database Using Recover Database From Service (12.2 and higher) (Doc ID 2850185.1)を参照してください

このアプローチでは、変更されたOracleデータ・ブロックをプライマリ・データベースから直接プルし、すべてのREDOを適用するために必要な時間の半分に大きなREDOギャップを緩和できる可能性があります。

このアプローチの短所は次のとおりです。

• REDO適用およびスタンバイ・データベースに固有の、論理破損および書込み欠落の検出チェックおよびバランシングがスキップされます
• これらのコマンドを発行し、完了後にREDO適用を再開するには、手動操作が必要です。

データ・ブロックは、引き続き物理破損について検証されます。

データ保護を犠牲にしたREDO適用率の改善

プライマリに遅れないよう、さらに高いREDO適用率を達成するために、REDO適用をチューニングできない状況は非常にまれです。このような場合、REDO適用のパフォーマンスを向上させるために、推奨されるデータ保護設定をオフにすることが必要になる場合があります。

次の表は、いくつかの考えられる個別変更とその潜在的な利益およびトレードオフを示しています。

変更	潜在的な利益	潜在的なトレードオフ
REDO適用を停止し、サービスからのリカバリを使用する How to Roll Forward a Standby Database Using Recover Database From Service (12.2 and higher) (Doc ID 2850185.1)を参照してください	ギャップが24時間を超える場合など、大規模なREDO転送またはREDO適用ギャップからリカバリするための最適化されたアプローチ	論理ブロックまたは書込み欠落のデータ保護チェックが行われません REDOブロックのチェックサム検証が行われません
Active Data Guardではなくスタンバイをマウントする	REDO適用のパフォーマンスが5-10%向上する可能性はありますが、大部分はバッチ・ワークロードが対象です	物理破損の自動ブロック修復がリアルタイムで行われません スタンバイに対して問合せがリアルタイムで行われません スタンバイがアプリケーションのしきい値を超えて遅れている場合、前述のいずれのトレードオフも関連しない可能性があります
スタンバイでDB_BLOCK_CHECKINGを無効化または削減する	REDO適用中のCPU使用率が削減されます CPUリソースが制限されている場合、この変更によりREDO適用が10-40%向上する可能性があります	まれに発生する可能性のある論理ブロック破損が検出されず、スタンバイに伝播される場合があります
フラッシュバック・データベースを無効化する	RECOのフラッシュバックIOPS要件が排除されます ストレージIOPSが制約リソースである場合、この変更がREDO適用パフォーマンスに役立つ可能性があります	スタンバイを即時に巻き戻すことができなくなります
プライマリおよびスタンバイでDB_LOST_WRITE_PROTECTを無効にする	書込み欠落を検出するためにプライマリで生成されたブロック読取りREDOにより、スタンバイでの追加の読取りIOPSが排除されます IOPS容量が飽和状態の場合、この変更はオプションです	プライマリ・データベースまたはスタンバイ・データベースで、書込み欠落が早期に検出されません

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

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

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

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

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

四半期ごと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• PRIMARY DATABASEセクション:

  • DGMGRL> VALIDATE DATABASE VERBOSE 'Primary_DBName';

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

    • SELECT * FROM dba_pdb_saved_states;

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

• 各STANDBY DATABASE STANDBY_DB_UNIQUE_NAMEセクション:

  • DGMGRL> VALIDATE DATABASE VERBOSE 'Standby_DBName';

  • DGMGRL> VALIDATE DATABASE 'Standby_DBName' SPFILE;

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

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

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

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

  • DGMGRL> VALIDATE NETWORK CONFIGURATION FOR ALL;

• REDO率履歴セクション:

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

例:

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

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

DGMGRL> validate database [verbose] database_name

Database Role: Physical standby database
 Primary Database: standby_db_unique_name

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

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

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

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

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

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

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

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

   DGMGRL> SET TRACE_LEVEL SUPPORT;

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

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

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

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

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

   ALTER SYSTEM SET EVENTS ‘16453 trace name context forever, level 15’;

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

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

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

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

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

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

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

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

DGMGRL> SWITCHOVER TO database_name;

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

DGMGRL> FAILOVER TO database_name [IMMEDIATE];

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

診断情報のソース

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

• データベース・ステータスの情報 - SHOW DATABASE VERBOSE db_unique_nameコマンドを使用して、データベースの簡単な説明(名前、ロールなど)、データベースの状態、健全性チェックの問題に関する情報を入手できます。

  DGMGRL> SHOW DATABASE VERBOSE db_unique_name

• Oracleアラート・ログ・ファイル - ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Oracle Data Guardをトラブルシューティングする場合は、このような情報のアラート・ログ・ファイルを確認できます。
• Oracle Data Guard "ブローカ・ログ・ファイル" - ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作とステータス情報がブローカ・ログ・ファイルに記録されます。このファイルはOracle Data Guardの障害を診断する際に役立ちます。TraceLevel構成プロパティは、ブローカ・ログ・ファイルで報告される診断情報のレベルを指定するために使用されます。ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

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

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

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

DGMGRL> SWITCHOVER TO database_name;

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

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

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

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

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

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

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

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

    SQL> ALTER DATABASE SWITCHOVER TO target_db_name;

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

Data Guardのパフォーマンス観測

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

Oracle Data GuardおよびOracle MAA Goldリファレンス・アーキテクチャは、プライマリ・データベース、クラスタまたはサイトに障害が発生した場合やアクセスできない場合に、障害時リカバリおよび高可用性ソリューションを提供します。

Data Guard環境はそれぞれ異なり、ロール・トランジションを実行する時間は大きく異なる場合があります。SGAサイズ、Oracle RACインスタンスの数、PDBの数、データ・ファイルおよびロール・トランジション時のデータベースへの接続を含む(これらに限定されない)変数は、特定のロール・トランジションの長さに影響します。

通常、Data Guardのスイッチオーバー(計画メンテナンス)は、Data Guardフェイルオーバー(計画外停止)より少し長くなります。

次の情報は、ロール・トランジションを最適化する方法を学習することを目的としています。

Data Guardスイッチオーバー期間

計画メンテナンスのアプリケーション停止時間を最小化しようとする場合:

• 計画メンテナンス期間の前に、バッチ・ジョブまたは実行時間が長いレポートを回避または遅延します。ピーク処理期間も回避する必要があります。

• Data Guardスイッチオーバーは正常であり、ソース・プライマリ・データベースの停止が必要であるため、すべてのアプリケーション排出タイムアウトを考慮します。Oracle Clusterwareサービスの排出属性および設定については、「アプリケーションの継続的なサービスの有効化」を参照してください。

• 単一インスタンス(非RAC)でのData Guardスイッチオーバー操作は、30秒未満にできます。

• Real Application ClusterでのData Guardスイッチオーバー操作は異なりますが、30秒から7分にすることができます。より多くのPDB (25を超えるPDBなど)がある場合、より多くのアプリケーション・サービス(200サービスなど)がある場合、およびデータベースに多数のデータ・ファイル(1000個のデータ・ファイルなど)がある場合、期間は長くなることがあります。

次のグラフと表は、MAAチューニング推奨事項を実装したときにスイッチオーバー操作時間がどれだけ短縮する可能性があるかの一例を示しています。結果は異なります。

図15-1 計画メンテナンス: DRスイッチの期間(秒)

「図15-1 計画メンテナンス: DRスイッチ期間(秒)」の説明

計画DRスイッチ(スイッチオーバー)	初期構成	チューニングされたMAA構成
プライマリをスタンバイに変換	26秒	21秒
スタンバイをプライマリに変換(C2P)	47秒	7秒
新規プライマリのオープン(OnP)	152秒	14秒
PDBのオープンおよびサービスの開始(OPDB)	130秒	39秒
合計アプリケーション停止時間	355秒(5分55秒)	81秒(78%低下)

「チューニングした」時間は、次のMAA推奨プラクティスを実装することで達成されています。

• ビッグファイル表領域の使用

• Oracle Data Guardの構成ベスト・プラクティス

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

Data Guardフェイルオーバー期間

DRシナリオでアプリケーションの停止時間を最小化しようとする場合:

• リカバリ時間目標(RTOまたはデータベースの停止時間)およびリカバリ・ポイント目標(RPOまたはデータ損失)を制限するには、自動検出およびフェイルオーバーが必要です。『Oracle Data Guard Broker』のファスト・スタート・フェイルオーバーを参照してください。

• データベース管理者は、FastStartFailoverThresholdを設定して、自動フェイルオーバーを開始する前に適切な検出時間を決定できます。『Oracle Data Guard Broker』のファスト・スタート・フェイルオーバーの有効化タスク4: FastStartFailoverThreshold構成プロパティの設定を参照してください。

  信頼性の高いネットワークの場合、MAAの推奨設定は5秒から60秒です。Oracle RACを再起動すると、プライマリの一時エラーからもリカバリできます。このしきい値を高く設定すると、再起動が完了してフェイルオーバーを回避できますが、一部の環境では負担が大きくなる可能性があります。トレードオフは、実際のフェイルオーバーが必要な場合にアプリケーションの停止時間が増加するということです。

• 単一インスタンス(非RAC)でのData Guardフェイルオーバー操作は、20秒未満にできます。

• Real Application ClusterでのData Guardのフェイルオーバー操作は異なりますが、20秒から7分にすることができます。より多くのPDB (25を超えるPDBなど)がある場合、より多くのアプリケーション・サービス(200サービスなど)がある場合、およびデータベースに多数のデータ・ファイル(1000個のデータ・ファイルなど)がある場合、期間は長くなる場合があります。

次のグラフと表は、MAAチューニング推奨事項を実装したときにフェイルオーバー操作時間がどれだけ短縮する可能性があるかの一例を示しています。結果は異なります。

図15-2 計画外DRフェイルオーバーの期間(秒)

「図15-2 計画外DRフェイルオーバーの期間(秒)」の説明

計画外停止/DR (フェイルオーバー)	初期構成	チューニングされたMAA構成
クローズしてマウント(C2M)	21秒	1秒
ターミナル・リカバリ(TR)	154秒	2秒
プライマリに変換(C2P)	114秒	5秒
新規プライマリのオープン(OnP)	98秒	28秒
PDBのオープンおよびサービスの開始(OPDB)	146秒	16秒
合計アプリケーション停止時間	533秒(8分53秒)	52秒(90%低下)

「チューニングした」時間は、次のMAA推奨プラクティスを実装することで達成されています。

• Data Guardのファスト・スタート・フェイルオーバーを評価し、異なるFastStartFailoverThreshold設定でテストします

• ビッグファイル表領域の使用

• Oracle Data Guardの構成ベスト・プラクティス

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

カスタマの事例

次の表に、Oracleカスタマからの実際のData Guardロール・トランジション期間の観測を示します。

プライマリおよびData Guardの構成	観測されたRTO
Database Cloud (DBCS)で大量のOLTPワークロードを使用する単一インスタンス・データベースのフェイルオーバー。Data Guardのしきい値は5秒です。	20秒
大量のOLTPワークロードを使用する4ノードRACによる大規模な商業銀行POCの結果	51秒(計画外DR) 82秒(計画DR)
大量のOLTPワークロードを使用するExaDB-Dの2ノードRAC MAAテスト	78秒
大量のOLTPワークロードを使用するADB-Dの2ノードRAC MAAテスト(25 PDB、250サービス)	104秒
大量のOLTPワークロードを使用するADB-Dの2ノードRAC MAAテスト(50PDB、600サービス)	180秒
大量のOLTPワークロードを使用するADB-Dの2ノードRAC MAAテスト(4 CDB、合計100 PDB、500サービス)	164秒
12ノードRAC、400GBのSGA、4000以上のデータ・ファイルのOracle SaaSフリート(数千) (ノート: データ・ファイルの数を数百に削減すると、停止時間を数分短縮できます)	6分未満
四半期ごとのサイト・スイッチを使用する7-12ノードRACのサード・パーティのSaaSフリート(数千)	5分未満

Data Guardによるアプリケーション・スループットおよびレスポンス時間の影響

Data Guardの最大パフォーマンス保護モードまたはASYNC転送を有効にすると、アプリケーションのスループットおよびレスポンス時間の影響はほぼゼロになります。スループットおよびアプリケーション・レスポンス時間は、通常、このような場合にはまったく影響しません。

Data Guardの最大可用性モード、最大保護モードまたはSYNC転送では、アプリケーションのパフォーマンスへの影響が異なります。そのため、SYNC転送を有効にする前に、アプリケーションのパフォーマンス・テストが常に推奨されます。チューニングされたネットワークおよび低ラウンドトリップ待機時間(RTT)では、データ損失ゼロ・ソリューションを保持するために、パラレルに使用可能なすべてのSYNCスタンバイ・データベースに対してすべてのログ・コミットを確認する必要がある場合でも、影響は無視できることもあります。

次に、アプリケーションのスループットへの影響の例を示しますが、アプリケーションの影響はワークロードによって異なります。

図15-3 MTU=9000によるアプリケーションの影響

「図15-3 MTU=9000によるアプリケーションの影響」の説明

ネットワークRTT待機時間(x軸)が低いと、アプリケーション(TPSまたはy軸)のスループットが低下することに注意してください。

このネットワーク環境では、ログ・メッセージ・サイズがSYNCで大幅に増加したため、MTUを1500 (デフォルト)から9000 (ジャンボ・フレームなど)に増やすと、大幅に向上しました。MTUサイズが大きいほど、REDO送信リクエスト当たりのネットワーク・パケットの数が少なくなります。

ソケット・バッファ・サイズやMTUを含むネットワークのチューニングの詳細は、「ネットワーク・パフォーマンスの評価および最適化」を参照してください。

RTT待機時間が長くなってスループットが大幅に低下しても、アプリケーションで同時実行性が増大する可能性がある場合は、TPSを増やすことができます。前述のチャートでは、最後の2つの列で、ユーザーを追加することでワークロードの同時実行性が向上しました。

SYNC転送を使用したアプリケーション・レスポンス時間は長くすることもできますが、各アプリケーションのワークロードおよびネットワーク・チューニングによって異なります。SYNC転送では、すべてのログ書込みがスタンバイSYNC確認応答を待機する必要があります。この追加の待機によって、コミットの確認応答を待機するフォアグラウンドが増えます。コミットはスタンバイ・データベースで確認する必要があり、より多くのフォアグラウンドがコミットを待機しているため、次のチャートに示すように、平均ログ書込みサイズが大きくなると、REDO/データ転送時間に影響を与えます。

図15-4 チューニング済およびデフォルトMTUのデータベース・レスポンス時間(ミリ秒)と待機時間(ミリ秒)

「図15-4 チューニング済およびデフォルトMTUのデータベース・レスポンス時間(ミリ秒)と待機時間(ミリ秒)」の説明

この例では、AWRレポートから、平均REDO書込みサイズが大幅に増え、チューニングMTUによってレスポンス時間の影響が削減されたことがわかりました。ソケット・バッファ・サイズやMTUを含むネットワークのチューニングについては、「ネットワーク・パフォーマンスの評価および最適化」を参照してください。

ネットワークのチューニング後、レスポンス時間の影響が予測可能になり、少なくなりました。レスポンスの影響は、アプリケーションのワークロードによって異なります。

Data Guardで最高のアプリケーション・パフォーマンスを得るには、次のプラクティスを使用します。

• 最初にData Guardを使用せずにアプリケーションをチューニングします。ASYNC転送についても同様のパフォーマンスが確認されます

• 「Oracle Data Guardの構成ベスト・プラクティス」を実装します

• 「REDO転送のトラブルシューティングおよびチューニング」の方法の使用

• SYNCを使用してネットワークをチューニングし、アプリケーションのパフォーマンスを向上させます。「ネットワーク・パフォーマンスの評価および最適化」を参照してください

• SYNC転送のスループットの向上に役立つアプリケーション・ワークロード固有の変更は次のとおりです。

  • 同時実行性またはユーザーの追加を評価して、スループットを向上させます。

  • データ損失ゼロを必要としない特定のセッション内の重要でないワークロードの場合は、拡張COMMIT_WRITE属性をNOWAITに評価します。

    この場合、確認応答を受信する前にコミットできます。REDOは永続REDOログに送信されますが、非同期で実行されます。リカバリは、適用されるREDO内のすべての永続コミット済トランザクションに対して保証されます。『Oracle Databaseリファレンス』のCOMMIT_WRITEを参照してください。