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

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

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

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

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

トポロジ情報の収集

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

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

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

スタンバイ・データベースにプライマリ・データベースと対称なハードウェアと構成があり、ネットワークが信頼性が高く適切にチューニングされており、十分な帯域幅を備えている場合は、転送ラグは10秒未満であり、ほとんどの場合は1秒未満となります。

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

転送ラグと適用ラグの違いを理解するには、まず、転送ラグが、まだスタンバイ・データベースで受信されていないREDOの量であることを認識してください。転送ラグは、リカバリ・ポイント目標(RPO)に影響します。

適用ラグは、まだスタンバイに適用されていないREDOの量を示しており、転送ラグを含んでいます。そのため、適用ラグは、現在の転送ラグ以上になり、それより高くなることがありますが低くなることはありません。適用ラグは、対応する転送ラグがあるときはRPOに対する影響を示し、転送ラグがないときはリカバリ時間目標(RTO)に対する影響を示している可能性があります。これは、適用されていないREDOが、通常は、スイッチオーバー操作やフェイルオーバー操作の結果としてスタンバイがプライマリになる前に、スタンバイに適用されるためです。

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

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

DATUM_TIME列は、ラグ・メトリックの計算に使用されたデータを受信した、スタンバイ・データベースでのローカル時間です。したがって、レポートされるラグは、DATUM_TIMEの"時点"のものです。ここでは、プライマリとスタンバイがそれらの接続を維持していると想定されています。ただし、プライマリとスタンバイとの接続が失われ、複数の問合せにわたりDATUM_TIMEが変化しない場合、潜在的なデータ損失は、正確に計算できず、その問合せからのDATUM_TIMEとスタンバイ・データベースでの現在時間との差分になると推測されます。

スタンバイ・インスタンスが最後に起動されてからの転送ラグまたは適用ラグの値の履歴を示すヒストグラムを取得するには、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時、大規模バッチ操作の間に毎月、四半期末の間に毎四半期)?
  • 有効になっている宛先ごとにLOG_ARCHIVE_DEST設定をチェックし、REDOのCOMPRESSIONまたはENCRYPTIONが有効になっているどうかを確認します。送信前にREDOを圧縮または暗号化し、スタンバイでの受信時に圧縮解除または暗号化解除する必要があるため、REDO転送スループット全体に悪影響を及ぼす可能性があります。その変更が最新かどうか、およびこれらの設定属性の無効化をテストできるかどうかを確認します。
  • Oracle Net設定をチェックして、Oracle Net暗号化が有効になっているかどうかを評価します。Oracle Net暗号化が有効な場合、いつ、どのレベルで有効化されましたか。REDOは送信前に暗号化され、スタンバイでのREDOの受信時に暗号化解除されるため、Oracle Netの暗号化によってREDOスループットが大幅に低下する可能性があります。オプションで、暗号化レベルを無効化または低減して、REDO転送ラグが減少するかどうかを確認します。Oracle Databaseのネイティブ・ネットワーク暗号化とデータ整合性の構成を参照してください。

プライマリでの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率を収集します。

    select begin_time,instance_number,metric_name,
 round(value/1024/1024) "Max Rate in MB"
from
(select to_char(begin_time,'DD-MON-YYYY HH24')
 begin_time,instance_number,metric_name,max(value) value
from dba_hist_sysmetric_history
where metric_name = 'Redo Generated Per Sec'
and trunc(begin_time) >=trunc(sysdate-7)
group by to_char(begin_time,'DD-MON-YYYY HH24'),instance_number,metric_name)
 order by 1,3;

    オプションで、'7'を他の値に変更して出力における日数を変更します。

    望ましい問合せはdba_hist_sysmetric_historyです(より正確な情報が提供されるため。ただし、保存はAWR保存によって制限されます)。探している日付を前の問合せから入手できない場合は、かわりにv$archived_logを使用して、ログごとの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('2024/10/15 08:00:00','YYYY/MM/DD HH24:MI:SS') 
and to_date('2024/11/15 11:00:00','YYYY/MM/DD HH24:MI:SS') 
and dest_id=1 order by first_time;

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

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

    AWR、およびスナップショットとAWRレポートの生成の詳細は、Oracle AI 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バウンドである
  • ASYNCプロセス(TT0n)はCPUバウンドです。つまり、CPUの70%以上を使用します
  • プライマリ・データベースまたはスタンバイ・データベースの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では、TT0nプロセスを使用してプライマリ・データベースのログ・バッファから直接REDOが送信されます。TT0nプロセスがペースを維持できず、REDOをスタンバイ・データベースに送信できるようになる前にログ・バッファがリサイクルされる場合は、TT0nプロセスが、自動的に、ディスク上のオンラインREDOログ・ファイル(ORL)からの読取りと送信に移行します。TT0n送信は、現在の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統計はファイルの先頭と末尾に示されます。ファイルの末尾にある統計では、どこで非同期送信に時間がかかったかについての見通しが得られます。

ノート:

非同期転送プロセスとトレースファイルを特定します:
SELECT DP.NAME, DP.PID OSPID, P.TRACEFILE FROM V$DATAGUARD_PROCESS DP, V$PROCESS P
 WHERE DP.PID=P.SPID AND DP.ROLE LIKE 'async%';

たとえば:

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統計を参照する場合(なお、出力におけるすべての時間はマイクロ秒単位です):

まず、クライアント側で最も時間がかかった場所(ネットワーク、ディスクまたはData Guard)を確認します。

ネットワーク統計

  • 'Average time : NETWORK SEND' - ここの値が大きい場合は(1マイクロ秒を超えている)、ネットワーク暗号化またはREDO圧縮が有効になっていることを示している可能性があります(パケットをネットワーク上に配置するのに時間がかかるため)。

  • Total bytes completed synchronously / Total bytes written - この割合が90%未満の場合は、TCPソケット・バッファを増やすと有効である可能性があります。これには、tcp_rmem and tcp_wmemの最大値を変更し、転送を再開始する必要があります。

ディスク統計

  • Log buffer blocks - 最良のシナリオは、すべてのブロックをディスクではなくログ・バッファ(つまり、メモリー)から読み取る場合です(たとえば、先読みやディスクのストール)。そうでない場合は、プライマリでlog_bufferパラメータのサイズを増やすと、転送の改善に役立つ場合があります。log_bufferパラメータの変更には、データベースのバウンスが必要です(Oracle RACローリングでサポートされている)。

    なお、ログ・バッファが大きいほど、非同期プロセスによって読み取られる次のREDOがログ・バッファに格納されるチャンスが高まります。ワークロードが重く持続的である場合は、最終的に、読取りがディスクに送られる可能性が高くなります(特に、暗号化や待機時間など、転送速度が低下する別の要因がある場合)。

  • "Disk stall blocks"の割合が高い場合は、_log_archive_buffersの値を256に増やします。この値の変更には、データベースの再起動を有効にする必要があります(Oracle RACローリングでサポートされている)。

Data Guard統計

  • 消費時間のほとんどがData Guard統計内にあり、転送ラグがある場合は、システム全体にリソースの問題がある可能性があります(CPUやメモリー不足など)。システムのボトルネックについて、ExaWatcherまたはOSWatcherを確認します。

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

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

REDO転送のみに対するOracle Net暗号化の無効化

Oracle Net暗号化では、REDO生成率が高くなるとREDO転送に悪影響がある可能性があります。暗号化によって、受信プロセスの送信のCPU使用率が増えて、それにより、CPUバウンド・プロセスが発生する場合があります。

アプリケーションのクライアント接続にOracle Net暗号化が必要な場合もありますが、REDO転送に対して暗号化を無効にしても業務に支障をきたさない場合もあります。たとえば、プライマリとスタンバイが同じデータ・センターにある場合や、フル・トランスポート・パスがお客様のファイアウォールによって保護されている場合です。この場合は、ネット・サービス記述子を変更することで、REDO転送のみに対してOracle Net暗号化を無効にできます。

スタンバイ・データベースのネット・サービス名の記述子に次のSECURITY句を含めることで、Oracle Net暗号化が、この別名を使用する接続のみに対して無効になります。同じ設定をスタンバイ・データベース・クラスタ上のプライマリ・データベース・エントリに追加する必要があります。 

(SECURITY=(ENCRYPTION_CLIENT=REJECTED))

例:

net_service_name= 
(DESCRIPTION= 
  (ADDRESS_LIST= 
    (ADDRESS=(PROTOCOL=tcp)(HOST=<standby scan listener>)(PORT=1521)) 
    (CONNECT_DATA= 
      (SERVICE_NAME=<standby database service>)
    ) 
    (SECURITY= (SECURITY=(ENCRYPTION_CLIENT=REJECTED))
  )
)

そのデータベースとの間の他のすべての接続は、sqlnet.oraパラメータ設定によって制御されます。このネット・サービス名を使用する接続のみ、Oracle Net暗号化が無効になります。

同期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からの出力を示しています。

表17-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)がその作業を終了してコミット・リクエストの作業を開始するまで待機しているセッションが増えます。つまり、アプリケーション同時実行性が増大しています。データベース統計および待機イベントを分析することで、アプリケーション同時実行性の増大を確認できます。

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

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

SYNC REDO率 ネットワーク待機時間 AWRからのTPS ログ・ファイル同期平均(ミリ秒) ログ・ファイル・パラレル書込み平均(ミリ秒) RFSランダム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)が有効化されています。

表17-3 Oracle AI 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ランダム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つに減らして高速のディスク・グループに配置すると、次の表に示すような結果が得られます。

表17-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ランダム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%