AWR レポートを使用して Oracle データベースの Amazon RDS エンジンサイズを推定

AWR レポートを有効にします。

レポートを有効にするには、「Oracle ドキュメント」の手順に従ってください。

保持期間を確認します。

AWR レポートの保持期間を確認するには、次のクエリを使用します。

SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;

スナップショットを生成します。

AWR スナップショットの間隔がピークワークロードの急増を捉えるほどきめ細かくない場合、AWR レポートを手動で生成できます。手動 AWR スナップショットを生成するには、次のクエリを使用します。

SQL> EXEC dbms_workload_repository.create_snapshot;

最近のスナップショットをチェックします。

最近の AWR スナップショットを確認するには、次のクエリを使用します。

SQL> SELECT snap_id, to_char(begin_interval_time,'dd/MON/yy hh24:mi') Begin_Interval,
 to_char(end_interval_time,'dd/MON/yy hh24:mi') End_Interval
 FROM dba_hist_snapshot
 ORDER BY 1;

メソッドを選択します。

IOPS は、ストレージデバイスの 1 秒あたりの入力操作と出力操作の標準的な尺度であり、読み取り操作と書き込み操作の両方が含まれます。 

オンプレミスデータベースを AWS に移行する場合、データベースが使用するピークディスク I/O を決定する必要があります。 次の方法を使用して、ターゲットデータベースのディスク I/O を推定することができます:

次のステップでこの 4 つのメソッドについて説明します。

オプション 1: 負荷プロファイルを使用します。

次のテーブルでは、AWR レポートのロードプロファイルセクションの例を示しています。

重要: より正確な情報を取得するには、ロードプロファイルの代わりに、オプション 2 (I/O プロファイル) またはオプション 3 (インスタンスアクティビティ統計データ) を使用することをおすすめします。

この情報に基づいて、IOPS とスループットを次のように計算できます：

IOPS = 読み取りI /O リクエスト: + 書き込み I/O リクエスト = 3,586.8 + 574.7 = 4134.5

スループット = 物理読み取り (ブロック) + 物理的書き込み (ブロック) = 13,575.1 + 3,467.3 = 17,042.4

Oracle のブロックサイズが 8 KB なので、合計スループットは次のように計算できます:

メガバイト単位の合計スループットは、 17042.4 * 8 * 024 / 1024 / 1024 = 133.2 MB

警告: 負荷プロファイルを使用してインスタンスサイズを推定しないでください。それは、インスタンスのアクティビティ統計や I/O プロファイルほど正確ではありません。

オプション 2: インスタンスアクティビティ統計を使用します。

12c 以前のバージョンの Oracle Database を使用している場合、AWR レポートのインスタンスアクティビティ統計セクションを使用して IOPS とスループットを推定できます。次の表に、この構文の例を示します。

この情報に基づいて、合計 IOPS とスループットを次のように計算できます：

合計 IOPS = 3,610.28 + 757.11 = 4367

合計 Mbps = 114,482,426.26 + 36,165,631.84 = 150648058.1/ 1024 / 1024 = 143 Mbps

オプション 3: I/O プロファイルを使用します。

Oracle Database 12c では、AWR レポートに I/O Profiles セクションが含まれています。このセクションでは、すべての情報が 単一のテーブルに表示され、データベースのパフォーマンスに関するより正確なデータが得られます。次の表に、この構文の例を示します。

このテーブルでは、スループットと合計 IOPS について次の値を示します：

　　　スループット = 143 MBPS (5 行目の 2 列目の合計とラベル付きから)

IOPS = 4,367.4 (最初の行の リクエストの合計 とラベル付き、2　番目の列)

オプション 4: AWR ビューを使用します。

AWR ビューを使用しても、同じ IOPS とスループット情報が表示されます。この情報を取得するには、次のクエリを使用します： 

break on report
 compute sum of Value on report
 select METRIC_NAME,avg(AVERAGE) as "Value"
 from dba_hist_sysmetric_summary
 where METRIC_NAME in ('Physical Read Total IO Requests Per Sec','Physical Write Total IO Requests Per Sec')
 group by metric_name;

メソッドを選択します。

ターゲットデータベースに必要な CPU は、次の 3 つの方法で推定することができます:

使用されるコアを確認する場合、OS 統計の代わりに、データベースメトリクスメソッドを使用することを推奨します。理由は、移行を計画しているデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。

CPU 世代に基づいて、要件を推定することもできます。異なる世代の CPU を使用している場合、ホワイトペーパー「ワークロードパフォーマンスを最適化するための vCPUs 数の謎を解き明かす」の手順に従うことで、必要なターゲットデータベースを推定することができます。

オプション 1: 利用可能なコアに基づいて要件を推定します。

AWR レポートで:

使用可能なコア数は次の 2 つの方法のいずれかで推定できます：

OS コマンドを使用して使用可能なコア数を推定するには

次のコマンドを使用して、プロセッサのコアをカウントします。

$ cat /proc/cpuinfo |grep "cpu cores"|uniq
cpu cores    : 4
cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\\nphysical/g | grep -v ^$ | sort | uniq | wc -l 

以下のコマンドを使用して、プロセッサのソケット数をカウントします。

grep "physical id" /proc/cpuinfo | sort -u
  physical id     : 0
  physical id     : 1

注: nmon と sar などの OS コマンドを使用して CPU 使用率を抽出することを推奨しません。この理由は、これらの計算には他のプロセスの CPU 使用率が含まれて、データベースが使用する実際の CPU 使用率を反映していない可能性があるためです。

AWR レポートを使用して使用可能なコアを推定するには

AWR レポートの最初のセクションから CPU 使用率を導き出すこともできます。以下はレポートからの抜粋です。

この例では、CPU 数は 80 で、これは論理 (仮想) CPU であることを示しています。また、この構成には 2 つのソケットがあり、各ソケットに 1 つの物理プロセッサ (合計で 2 つの物理プロセッサ) があり、物理プロセッサまたはソケットごとに 40 コアがあることも確認できます。 

オプション 2: OS 統計を使用して CPU 使用率を推定します。

OS で(sarやその他のホスト OS ユーティリティを使用して)、またはAWR レポートのオペレーティングシステム統計セクションから IDLE/ (IDLE+BUSY) 値をレビューすることで、OS の CPU 使用率統計をチェックできます。v$osstat から直接消費された CPU の秒数を確認できます。AWR レポートと Statspack レポートでも、オペレーティングシステム統計セクションでこのデータが表示されます。

同じボックスに複数のデータベースがある場合、BUSY_TIME の v$osstat 値はすべて同じになります。

システムに他の CPU 使用者がいない場合は、次の式を使用して CPU 使用率を計算します:

使用率 = ビジータイム/合計時間

ビジータイム = 要件 = v$osstat.Busy_Time

C = 合計時間 (ビジー+アイドル)

C = 容量 = v$OSTAT.Busy_Time + v$OSTAT.Idle_Time

   使用率 = BUSY_TIME / (BUSY_TIME + IDLE_TIME)

      = -1,305,569,937/(1,305,569,937 + 4,312,718,839)

      = 23% 利用

オプション 3: データベースメトリクスを使用して CPU 使用率を推定します。

システム内で複数のデータベースが実行されている場合、レポートの先頭に表示されるデータベースメトリックを使用できます。

CPU 使用率メトリクスを取得するには、次の式を使用します:

データベースの CPU 使用率 (使用可能な CPU パワーの%) = CPU 時間 /N UM_CPUS / 経過時間

CPU 使用率は CPU 時間で表され、CPU の待機時間の代わりに、 CPU に費やされた時間を示します。この計算結果は次のようになります：

= 312,625.40/11,759.64/80 = CPU の 33% が使用されています

コア数 (33%) * 80 = 26.4 コア

合計コア数 = 26.4 * (120%) = 31.68 コア

これら 2 つの値のうち大きい方を使用して、Amazon RDS または Aurora DB インスタンスの CPU 使用率を計算できます。

注: IBM AIX では、計算された使用率はオペレーティングシステムまたはデータベースの値と一致しません。これらの値は、他のオペレーティングシステムでは一致します。

メモリ統計情報を使用してメモリ要件を推定します。

ソースデータベースのメモリを計算し、それをターゲットデータベースでマッチさせるのに、AWR レポートを使用できます。また、コストを節約するのに、既存のデータベースのパフォーマンスを確認してメモリ要件を減らすか、パフォーマンスを向上させるために要件を増やす必要もあります。それには、AWR の応答時間とアプリケーションのサービスレベルアグリーメント (SLA) を詳細に分析する必要があります。Oracle のシステムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) の使用量の合計を、Oracle の推定メモリ使用率として使用します。OS に さらに20% を追加して目標メモリサイズ要件を決定します。Oracle RAC では、すべての RAC ノードの推定メモリ使用率の合計を使用して、合計メモリを減らします。理由は、メモリが共通ブロックに格納されるためです。

使用中のインスタンスメモリの合計 = SGA + PGA = 220 GB + 45 GB = 265 GB

バッファーの 20% を追加:

合計インスタンスのメモリ = 1.2 * 265 GB = 318 GB

SGA と PGA がホストメモリの 70% を占めるため、必要な合計メモリ量は次のようになります: 

　　ホストメモリの総容量 = 318/0.7 = 464 GB

注:　Amazon RDS for Oracle に移行すると、PGA と SGA は事前定義された計算式に基づいて事前に計算されます。事前に計算された値が、推定値に近いことを確保します。

ディスク I/O、CPU、メモリの見積もりに基づいて DB インスタンスタイプを決定します。

前のステップの見積もりに基づいて、ターゲットの Amazon RDS または Aurora データベースの容量は次のようになるはずです:

ターゲットの Amazon RDS または Aurora データベースでは、これらの値を db.r5.16xlarge インスタンスタイプにはマッピングできます。このインスタンスタイプは 32 コアのキャパシティ、512 GB の RAM、13,600 Mbps のスループットがあります。 詳細については、AWS ブログ記事「Oracle のパフォーマンスメトリクスに基づく Amazon RDS インスタンスを大規模に適切なサイズ」を参照してください。