Oracle Data Guardデプロイメントの計画

14 Oracle Data Guardデプロイメントの計画

ITシステムおよびビジネス・プロセスの技術面と運用面の両方を含む特定の要件を分析し、Oracle Data Guardアーキテクチャ・オプションの可用性の影響を理解し、アプリケーションおよびネットワークの影響を考慮します。

Oracle Data Guardアーキテクチャ

Gold MAAリファレンス・アーキテクチャには4つのアーキテクチャ・パターンが用意されており、Oracle Active Data Guardを使用して単一点障害をなくすことができます。パターンは、ファスト・スタート・フェイルオーバーおよびHAオブザーバを使用する単一のリモート・アクティブ・スタンバイから、遠隔同期インスタンス、複数のスタンバイ、リーダー・ファームなどまで様々です。

Gold MAAリファレンス・アーキテクチャを計画する場合、高可用性リファレンス・アーキテクチャで各Goldアーキテクチャ・パターンの概要を参照し、要件に基づいて組み込む要素を選択します。

Oracle Data Guardデプロイメントのアプリケーションに関する考慮事項

Oracle Data Guardデプロイメントの計画の一環として、フェイルオーバーのシナリオで必要なリソースとアプリケーション可用性要件を考慮します。

サイト全体のフェイルオーバーかシームレス接続フェイルオーバーかの決定

最初のステップは、障害のためにプライマリ・データベースまたはプライマリ・サイトがアクセス不可か失われた場合に、ビジネス要件およびアプリケーション要件に最適なフェイルオーバー・オプションを評価することです。

次の表では、停止タイプごとの様々な条件を説明し、各シナリオでお薦めするフェイルオーバー・オプションを示します。

表14-1 様々な停止シナリオで推奨されるフェイルオーバー・オプション

停止タイプ	条件	推奨されるフェイルオーバー・オプション
プライマリ・サイト障害(すべてのアプリケーション・サーバーを含む)	障害が発生したプライマリ・データベースに接続されていた既存のすべてのアプリケーション・サーバー(または中間層サーバー)がプライマリ・サイトに含まれています。	サイト全体のフェイルオーバーが必要です
プライマリ・サイト障害(一部のアプリケーション・サーバーは引き続き稼働)	一部またはすべてのアプリケーション・サーバーに影響がなく、引き続き稼働しているアプリケーション・サーバーがセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースに再接続できます。アプリケーション・サーバーとセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースとの間のネットワーク待機時間が異なっても、アプリケーションのパフォーマンスとスループットを引き続き許容できます。通常、分析アプリケーションまたはレポート・アプリケーションでは、パフォーマンスへの顕著な影響なくクライアントとデータベースの間のより長いネットワーク待機時間を許容できますが、OLTPアプリケーションはアプリケーション・サーバーとデータベースの間のネットワーク待機時間が長くなると、パフォーマンスが大幅に低下する可能性があります。	停止時間を最小限に抑え、アプリケーションおよびデータベースの自動フェイルオーバーを可能にするために、シームレスな接続フェイルオーバーをお薦めします。
プライマリ・データベースまたはプライマリ・サーバー全体の障害	アプリケーション・サーバーは影響を受けず、ユーザーはセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースに再接続できます。アプリケーション・サーバーとセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースとの間のネットワーク待機時間が異なっても、アプリケーションのパフォーマンスとスループットを引き続き許容できます。通常、分析アプリケーションまたはレポート・アプリケーションでは、パフォーマンスへの顕著な影響なくクライアントとデータベースの間のより長いネットワーク待機時間を許容できますが、OLTPアプリケーションはアプリケーション・サーバーとデータベースの間のネットワーク待機時間が長くなると、パフォーマンスが大幅に低下する可能性があります。	パフォーマンスを許容できる場合は、停止時間を最小限に抑え、アプリケーションおよびデータベースの自動フェイルオーバーを可能にするために、シームレスな接続フェイルオーバーをお薦めします。それ以外の場合は、サイト全体のフェイルオーバーが必要です。

停止タイプ

条件

推奨されるフェイルオーバー・オプション

プライマリ・サイト障害(すべてのアプリケーション・サーバーを含む)

障害が発生したプライマリ・データベースに接続されていた既存のすべてのアプリケーション・サーバー(または中間層サーバー)がプライマリ・サイトに含まれています。

サイト全体のフェイルオーバーが必要です

プライマリ・サイト障害(一部のアプリケーション・サーバーは引き続き稼働)

一部またはすべてのアプリケーション・サーバーに影響がなく、引き続き稼働しているアプリケーション・サーバーがセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースに再接続できます。

アプリケーション・サーバーとセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースとの間のネットワーク待機時間が異なっても、アプリケーションのパフォーマンスとスループットを引き続き許容できます。

通常、分析アプリケーションまたはレポート・アプリケーションでは、パフォーマンスへの顕著な影響なくクライアントとデータベースの間のより長いネットワーク待機時間を許容できますが、OLTPアプリケーションはアプリケーション・サーバーとデータベースの間のネットワーク待機時間が長くなると、パフォーマンスが大幅に低下する可能性があります。

停止時間を最小限に抑え、アプリケーションおよびデータベースの自動フェイルオーバーを可能にするために、シームレスな接続フェイルオーバーをお薦めします。

プライマリ・データベースまたはプライマリ・サーバー全体の障害

アプリケーション・サーバーは影響を受けず、ユーザーはセカンダリ障害時リカバリ・サイトの新しいプライマリ・データベースに再接続できます。

パフォーマンスを許容できる場合は、停止時間を最小限に抑え、アプリケーションおよびデータベースの自動フェイルオーバーを可能にするために、シームレスな接続フェイルオーバーをお薦めします。

それ以外の場合は、サイト全体のフェイルオーバーが必要です。

サイト全体のフェイルオーバーのベスト・プラクティス

サイト全体のフェイルオーバーとは、サイト全体が新しい一連のアプリケーション層と新しいプライマリ・データベースを使用する別のサイトにフェイルオーバーすることです。

サイト全体で障害が発生すると、アプリケーション層とデータベース層の両方が使用できなくなります。可用性を維持するために、本番データベースの冗長アプリケーション層と同期コピーをホスティングするセカンダリ・サイトに、アプリケーション・ユーザーをリダイレクトする必要があります。

次の2つの図について考えてみます。最初の図は、フェイルオーバー前のネットワーク・ルートを示しています。クライアント・リクエストまたはアプリケーション・リクエストは、クライアント層のプライマリ・サイトに入り、プライマリ・サイトのアプリケーション・サーバー層およびデータベース・サーバー層にルーティングされます。

図14-1 サイト・フェイルオーバー前のネットワーク・ルート

「図14-1 サイト・フェイルオーバー前のネットワーク・ルート」の説明

次の2つ目の図は、サイト・フェイルオーバー完了後のネットワーク・ルートを示しています。クライアント・リクエストまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトと同じ経路をたどります。

図14-2 サイト・フェイルオーバー後のネットワーク・ルート

「図14-2 サイト・フェイルオーバー後のネットワーク・ルート」の説明

MAAベスト・プラクティスは、起動時間の発生を回避するためにスタンバイ・サイトで実行中のアプリケーション層をメンテナンスすること、およびOracle Data Guardを使用して本番データベースの同期コピーをメンテナンスすることです。サイト障害が発生すると、WANトラフィック・マネージャを使用してDNSフェイルオーバーが(手動または自動で)実行されて、すべてのユーザーがスタンバイ・サイトのアプリケーション層にリダイレクトされます。その間に、Data Guardフェイルオーバーによってスタンバイ・データベースがプライマリ本番ロールに遷移します。

Oracle Active Data Guardファスト・スタート・フェイルオーバーを使用して、データベース・フェイルオーバーを自動化します。アプリケーション・サーバーおよび非データベース・フェイルオーバーは、Oracle Site Guardを使用して自動化および調整できます。Oracle Site Guardは、セカンダリ・サイトでアプリケーション・サーバーを起動したり、Data Guardが自動的にフェイルオーバーする際に非データベース・メタデータを再同期するなどの操作を編成および自動化します。

Oracle Site Guardの詳細は、Oracle Site Guard管理者ガイドを参照してください。

シームレスな接続フェイルオーバーの構成

Oracle Data Guard構成でシームレスなクライアント・フェイルオーバーを自動化する作業には、Data Guardフェイルオーバーの一部として新しいプライマリ・データベースにデータベース・サービスを再配置することや、障害の発生をクライアントに通知してTCPタイムアウトを解消すること、新しいプライマリ・データベースにクライアントをリダイレクトすることなどが含まれます。

次の図では、データベース・リクエストが停止またはタイムアウトによって中断し(1)、そのためセッションがOracle RACクラスタに再接続され(2)(またはスタンバイに再接続され(2))、データベース・リクエストが代替ノードで自動的にリプレイされ(3)、データベース・リクエストの結果がユーザーに返されます(4)。

図14-3 シームレスな接続フェイルオーバー

「図14-3 シームレスな接続フェイルオーバー」の説明

シームレスな接続フェイルオーバーを実現するには、「アプリケーションの継続的な可用性の構成」を参照してください。

ネットワーク・パフォーマンスの評価および最適化

Oracle Data Guardは、基礎となるネットワークを利用して、プライマリ・データベースからスタンバイ・データベースにREDOを送信します。ネットワークが正常で、ピークREDO生成率をサポートできることを保証することで、将来の転送ラグを回避できます。

転送ラグは、プライマリ・データベースがプライマリ・インスタンスのREDO生成率よりも速くスタンバイにREDOを送信できない場合に発生します。プライマリ・データベース障害が発生した場合、転送ラグによってデータ損失が発生する可能性があります。

ネットワーク評価は、次の評価で構成されます。

ネットワークの信頼性
ピークREDO生成率に対応するネットワーク帯域幅

ノート:

プライマリ・データベース・インスタンスの各インスタンスは、独自のREDOを生成し、単一のネットワーク・ストリームでスタンバイ・データベースにREDOを送信します。したがって、REDO転送では、各ノードの単一プロセス・ネットワーク・スループットを最大にすることが重要です。

従来、ネットワークおよびREDO転送のスループットを削減できる領域があり、これによって転送ラグが生じる可能性があります。

ネットワーク・ファイアウォールまたはネットワーク暗号化

ネットワーク・ファイアウォールおよびネットワーク(Oracle Netではなく)暗号化により、全体的なスループットが大幅に低下する可能性があります。oratcpツール(後述)を使用して、暗号化の有無にかかわらずスループットを検証し、適宜チューニングします。

暗号化レベルを低くすると、スループットが大幅に向上することがあります。パフォーマンスとデータ損失の要件とともにセキュリティのニーズを満たすには、バランスが必要です。
REDO転送の圧縮

データベース初期化パラメータにLOG_ARCHIVE_DEST_N属性COMPRESSION=ENABLEがある場合、Oracleバックグラウンド・プロセスは、ネットワーク・メッセージを送信する前にREDOを圧縮し、REDOを処理する前にREDOを圧縮解除する必要があります。これにより、REDOおよびネットワーク・スループット全体が削減されます。圧縮は、プライマリ宛先とスタンバイ宛先の間でネットワーク帯域幅が不十分な場合にのみ推奨されます。
Oracle Net暗号化

REDOを含むOracle Netメッセージは送信前に暗号化し、その後、REDO処理の前に暗号化を解除する必要があるため、Oracle Netの暗号化レベルに応じて、REDOスループットの影響が異なります。

データベース暗号化が透過的データ暗号化(TDE)ですでに有効化されている場合、REDOはすでに暗号化されていますが、Oracle Net暗号化ではメッセージ・ヘッダーも暗号化できます。
REDO転送用のチューニングされていないネットワーク
- オペレーティング・システムのソケット・バッファの最大サイズを増やすと、単一のプロセス・スループットが2から8倍増加する可能性があります。異なるソケット・バッファ・サイズでテストして、どの値が正の結果をもたらすかを確認し、スループットがピークREDOスループットより大きいことを確認します。
- 様々なMTU設定とパフォーマンスを比較します。
  
  平均REDO書込みサイズが1500バイト未満の場合は、システム上でREDOを送信または受信するネットワーク・インタフェースのMTU=9000 (ジャンボ・フレームなど)などの様々なMTU設定を試みます。これにより、不要なネットワーク・ラウンドトリップが削減され、全体的なスループットが向上する可能性があります。
  
  また、SYNC転送の場合、Oracleの平均REDO書込みサイズ(Oracleメッセージの送信など)は、v$sysstatsまたはAWR統計のREDOサイズ/REDO書込みによって決定されるとおりに大幅に増加します。
  
  地理的なリージョン間でREDOを送信する場合、実験ではMTU=9000を使用すると、一部のネットワーク・トポロジでもメリットが得られることが示されています。oratcpでパフォーマンス・テストを実行し、結果をデフォルトのMTUおよびMTU=9000設定と比較します。

トポロジ情報の収集

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

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

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

対称的なハードウェアおよび構成を備えたスタンバイ・データベースで、ピークREDO生成率をサポートできるようにネットワーク構成が適切にチューニングされている場合、転送ラグは1秒未満となります。

Data Guardのネットワーク使用状況の理解

ネットワークを最も頻繁に使用するData Guardライフ・サイクルのフェーズは次のとおりです。

インスタンス化 - スタンバイ・データベース作成のこのフェーズでは、任意のホストからの並列処理を使用してファイルをコピーできます。ノード間のスループットを最大化する並列度を特定することは、スタンバイのインスタンス化プロセスを最適化するのに役立ちます。
REDO転送(安定した状態): 通常のData Guard操作では、プライマリ・データベースは適用対象のスタンバイにREDOを送信します。プライマリ・データベースの各RACインスタンスは、それが実行されているホストから単一のストリームでREDOを送信します。各プライマリ・データベース・インスタンスの要件を理解し、単一のプロセスでスループット要件を達成できるようにすることは、スタンバイ・データベースがプライマリ・データベースに遅れないようにするために重要です。

インスタンス化のターゲットおよび目標の理解

大規模なデータベースのインスタンス化には数時間、極端な場合は数日かかることがあります。インスタンス化の計画を可能にし、プライマリ・システムとスタンバイ・システム間のスループットを最大化してできるだけタイミングよくインスタンス化を完了するには、まずインスタンス化時間の目標を決定します。次に、次に定義するプロセスに従って、プロセスごとのスループットを最大化し、プライマリ・ノードとスタンバイ・ノード間の最適な並列度を特定します。

REDO転送のスループット要件および平均REDO書込みサイズの理解

特定のData Guard構成に必要なネットワーク帯域幅は、プライマリ・データベースのREDO生成率によって決まります。

ノート:

プライマリ・データベースがすでに存在する場合は、必要なネットワーク帯域幅のベースラインを確立できます。既存のプライマリ・データベースがない場合は、このステップおよび今後のプロセスでのデータへの言及を読み飛ばしてください。

自動ワークロード・リポジトリ(AWR)ツールを使用してREDO生成率を特定できますが、スナップショットは多くの場合、30分または60分間隔であり、最大速度が低下する可能性があります。最大速度は比較的短い期間で発生することが多いため、既存のデータベースでの実行時に各ログの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('2022/01/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
 AND TO_DATE('2022/01/15 11:00:00','YYYY/MM/DD HH24:MI:SS')
AND DEST_ID=1 ORDER BY FIRST_TIME;

出力例:

THREAD# SEQUENCE# MB         SEC        MB/s
------- --------- ---------- ---------- ----------
      2      2291 29366.1963        831  35.338383
      1      2565 29365.6553        781 37.6000708
      2      2292 29359.3403        537  54.672887
      1      2566 29407.8296        813 36.1719921
      2      2293 29389.7012        678 43.3476418
      2      2294 29325.2217       1236 23.7259075
      1      2567 11407.3379       2658 4.29169973
      2      2295 24682.4648        477 51.7452093
      2      2296 29359.4458        954 30.7751004
      2      2297 29311.3638        586 50.0193921
      1      2568 3867.44092       5510 .701894903

ノート:

ピークREDO率を見つけるには、最高レベルの処理(OLTPのピーク期間、四半期末バッチ処理、年末バッチ処理など)中の時間を選択します。

この短い例では、最高速度は約52MB/sでした。ネットワークは、このアプリケーションの最大速度に30%を上乗せするか68MB/sを加算したものをサポートするのが理想的です。

平均REDO書込みサイズの検証

v$sysstatsを使用するか、様々なワークロードおよびピーク間隔についてAWRレポートを参照して、次に基づいて平均REDO書込みサイズを記録します

REDO書込み平均サイズ= "REDO SIZE" / "REDO WRITES"

oratcpのテストでこの平均REDO書込みサイズを使用します。平均REDO書込みサイズが1500バイトを超える場合は、様々なMTU設定を試してください。

現在のネットワーク・スループットの理解

Oracleユーティリティoratcptestは、どのOSユーザーでも実行できるiperf/qperfのような、ネットワーク帯域幅および待機時間を測定するための汎用ツールです。

oratcptestユーティリティには、次のようなネットワーク・ロードを制御するためのオプションが用意されています。

ネットワーク・メッセージ・サイズ
メッセージ間の遅延時間
パラレル・ストリーム
oratcptestサーバーがディスクにメッセージを書き込むかどうか。
パケットの確認応答(ACK)を待機することによるData Guard SYNC転送のシミュレートまたはACKを待機しないことによるASYNC転送のシミュレート。

ノート:

このツールは、Oracleネットワーク・ストリーミング転送と同様に、Data Guard転送のようにソース・ホストからターゲット・ホストへの効率的なネットワーク・パケット転送をシミュレートできます。スループットは、ソース・サーバーとターゲット・サーバー間で使用可能なネットワーク帯域幅を飽和状態にする可能性があります。したがって、短期間のテストを実行し、同じネットワークを共有するその他の重要なアプリケーションについて検討することをお薦めします。

1つ以上のプロセスの既存のスループットの測定

既存のスループットを測定するには、次のタスクを実行します。

タスク1: oratcptestのインストール

MOSノート2064368.1からoratcptest.jarファイルをダウンロードします
JARファイルをクライアント(プライマリ)とサーバー(スタンバイ)の両方にコピーします

ノート:
oratcptestにはJRE 6以降が必要です
ホストにJRE 6以降があることを確認します
すべてのプライマリ・ホストおよびスタンバイ・ホストで、ヘルプを表示してJVMがJARファイルを実行できることを確認します
```
# java -jar oratcptest.jar -help
```

タスク2: 単一プロセスの既存のスループットの測定

Data Guardの非同期REDO転送(ASYNC)では、パケット確認応答を待機しないため、SYNC転送よりも高い速度を達成するストリーミング・プロトコルを使用します。

受信(スタンバイ)側でテスト・サーバーを起動します。

java -jar oratcptest.jar -server [IP of standby host or VIP in RAC
 configurations] -port=<any available port number>

テスト・クライアントを実行します。(ステップ4で起動したサーバーのものと一致するように、サーバー・アドレスおよびポート番号を変更します。)

$ java -jar oratcptest.jar [IP of standby host or VIP in RAC configurations]
 -port=<port number> -mode=async -duration=120 -interval=20s

[Requesting a test]
        Message payload        = 1 Mbyte
        Payload content type   = RANDOM
        Delay between messages = NO
        Number of connections  = 1
        Socket send buffer     = (system default)
        Transport mode         = ASYNC
        Disk write             = NO
        Statistics interval    = 20 seconds
        Test duration          = 2 minutes
        Test frequency         = NO
        Network Timeout        = NO
        (1 Mbyte = 1024x1024 bytes)

(17:54:44) The server is ready.
                    Throughput
(17:55:04)     20.919 Mbytes/s
(17:55:24)     12.883 Mbytes/s
(17:55:44)     10.457 Mbytes/s
(17:56:04)     10.408 Mbytes/s
(17:56:24)     12.423 Mbytes/s
(17:56:44)     13.701 Mbytes/s
(17:56:44) Test finished.
               Socket send buffer = 2 Mbytes
                  Avg. throughput = 13.466 Mbytes/s

この例では、これらの2つのノード間の平均スループットは約13 MB/sで、問合せからの68 MB/sの要件を満たしていませんでした。

ノート:

このプロセスは、帯域幅が1日の様々な時間で変化するかどうかを判断するために、-freqオプションを使用して特定の頻度で実行されるようにスケジュールできます。たとえば、-freq=1h/24hを設定すると、1時間ごとに24時間テストが繰り返されます。

タスク3: 複数プロセスの既存のスループットの測定

2つの接続を(num_connパラメータを使用して)指定し、前述のテストを繰り返します。

$ java -jar oratcptest.jar <target IP address> -port=<port number>
 -duration=60s -interval=10s -mode=async [-output=<results file>] -num_conn=2

[Requesting a test]
        Message payload        = 1 Mbyte
        Payload content type   = RANDOM
        Delay between messages = NO
        Number of connections  = 2
        Socket send buffer     = (system default)
        Transport mode         = ASYNC
        Disk write             = NO
        Statistics interval    = 20 seconds
        Test duration          = 2 minutes
        Test frequency         = NO
        Network Timeout        = NO
        (1 Mbyte = 1024x1024 bytes)

(18:08:02) The server is ready.
                    Throughput
(18:08:22)     44.894 Mbytes/s
(18:08:42)     23.949 Mbytes/s
(18:09:02)     25.206 Mbytes/s
(18:09:22)     23.051 Mbytes/s
(18:09:42)     24.978 Mbytes/s
(18:10:02)     22.647 Mbytes/s
(18:10:02) Test finished.
          Avg. socket send buffer = 2097152
        Avg. aggregate throughput = 27.454 Mbytes/s

ステップ1を繰り返し実行し、3つの連続する値で集計スループットが増加しなくなるまで、num_connの値を毎回2ずつ増やします。たとえば、集計スループットが10個、12個および14個の接続でほぼ同じである場合、終了します。

ノート:
RMANでは、クラスタ内のすべてのノードをインスタンス化に使用できます。合計集計スループットを検出するには、My Oracle Supportの『Creating a Physical Standby database using RMAN restore database from service』(ドキュメントID 2283978.1)を参照してください。
すべてのクラスタ内の全ノードで同じテストを実行して、現在の合計集計スループットを検出します。プライマリのノード1からスタンバイのノード1、ノード2からノード2のように、すべてのノードで検出されたスループットを合計します。
ロールを逆にして、テストを繰り返します。
最適な集計スループットを達成した接続の数をメモします。

データベースの合計サイズおよび合計集計スループットを使用して、データベースのコピーの完了にかかる時間を推定します。完全なインスタンス化では、コピー中に生成されたREDOを適用する必要もあります。データベースのアクティブ状態に基づいて、この推定時間に何パーセント(0%から50%)かさらに加算する必要があります。

見積り時間が目標を満たしている場合は、インスタンス化のための追加のチューニングは必要ありません。

1つ以上のプロセスによるREDO転送の最適化

前の単一プロセス・テストおよび複数プロセス・テストのスループットが目標を満たしている場合、追加のチューニングは必要ありません。より高いスループットが必要な場合、最大TCPソケット・バッファ・サイズをより大きい値に設定することが、スループットを増やす可能性がある主な方法です。

TCPソケット・バッファ・サイズの設定

TCPソケット・バッファは、受信データおよび送信データを一時的に格納するシステム・メモリー・バッファです。送信データは書込みバッファに格納されますが、受信データは読取りバッファに格納されます。読取りおよび書込みのソケット・バッファは別個に割り当てられます。バッファ(一般には読取りバッファ)が一杯になる(多くの場合、アプリケーションがバッファから十分な速さでデータを取得できない)と、データの送信が遅くなったり停止するために送信側にメッセージが送信されます。多くの場合、より大きなバッファを割り当てると、送信側を停止することなくワイヤからデータを取得する時間がアプリケーションに提供されるため、REDO転送が改善されます。

TCPソケット・バッファ・サイズのチューニングは、ASYNC転送を改善するための主な手法であり、場合によってはSYNC転送も改善できます。

ノート:

ソケット・バッファ・サイズが比較的大きい場合は、TCP選択的確認応答(SACK)をお薦めします。多くの場合、これはデフォルトで有効になっていますが、TCP選択的確認応答の確認または有効化の詳細は、オペレーティング・システムのドキュメントを参照してください。

TCPソケット・バッファ・サイズを設定するには、次のタスクを実行します。

タスク1: 最適な最大ソケット・バッファ・サイズの決定

一連のテストを実行して、ターゲット・ネットワーク・リンク上の単一プロセスについて、最適な最大ソケット・バッファ・サイズを見つけます。

ノート:

帯域幅遅延積は、チャネルのネットワーク・リンク容量とラウンド・タイム(待機時間)の積です。ソケット・バッファ・サイズの最小推奨値は、特に待機時間の長い高帯域幅ネットワークの場合、3*BDPです。oratcptestを使用してソケット・バッファ・サイズをチューニングします。

タスク2: 最大ソケット・バッファ・サイズの一時的な設定

プライマリ・システムとスタンバイ・システムで、次の各ステップに従ってリクエストの最大ソケット・バッファ・サイズを設定します。これはメモリー内で行われ、なんらかの理由でサーバーを再起動された場合は維持されません。

rootとして次の各ステップを実行します。

まず、カーネル・パラメータnet.ipv4.tcp_rmemおよびnet.ipv4.tcp_wmemの現在のサイズを見つけます。返される値は、TCPが動的に割り当てるソケット・バッファの最小、デフォルトおよび最大のサイズです。ソケットの作成時に指定されたデフォルトよりも大きい値がプロセスで必要な場合、さらにバッファが最大値まで動的に割り当てられます。
```
# cat /proc/sys/net/ipv4/tcp_rmem
4096    87380   6291456

# cat /proc/sys/net/ipv4/tcp_wmem
4096    16384   4194304
```

値を16MBまたは3*BDPの計算結果に変更します

# sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216';

# sysctl -w net.ipv4.tcp_wmem='4096 16384 16777216';

ノート:

これらの値を増やすと、システムでのネットワーク・ソケットのシステム・メモリー使用量が増加する可能性があります。

ノート:

sysctlを使用して行われた変更は永続的ではありません。マシンの再起動後もこれらの変更を保持するために、/etc/sysctl.confファイルを更新します。適切な設定が決定されると、このプロセスの最後に構成ファイルを変更するステップがあります。

タスク3: 単一プロセスのスループットのテスト

前のテストを再実行して、前のステップで設定した新しい最大値までソケット・バッファが動的に増加できるようにします。

(oracleとして)

サーバー(スタンバイ):

$ java -jar oratcptest.jar -server [IP of standby host or VIP in RAC configurations]
 -port=<port number>

クライアント(プライマリ):

$ java -jar oratcptest.jar <IP of standby host or VIP in RAC configurations>
 -port=<port number> -mode=async -duration=120s -interval=20s

ノート:

ソケット・バッファ・サイズの明示的なリクエストを制御するカーネル・パラメータは、このテストに設定されたものと異なるため、oratcptest sockbufパラメータを使用しないでください。

テストが完了すると、クライアントおよびサーバーからの結果に、そのテスト中のソケット・バッファの値が表示されます。このドキュメントの執筆時点では、その値は実際のソケット・バッファ・サイズの半分であり、使用された実際のサイズを検出するには2倍にする必要があります。

クライアント

[Requesting a test]
        Message payload = 1 Mbyte 
        Payload content type = RANDOM 
        Delay between messages = NO 
        Number of connections = 1 
        Socket send buffer = 2 Mbytes 
        Transport mode = ASYNC
        Disk write = NO
        Statistics interval = 20 seconds 
        Test duration = 2 minutes
        Test frequency = NO 
        Network Timeout = NO
        (1 Mbyte = 1024x1024 bytes) 
(11:39:16) The server is ready.
                Throughput 
(11:39:36) 71.322 Mbytes/s
(11:39:56) 71.376 Mbytes/s
(11:40:16) 72.104 Mbytes/s
(11:40:36) 79.332 Mbytes/s
(11:40:56) 76.426 Mbytes/s
(11:41:16) 68.713 Mbytes/s
(11:41:16) Test finished.

          Socket send buffer = 8388608  
            Avg. throughput = 73.209 Mbytes/s

サーバー

The test terminated. The socket receive buffer was 8 Mbytes.

ノート:

oratcptestのレポートでは、ソケットに割り当てられたバッファの半分になっています。テスト中に使用された実際のソケット・バッファ・サイズについてレポートされた数値を2倍にします。

タスク4: 複数プロセスのスループットのテスト

num_conn=10に設定された10個のプロセスで、ピーク集計スループットに到達した場合など、最初のテストで決定されたnum_conn値を使用してテストを繰り返します。

クライアント

$ java -jar oratcptest.jar <IP of standby host or VIP in RAC configurations>
 -port=<port number> -mode=async -duration=120s -interval=20s -num_conn=10

[Requesting a test]
        Message payload        = 1 Mbyte
        Payload content type   = RANDOM
        Delay between messages = NO
        Number of connections  = 10
        Socket send buffer     = (system default)
        Transport mode         = ASYNC
        Disk write             = NO
        Statistics interval    = 20 seconds
        Test duration          = 2 minutes
        Test frequency         = NO
        Network Timeout        = NO
        (1 Mbyte = 1024x1024 bytes)

(19:01:38) The server is ready.
                    Throughput
(19:01:58)    266.077 Mbytes/s
(19:02:18)    242.035 Mbytes/s
(19:02:38)    179.574 Mbytes/s
(19:02:58)    189.578 Mbytes/s
(19:03:18)    218.856 Mbytes/s
(19:03:38)    209.130 Mbytes/s
(19:03:38) Test finished.
          Avg. socket send buffer = 8 Mbytes 
        Avg. aggregate throughput = 217.537 Mbytes/s

ノート:

サーバー(各接続で受信バッファが出力されます。各インスタンスのソケット・バッファ・サイズを2倍にします)

The test terminated. The socket receive buffer was 8 Mbytes. 

The test terminated. The socket receive buffer was 8 Mbytes. 
 
The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.
 
The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.

The test terminated. The socket receive buffer was 8 Mbytes.

タスク5: テストの繰返し

スループットがさらに必要な場合は、tcp_rmemおよびtcp_wmemの値を大きくして前の2つのテストを繰り返します。これらの大きくした値は、他のソケットにも使用できますが、必要な場合にのみ動的に割り当てられることを理解してください。この表は、ソケット・バッファ・サイズごとに異なるスループットの結果を追跡するサンプル・データを示しています。

tcp_rmemの最大値	tcp_wmemの最大値	単一プロセスのスループット	単一ノードのマルチプロセスの最大集計スループット	単一ノードのマルチプロセスの並列度
6291456	4194304	13.5 MB/s	203 MB/s	16
8388608	8388608	48 MB/s	523 MB/s	14
16777216	16777216	73 MB/s	700 MB/s	14
33554432	33554432	132 MB/s	823 MB/s	14

タスク6: パラメータの永続的な設定

sysctlを使用した変更により、ホストの再起動後には保持されないメモリー内の値が変更されます。ソケット・バッファの最適なサイズが決定されたら、/etc/sysctl.confファイルを編集してサーバーの再起動後も保持されるようにカーネル・パラメータを設定します。

これは、プライマリ・システムおよびスタンバイ・システムのすべてのノードで実行する必要があります。

これらの変更を永続的にするには、既存の値を変更するか、存在しない場合はこれらの値をファイルに追加して/etc/sysctl.confを編集します。

net.ipv4.tcp_rmem='4096 87380 16777216'

net.ipv4.tcp_wmem='4096 16384 16777216'

タスク7: 大きいMTUの評価

Data Guardト転送で使用されるネットワーク・インタフェースを決定します。

平均REDO書込みサイズが現在のMTU設定(通常はデフォルトの1500など)より大きい場合、ジャンボ・フレーム(MTU=9000など)によってこれらの大規模なネットワーク・パケットのネットワークRTTが削減され、REDOスループット全体が向上するかどうかを評価します。

Linuxでテスト目的でData Guard転送ネットワーク・インタフェースのMTUを変更する例を次に示します。

ifconfig bondeth0 mtu 9000 up

前述したように、MTUサイズを大きくして同じoratcpパフォーマンス手法を繰り返し、スループットが向上したかどうかを確認します。

パフォーマンスが向上した場合は、システムおよびネットワーク・エンジニアと協力して、プライマリ・データベースとスタンバイ・データベースの両方のDG転送のMTUサイズを変更します。

このデータの使用方法

スループットの数値を使用してスループットを決定し、REDO転送およびインスタンス化の状況に役立てることができます。

REDO転送

単一プロセスのスループットがプライマリ・データベースの単一インスタンスのREDO生成率を超えない場合、スタンバイは、この間、プライマリに遅れをとるようになります。このような場合、ネットワーク・エンジニアリング・チームによるさらなる評価およびネットワーク・チューニングが必要になることがあります。

インスタンス化

すべてのノードの最大集計スループットが認識されると、インスタンス化の大まかな見積りを策定できます。たとえば、インスタンス化する2ノードRACに100 TBのデータベースがあり、各ノードが300 MB/秒を達成できる場合、データ・ファイルのコピーには約50時間かかります。インスタンス化するための追加作業で、その数値に何パーセントか(30%まで)加算されます。

300 MB/s * 60 seconds/minute * 60 minutes/hour * 2 nodes = ~2 TB/hr aggregate for both nodes
100TB / 2TB/hr = ~50 hours

複数のノードを使用するなど、大規模なデータベースの最適化を使用してデータベースをインスタンス化するステップについては、『Creating a Physical Standby database using RMAN restore database from service』(ドキュメントID 2283978.1)を参照してください。

Oracle Data Guard保護モードの決定

Oracle Data Guardは3つの異なる保護モードで実行でき、モードごとに対応するパフォーマンス、可用性およびデータ損失の要件が異なります。このガイドを使用して、ビジネス要件に適合する保護モードおよび潜在的な環境制約を決定します。

最大保護モード: このモードでは、プライマリ・データベースの障害発生時に、それが複数の障害(たとえば、プライマリとスタンバイ間のネットワークに障害が発生し、しばらくしてからプライマリに障害が発生する場合)であっても、データの損失がないことが保証されます。このポリシーを実施するため、REDOがディスクに固定されたことを少なくとも1つのData Guardスタンバイが確認応答するまで、プライマリ・データベース・トランザクションのコミット成功は伝達されません。このような確認応答がない場合、プライマリ・データベースでは保護されていないトランザクションのコミットは不可能で、データベースは一時停止して最終的にはシャットダウンします。

プライマリ・データベースは操作可能でスタンバイ・データベースは操作不可能な場合に可用性を保つためのベスト・プラクティスは、最大保護構成で同期化されたスタンバイ・データベースを常に2つ以上保持することです。プライマリ・データベースの可用性は、少なくとも1つの同期化されたスタンバイ・データベースから確認応答を受け取っていれば、影響されません。

データ損失ゼロがデータベース可用性よりも重要な場合には、この保護モードを選択します。SYNC転送を有効にするときに、オーバーヘッドを許容できるかどうかを測定するには、ワークロードの影響分析をお薦めします。

最大可用性モード: このモードでは、プライマリ・データベースで構成に影響を与える最初の障害が発生した場合に、データ損失は起こらないことが保証されます。最大保護モードとは異なり、最大可用性モードはいずれかのスタンバイ・データベースからの確認応答に対してNET_TIMEOUTの最大秒数を待機します。その後、コミット成功をアプリケーションに伝達して、次のトランザクションに移動します。プライマリ・データベースの可用性(つまりモードの名前と同じ)は、スタンバイとの通信ができない場合(たとえば、スタンバイまたはネットワークの停止が原因の場合)でも、影響を受けません。Data Guardは引き続きスタンバイにpingを送信し、可能になったら自動的に接続を再確立して、スタンバイ・データベースを再同期化します。ただし、プライマリとスタンバイが分岐した期間中にデータ損失が発生し、これはプライマリ・データベースに影響を与える二次障害になります。

このような理由から、保護レベルを監視(Enterprise Manager Grid Controlの使用が最も簡単)して、プライマリとスタンバイの間の通信の遮断は、二次障害が発生する前に迅速に解決することがベスト・プラクティスとなります。これは、最も一般的なデータ損失ゼロのデータベース保護モードです。

データ損失ゼロは非常に重要であるものの、すべてのスタンバイ・データベースにアクセスできなくなるという可能性の低い事態でも引き続きプライマリ・データベースを使用可能にする場合には、この保護モードを選択します。このソリューションを補完するには、複数のスタンバイ・データベースを統合するか、遠隔同期インスタンスを使用してWAN全体でデータ損失ゼロのスタンバイ・ソリューションを実装します。SYNC転送を有効にするときに、オーバーヘッドを許容できるかどうかを測定するには、ワークロードの影響分析をお薦めします。

最大パフォーマンス・モードは、デフォルトのData Guardモードで、プライマリ・データベースのパフォーマンスまたは可用性に影響を与えない範囲で最高レベルのデータ保護を提供します。このモードでは、トランザクションのリカバリに必要なREDOデータがプライマリ・データベースにあるローカルのオンラインREDOログに書き込まれると、即座にそのトランザクションのコミットが許可されます(スタンバイ・データベースが存在しなかった場合と同じ動作)。Data Guardは、REDOを1)プライマリ・ログ・バッファからスタンバイ・データベースに直接送信するとともに、2)ローカル・オンラインREDOログ書込みに非同期で送信することで、プライマリ・サイトが失われた場合のデータ損失の可能性を非常に低く抑えます。スタンバイ確認応答の待機は発生しませんが、それでも、このデータ保護モードではデータ損失の可能性をゼロに近くすることができます。

最大可用性モードと同様に、Enterprise Manager Grid Controlで保護レベルを監視して、二次障害が発生する前にプライマリとスタンバイの間の通信の遮断を迅速に解決することがベスト・プラクティスです。

最小データ損失を許容でき、プライマリに対するパフォーマンスへの影響がゼロの場合には、このモードを選択します。

読取り専用スタンバイ・データベースへの問合せのオフロード

問合せおよびレポートのワークロードを読取り専用スタンバイ・データベースにオフロードすると、プライマリ・データベースのシステム・リソースが解放され、ユーザー、ワークロードさらにはデータベースまで追加できるようになります。

プライマリ・データベースとスタンバイ・データベースの両方のリソースを利用すると、業務およびアプリケーションでの合計システム使用率が高くなり、アプリケーションのスループットが向上する可能性もあります。

次のステップに従って、適切なワークロードをオフロードします。

読取り専用または読取り多用のアプリケーション・モジュールを特定します。
- 読取り専用のアプリケーション・サービスまたはモジュールがあるかどうかを評価します。
- 小規模で短い読取り専用の問合せは、スタンバイ・データベースへのオフロードの候補として適しています。
- 短いDML、特にレスポンス時間に依存するDMLは、スタンバイにオフロードしないでください。
- 大規模なレポートまたは分析レポートは、オフロードの候補として適しています。
- 主に読み取られるレポートや、低頻度のDMLが(通常はレポートの先頭または末尾)に含まれることがあるレポートは、オフロードの候補として適している場合があります。
  
  DMLリダイレクトを有効にするには、ADG_REDIRECT_DMLを参照してください。
オフロードの候補ごとに、予想されるアプリケーション・パフォーマンス、スループット、レスポンス時間または経過時間のサービス・レベルに関する情報を収集します。
- オフロードに適した候補となる問合せおよびレポートを決定したら、それぞれに必要な予想および最大のレスポンス時間または経過時間を求めます。たとえば、大規模な分析レポートの中には、2時間以内に完了する必要があるものがあります。
- 短い問合せの場合は、予想されるレスポンス時間とスループットの見込みを割り出します。
- これらの要件は、次のステップで必要になるアプリケーション・パフォーマンスに関するサービス・レベル契約と呼ばれることもあります。
スタンバイ上の各候補のパフォーマンスをテストし、要件を満たしているかどうかを判断します。
- プライマリ・データベースとスタンバイ・データベースのデータは基本的に同じですが、独立したデータベース、独立したマシン、独立した構成であり、ワークロードが異なります。たとえば、Active Data Guardの読取り専用スタンバイ・データベースには、REDO適用のワークロードとオフロードされる問合せがありますが、プライマリ・データベースにはOLTP、バッチおよび問合せのワークロードがある場合があります。
- レポートされる経過時間、問合せレスポンス時間およびワークロード・パフォーマンスは、これらのシステム、構成およびワークロードの違いにより、プライマリとスタンバイで異なる場合があります。
- チューニングでは、システム・リソース、SQL計画および個々の問合せのCPUと待機プロファイルを理解する必要があります。チューニングに関する推奨事項は、プライマリ・データベースとスタンバイ・データベースの両方に適用できます。データベース・パフォーマンスの診断およびチューニングを参照してください。
パフォーマンス要件を満たす問合せのサブセットをオフロードし、処理能力を高めるためにプライマリ・データベースのリソースを解放します。
- オフロードできる問合せおよびレポートを決定し、それらのアクティビティのパフォーマンスが許容できるようになったら、ワークロードの一部を徐々にオフロードして監視します。
- チューニング後にREDO適用の速度を維持できなくなるほど、過剰なワークロードをスタンバイにオーバーサブスクライブおよびオフロードしないでください。スタンバイが遅れを取ると、実行可能なロール・トランジション・ターゲットとしてのそのスタンバイは失われ、ほとんどの場合、遅れているスタンバイは問合せのオフロードに使用できません。

特定の問合せが要件を満たしていない場合はどうなりますか。

パフォーマンス・エンジニアに相談し、Databaseパフォーマンス・チューニング・ガイドの推奨事項に従ってください。
特定の問合せのレスポンス時間、スループットまたはレポート経過時間は、スタンバイ・システムとプライマリとで同じである保証はありません。システム・リソース、SQL計画、全体的なCPU作業時間および待機時間を分析します。

たとえば、短い問合せのいずれかで、standby query scn advance waitがずっと長い経過時間の原因となっていることがわかります。この待機の増加は、Active Data GuardのREDO適用に起因します。問合せでデータ・ブロック内の特定の行が検出され、問合せのシステム・コミット番号(SCN)の時点でトランザクションがコミットされていないためロールバックする必要がある場合は、対応するUNDOを適用して、その問合せの読取り一貫性を取得する必要があります。対応するUNDO変更のREDOがREDO適用によってまだ適用されていない場合、問合せは待機する必要があります。このような待機の存在自体は問題ではなく、通常は数ミリ秒かかることがありますが、ワークロードによって異なり、Real Application Clusterデータベース・システムでの方が大きくなる可能性があります。