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

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

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

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

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

システム・リソースがボトルネックではなく、スタンバイ・システムがプライマリと対称であり、適用ラグがほぼゼロであると仮定すると、Oracle 19c以前のデータベース・リリースの場合にData Guardロール・トランジションのタイミングが増える最大の要因は、次のことです:

プラガブル・データベース(PDB)の数(たとえば、PDBが25個を超えている)
Oracle Clusterwareマネージド・サービスの数(たとえば、Oracleサービスが200個を超えている)
データファイルの数(Oracleデータファイルが500個を超えている)

前述のどれかがしきい値を超えている場合は、Data Guardスイッチオーバーまたはフェイルオーバーのタイミングが数分増える可能性があります。たとえば、5000個以上のデータファイルがあるデータベースの場合は、ロール・トランジションのタイミングが5分以上増える可能性があります。500個のOracleサービスがあるデータベースの場合は、ロール・トランジションのタイミングが1分以上増える可能性があります。50個以上のPDBがあるデータベースの場合は、ロール・トランジションのタイミングが1分以上増える可能性があります。

データファイルの数は大きな要因であるため、MAAでは、表領域とパーティションの作成時に大きなデータファイル・サイズまたはビッグファイルを使用することをお薦めしています。スタンバイ・データベースによって保護されているデータベースが重要である場合、MAAでは、それらをそれ固有の別個のコンテナ・データベース(CDB)に隔離するか、PDBの数を最小限に抑えることをお薦めしています。

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

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

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

計画メンテナンス期間の前に、バッチ・ジョブまたは実行時間が長いレポートを回避または遅延します。ピーク処理期間も回避する必要があります。
Data Guardスイッチオーバーは正常であり、ソース・プライマリ・データベースの停止が必要であるため、すべてのアプリケーション排出タイムアウトを考慮します。Oracle Clusterwareサービスの排出属性および設定については、「アプリケーションの継続的なサービスの有効化」を参照してください。
単一インスタンス(非RAC)でのData Guardスイッチオーバー操作は、30秒未満にできます。
Real Application ClusterでのData Guardスイッチオーバー操作は異なりますが、30秒から7分にすることができます。より多くのPDB (25を超えるPDBなど)がある場合、より多くのアプリケーション・サービス(200サービスなど)がある場合、およびデータベースに多数のデータ・ファイル(1000個のデータ・ファイルなど)がある場合、期間は長くなることがあります。

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

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

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

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

「チューニングされたMAA構成」のタイミングは、次のMAA推奨プラクティスを実装することで達成されました:

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

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

「図17-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構成」のタイミングは、次のMAA推奨プラクティスを実装することで達成されました:

Data Guardのファスト・スタート・フェイルオーバーを評価し、異なるFastStartFailoverThreshold設定でテストします
ビッグファイル表領域の使用
Oracle Data Guardの構成ベスト・プラクティス
ロール・トランジション、アセスメントおよびチューニング

カスタマの事例

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

プライマリおよびData Guardの構成	観測されたRTO
Database Cloud (DBCS)で大量のOLTPワークロードを使用する単一インスタンス・データベースのフェイルオーバー。Data Guardのしきい値は5秒です。	20秒
大きなCDB内にPDB 1つのみと、クラスタウェア・マネージド・サービス25個未満からなる、重いOLTPワークロードがある4ノードOracle 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分未満

Oracle AI Database 26aiでのData Guardロール・トランジションの最適化

Oracle AI Database 26aiでは、Data Guardロール・トランジションのタイミングが400%速くなる可能性があります。これは、様々な領域(PDBとCDBのオープン操作とクローズ操作、リカバリ、およびデータベース・チェックポイントとクラスタウェア・サービスの管理など)で、Oracle AI Database 26aiの最適化が多数行われているためです。次の例では、ロール・トランジションが30秒未満であることが示されています。Oracle AI Database 26aiにアップグレードした後のData Guardロール・トランジションのタイミングがOracle Database 19cに比べて速いことがわかります。

Oracle AI Database 26aiでのData Guardロール・トランジションのタイミングが30秒を超える場合があります。その主な要因2つを次に示します

データファイルの数(たとえば、2000個を超えるデータファイル)と、必要な未処理メディア・リカバリの量。これは、重要で最も影響のある変数です。たとえば、データファイル5000個と重いワークロードがあるCDB上のデータベースの場合は、適用対象の未処理REDOが生じて、RTOが60秒を超えることがあり、数分を超えることもあります。
PDBとクラスタウェア・マネージド・サービスの数。多数のPDB (25個を超えるPDB)や数百個のクラスタウェア・マネージド・サービスがある場合は、RTOのタイミングの増加に気付くことがあります。

Oracle AI DatabaseおよびOracle AI Database 26aiでは、Data Guardのスイッチオーバーおよびフェイルオーバーのタイミングが大幅に短縮されます。

dg-faster-transitions-intwentythreeai.pngの説明が続きます

図dg-faster-transitions-intwentythreeai.pngの説明

測定された内容

Oracle MAAでは、アラート・ログ内で示されている、DGMGRLでSWITCHOVERフェーズまたはFAILOVERフェーズに入ってからサービスを開始するまでの時間差が測定されました。

そのために、次の表に示す、3つの異なる構成が使用されました。

構成	システム	PDB	データ・ファイル	サービス	REDO率
小規模	2ノードのExadata RAC	5	50	10	60 MB/秒
中規模	4ノードのExadata RAC	12	500	12	100 MB/秒
大規模	4ノードのExadata RAC	100	10'000	1200	100 MB/秒

REDO適用パフォーマンス

単一インスタンスREDO適用(SIRA)はデフォルトのREDO適用モードであり、ほとんどの場合、これで十分です。マルチインスタンスREDO適用(MIRA)を検討する前に、SIRAのチューニングとそのボトルネックの理解に注力してください。「REDO適用のトラブルシューティングおよびチューニング」を参照してください。

システム・リソースの競合(ストレージ帯域幅の制限や、読取り/書込みI/Oが原因のチューニングされていないデータベース待機イベント、またはチェックポイント待機イベントなど)がないことを前提とすると、マルチインスタンスREDO適用(MIRA)では、MIRA構成内の追加Oracle RACインスタンスをそれぞれ30から80%スケーリングすることでREDO適用パフォーマンスを改善できます。

プライマリのワークロードのタイプ、スタンバイの追加の読取り専用ワークロード、新しい上位スタンバイ待機イベントなど、改善率に影響を及ぼす様々な要因があります。

図17-3 Swingbench OLTPワークロードの適用率の例

「図17-3 Swingbench OLTPワークロードの適用率の例」の説明

図17-4 バッチ挿入ワークロードの適用率の例

「図17-4 バッチ挿入ワークロードの適用率の例」の説明

大規模なREDOギャップのについては、非常に大きいREDO適用ギャップの対処で説明している方法を実装することで、ギャップにすばやく追い付くことができます。

非常にまれなケースですが、適用パフォーマンスがより重要である場合は、一部のMAAデータ保護設定を一時的に無効にできます。「データ保護を犠牲にしたREDO適用率の改善」を参照してください。

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

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

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

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

図17-5 MTU=9000によるアプリケーションへの影響

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

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

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

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

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

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

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

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

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

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

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

最初にData Guardを使用せずにアプリケーションをチューニングします。ASYNC転送についても同様のパフォーマンスが確認されます
「Oracle Data Guardの構成ベスト・プラクティス」を実装します
「REDO転送のトラブルシューティングおよびチューニング」の方法の使用
SYNCを使用してネットワークをチューニングし、アプリケーションのパフォーマンスを向上させます。「ネットワーク・パフォーマンスの評価および最適化」を参照してください
SYNC転送のスループットの向上に役立つアプリケーション・ワークロード固有の変更は次のとおりです。
- 同時実行性またはユーザーの追加を評価して、スループットを向上させます。
- データ損失ゼロを必要としない特定のセッション内の重要でないワークロードの場合は、拡張COMMIT_WRITE属性をNOWAITに評価します。
  
  この場合、確認応答を受信する前にコミットできます。REDOは永続REDOログに送信されますが、非同期で実行されます。リカバリは、適用されるREDO内のすべての永続コミット済トランザクションに対して保証されます。Oracle AI DatabaseリファレンスのCOMMIT_WRITEを参照してください。