※本ページは、”Sizing Database SGA for Migration to Exadata“の翻訳です。

Exadata以外のシステムは、Exadataと比較してI/O特性が大きく異なります。これらのシステムにおけるI/Oパフォーマンスチューニングの主なアプローチは、単純にSGA（System Global Area）のサイズを増やすことです。Exadataは、従来システムには存在しない低レイテンシ、高スループット、Storage Offload機能など、はるかに優れたI/Oパフォーマンスを提供します。従来システムからExadataへデータベースを移行する際には、System Global Areaを適切なサイズに見直す機会がありますが、移行作業を迅速化するためにこの作業が省略されることも少なくありません。Exadataへの移行時には、可能な限り変更を最小限に抑えることを前提としていますが、移行後にデータベースを最適化することも可能です。

この記事では、従来システムにおけるSGAメモリのサイジングを評価し、Exadataへの移行時にパフォーマンスチューニングを行わずにSGAを安全に縮小できるかどうか、またどの程度縮小できるかを判断する方法について説明します。

Average Active Sessions（平均アクティブ・セッション）

待機クラス別の平均アクティブ・セッション（Average Active Sessions）を確認することで、データベース全体で何が起きているのか、またどこに時間が費やされているのかを把握できます。一般的には、データベースの処理時間はCPUまたはI/Oに費やされていることが多いですが、一部のデータベースでは、同時実行制御（Concurrency）やアプリケーション起因の問題など、他の要因に時間が費やされている場合もあります。以下のグラフでは、データベースの処理時間の51%がCPU、22%がI/Oに費やされていることを示しています。行ロック（Row Locking）の問題も見られますが、これはアプリケーションの変更なしには解決できず、単にプラットフォームを変更しただけでは改善できません。

I/Oレイテンシの評価

Exadata以外のシステムでは、READ処理に関する重要な待機イベントが2つ、WRITE処理に関する重要な待機イベントが2つあります。READ系の待機イベントでは、エンドユーザーやアプリケーションが実際に待機しているため、常に重要な指標として扱われます。

一方、Oracleデータベースの書き込み処理の大部分はバックグラウンドで実行されるため、通常はエンドユーザーやアプリケーションが待機することはありません。ただし、以下に示すコミット関連の待機イベントは例外です。

READ

  • db file sequential read
  • db file scattered read

WRITE

  • log file parallel write
  • log file sync

これらの待機イベントは、Oracle Enterprise ManagerやOracle AWR（Automatic Workload Repository）レポートなど、さまざまなOracleパフォーマンス分析ツールで容易に確認できます。

以下のグラフは、基盤となるAWR履歴ビュー（AWR History Views）を問い合わせて作成したものです。

このヒストグラムから、既存システムのI/Oレイテンシは、このデータベースをExadataへ移行した後に得られる性能と比べて、決して高速ではないことが分かります。「db file sequential read」イベントの70%は1,000マイクロ秒（µsec）以内で発生しています。また、「log file sync」イベントの大部分（53%）は4,000マイクロ秒を要しています。

これらの重要なI/O待機イベントは、Exadata上では大幅に高速化されるため、SGAサイズを削減する余地があると考えられます。

なお、上記のグラフはミリ秒単位で表示されていますが、Exadataでは現在、一般的にマイクロ秒単位で性能を議論します。1ミリ秒は1,000マイクロ秒であり、Exadata上でデータベースを稼働させる世界は、従来システムとはまったく異なると言えます。

マルチブロック・スキャンとシングルブロックI/O

私たちはよく「トランザクション処理（Transaction Processing）」データベースと「分析（Analytic）」データベースについて語りますが、実際にはほぼすべてのデータベースがこれらのワークロードの混在です。トランザクション処理型データベースでは主にシングルブロックI/Oが発生し、一方で分析型データベースでは主にマルチブロックI/O、すなわちスキャンI/Oが発生します。

以下は、このような挙動を示す非常に良い例です。このデータベースでは、シングルブロックI/O（db file sequential read）とマルチブロックI/O（db file scattered read）の両方が発生していることが分かります。しかし、各グラフの左側に示されているスケールに注目してください。

上側のグラフはマルチブロックI/O（db file scattered read）を示しており、スケールの上限は1,200万（12M）です。一方、下側のグラフは1億（100M）まで達しています。このデータベースでは、スキャン（マルチブロックI/O）よりもシングルブロックI/Oを約8倍多く実行しているため、分析処理よりもトランザクション処理の性質が強いことが分かります。先ほどのヒストグラムを振り返ると、これらのマルチブロックI/Oイベントのレイテンシは4,000マイクロ秒以上に達していることが分かります。また、ここで示されている値はAWRスナップショットの取得間隔中に発生したイベント数であり、1秒あたりのイベント数を表しているわけではない点にも注意が必要です。このデータベースは60分間隔でAWRスナップショットを取得するよう構成されているため、1秒あたりのイベント数を算出するには3,600で割る必要があります。Exadataでは、ここで観測されている値をはるかに上回る、桁違いのI/Oイベント数を1秒あたりに処理することが可能です。

SQLオフロードの活用機会（SQL Offload Opportunities）

Exadata Storageへのオフロードが明確に期待できるかどうかを判断するためには、Direct Path I/Oの有無を確認する必要があります。Direct Path I/Oの割合が十分に高いシステムでは、通常、以下に示す「Top 10 Timed Events」レポートにこれらのイベントが表示されます。一般的に、これらのイベントは、ワークロードをExadataへ移行した際にSQLオフロードの対象となるSQLを示していると考えられます。単純にマルチブロック読込み（multi-block reads）だけを見ても、それが必ずしもオフロードにつながるとは限りません。一方で、direct path readは、Exadataでのオフロード可能性を評価するうえで、より適切な指標となります。

このアプリケーションは主にOLTP（オンライン・トランザクション処理）ワークロードであるため、Exadataへ移行した後に大量のI/Oがオフロードされることは想定していません。アプリケーションチームがパフォーマンスチューニングを実施し、その結果としてワークロード特性が変化する可能性はありますが、サイジング作業においては、そのようなパフォーマンスチューニングによる変更は前提としません。サイジングの基本原則の一つは、サイジングとパフォーマンスチューニングを同時に行わないことです。両者を組み合わせると、「チューニングしてサイジング、さらにチューニングして再度サイジング」といった終わりのないループに陥りやすくなります。そのため、まずシステムが適切にチューニングされていることを前提とし、その結果として発生するワークロードを処理できるようにサイジングを行う必要があります。

SGA Target Advisorの活用方法

Oracle DatabaseのSGA Target Advisorは、SGAサイズを増減した場合のパフォーマンスへの影響に関する情報を提供します。データベースによる自動分析では、SGAメモリサイズを増加または減少させた際に予想されるI/Oへの影響が示されます。ここでは、SGA Target Advisorの値（AWRレポートやその他のツールから取得可能）をグラフ化し、状況をより分かりやすく示しています。現在のシステムでは、SGAサイズを縮小するとI/Oは増加すると予測されており（赤色で表示）、逆にSGAサイズを拡大するとI/Oは減少すると予測されています（緑色で表示）。

前のセクションで説明したとおり、既存のレガシーシステムはExadataと比較してI/O性能が劣ることが分かっています。さらに、本記事の前半で説明したDirect Path I/Oの分析から、このケースでは約10%のI/OおよびSQL処理がExadata Storage層で実行されると見込まれており、その結果としてSGAへの負荷も軽減されます。Exadataの優れたI/O性能とSQLオフロード機能を考慮すると、このシステムではSGAサイズを30%削減（500GBから350GBへ縮小）しても、大幅なI/O増加を招くことなく安全に運用できると判断できます。SGAを縮小するとI/O量は約50%増加すると予測されますが、それらのI/OはExadata上ではより高速に処理されます。また、このデータベースをExadataへ移行した後には、さらなる最適化が可能になる場合もあるため、移行後に同じ分析を再実施することを推奨します。

この分析を行う際には、AWRスナップショットの中でも最もアクティビティが高い時間帯を対象に分析することが重要です。これらの統計情報はインスタンスの最後の再起動以降の累積値であるためです。通常、最もアクティビティが高いスナップショット区間は最新（最後）の区間になりますが、データベースが再起動されている場合は、それ以前の区間が最も高いアクティビティを示すこともあります。

ピークシーズン時のメトリクス（High Season Metrics）

AWR履歴に含まれる期間の日付を考慮することは極めて重要です。例えば、ビジネスやデータベースの負荷が季節によって大きく変動する場合、この分析は必ずピークシーズン（繁忙期）に収集されたメトリクスを対象に実施する必要があります。AWR履歴のデフォルト（かつ最小）の保持期間は8日間であるため、稼働中のデータベースを単純に参照すると、直近8日間のアクティビティしか確認できません。これは現在発生しているパフォーマンス問題の診断には十分かもしれませんが、サイジングを行うタイミングとしては必ずしも適切ではありません。そのため、繁忙期のデータが確実に含まれるよう、過去のAWR履歴期間を参照する必要がある場合があります。また、常に1か月分のメトリクスを保持できるよう、AWR履歴の保持期間を約33日間に延長することも検討するとよいでしょう。

「繁忙期」の代表的な例として、季節変動の大きい小売業が挙げられます。サイジング作業は、小売業のピークシーズン中には決して実施されません。繁忙期には、システムが安定して稼働するよう運用担当者が対応に追われており、サイジングやキャパシティプランニングに時間を割くことは通常できません。また、次回の繁忙期に向けたサイジングの検討は、現在の繁忙期が終了してからかなり後になって行われるのが一般的です。そのようなケースでは、直近8日間のメトリクスには繁忙期の負荷が含まれておらず、その繁忙期は数か月前に発生していた可能性もあります。

まとめ

適切にサイジングされたExadataシステムであれば、本分析で示したレガシーシステムと比較して、より優れたI/Oパフォーマンスを提供できます。Exadataの高いI/O性能により、移行時にOracle System Global Area（SGA）のサイズを削減できる場合が少なくありません。ただし、SGAサイズを削減する前には、本記事で説明した手法に従って十分な分析を実施することを推奨します。