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です。

表17-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適用パフォーマンスに最も影響を及ぼします

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

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

  • 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の増加が示されます。

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

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

列 説明 チューニングに関する推奨事項
Logfile sequential read

パラレル・リカバリ・コーディネータは、オンライン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を増やします

これらのパラメータでは共有プールにある次と等量の領域が使用されることに注意してください。

(_mira_num_local_buffers * 2) + (_mira_num_receive_buffers * インスタンス数-1)

(スタンバイ・データベースのインスタンスごと)。

たとえば、2ノードのRACスタンバイ・データベースで、_mira_num_local_buffers = 100および_mira_num_receive_buffers = 100の場合、これらのパラメータで使用される合計SGA領域は、SGAの(100*2)+(100*1)=300MBです。

ノート:

_mira_num_local_buffersおよび_mira_num_receive_buffersのデフォルトは25です。

スタンバイ・データベースでの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_well_tuned.pngの説明sira_poorly_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システムには、次の表に示すように、プライマリ・データベースで追加のステップが必要です。

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

    Exadataシステム データベースのリリース ステップ
    永続メモリー(XRMEM)のあるExadataストレージ・セル 19.13以降

    追加ステップはありません
    XRMEMなし 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のためにバッファ・サイズを増やすことをお薦めします。

    これらのパラメータは、インスタンス間でブロックを渡すための追加のバッファ領域を提供します。

    • "_mira_local_buffers"=100 (デフォルトは25)

    • "_mira_num_receive_buffers"=100 (デフォルトは25)

    • "_mira_rcv_max_buffers"=10000 (デフォルトは500) - SGAの使用量は増やさずに、単に上限を設定します。

    これらの値にすると、MIRAのSGA使用量が増えます。これらの新しい設定のために使用できるSGAメモリーが十分にあることを確認してください。

    関連するMIRA Oracle RACインスタンスごとの追加メモリー要件(MB) = ((_mira_local_buffers*2)+(_mira_num_receive_buffers*[インスタンスの数-1])) MB

    たとえば、4ノードのOracle RACシステムでは、_mira_num_local_buffers=100および_mira_num_receive_buffers=100の場合は、SGAから(100*2)+(100*3)=500MBになります。

    ノート:

    これらのパラメータを有効にするには、スタンバイ・データベースを再起動する必要があります(RACローリング再起動が可能です)。

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

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

      ‘ApplyInstances’=<#|ALL>

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

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

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

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

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

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

    "recovery apply pending"または"recovery receive buffer free"が待機イベントの上位にある場合は、_mira_num_receive_buffersおよび_mira_num_local_buffersを増分的に100ずつ増やしてこの待機イベントを減らします。

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

  6. バッファの適切な値の特定は、反復プロセスで実行できます。

    適用率およびスタンバイAWRのレポートを、典型的な通常ワークロードの期間(ワークロードのピーク期間を含む)にわたり監視します。"recovery apply pending"または"recovery receive buffer free" (あるいはその両方)がまだ待機の上位であり、待機のかなりの割合を占めている場合は、バッファ・パラメータをさらに増やし、繰り返します。

非常に大きい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容量が飽和状態の場合、この変更はオプションです

プライマリ・データベースまたはスタンバイ・データベースで、書込み欠落が早期に検出されません