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

PDF

作成者: Abhishek Verma (AWS) および Eduardo Valentim (AWS)

概要

Oracle データベースを Amazon Relational Database Service (Amazon RDS) または Amazon Aurora に移行する場合、ターゲットデータベースの CPU、メモリ、ディスク I/O を計算することが重要な要件です。Oracle 自動ワークロードリポジトリ (AWR) レポートを分析することにより、ターゲットデータベースに必要なキャパシティを推定できます。このパターンでは、AWR レポートを使用して、これらの値を推定する方法を説明します。

ソース Oracle データベース は、オンプレミスで、または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでホストされることが可能です。あるいは、Amazon RDS for Oracle DB インスタンス でも可能です。ターゲットデータベースは、Amazon RDS または Aurora データベースのどれでも構いません。

注記

ターゲットデータベースエンジンが Oracle の場合、容量の見積もりはより正確になります。その他の Amazon RDS データベースでは、データベースアーキテクチャの違いによりエンジンサイズが異なる場合があります。

Oracle データベースを移行する前にパフォーマンステストを実行することを推奨します。

前提条件と制限

前提条件

• AWR レポートをダウンロードするには、Oracle データベースエンタープライズエディションライセンスと Oracle 診断パックライセンスが必要です。

製品バージョン

• バージョン 11g (バージョン 11.2.0.3.v1 以降）および 12.2、18c、19c までのすべての Oracle Database エディション。

• このパターンでは、OracleエンジニアドシステムズやOracleクラウドインフラストラクチャ（OCI）が、カバーされていません。

アーキテクチャ

ソーステクノロジースタック

次のいずれかです:

• オンプレミスの Oracle データベース

• EC2 インスタンス上の Oracle データベース

• Amazon RDS for Oracle DB インスタンス。

ターゲットテクノロジースタック

• Amazon RDS データベース または Amazon Aurora クラスター

ターゲット アーキテクチャ

完全な移行プロセスについては、「AWS DMS と AWS SCT を使用して Oracle データベースを Aurora PostgreSQL に移行する」のパターンを参照してください。

自動化とスケール

移行する 複数の Oracle データベースがあり、追加のパフォーマンスメトリクスを使用したい場合、ブログ記事「Oracle のパフォーマンスメトリックスに基づきAmazon RDS インスタンスを大規模に適切なサイズ」 で説明されている手順に従ってプロセスを自動化できます。

ツール

• 「Oracle 自動ワークロードリポジトリ (AWR)」 は Oracle データベースにビルドインされているリポジトリです。システム・アクティビティとワークロード・データを定期的に収集して保存し、自動データベース診断モニター (ADDM) によって分析します。AWR は、システムパフォーマンスデータのスナップショットを定期的に(デフォルトでは 60 分ごと) 作成し、その情報を保存します(デフォルトでは最大 8 日間)。 AWR のビューとレポートを使用して、このデータを分析できます。

ベストプラクティス

• ターゲットデータベースのリソース要件を計算するために、単一の AWR レポート、複数の AWR レポート、または動的 AWR ビューを使用できます。ピークロードの時に、複数の AWR レポートを使用して、ピーク時のロードを処理するのに必要なリソースを推定することを推奨します。さらに、動的ビューでは、リソース要件をより正確に計算することを支援するデータポイントがより多く提供されます。 

• IOPSの推定は移行する予定のデータベースについてのみ行い、他のデータベースやそのディスクを使うプロセスについては行いません。

• データベースが使用する I/O の量を計算するには、AWR レポートのロードプロファイルセクションの情報を使用しないでください。その代わり、可能な場合は、 I/O プロファイルセクションを使用するか、インスタンスアクティビティステータスセクションに飛んで、物理的な読み書き操作の合計値を確認します。

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

• 適切なインスタンスタイプを決定する際には、特定のインスタンスサイズの I/O スループット制限 (Amazon Elastic Block Store (Amazon EBS) のスループットとネットワークスループット) を考慮します。

• 移行前にパフォーマンステストを実行して、エンジンサイズを検証します。

エピック

レポートを作成する

タスク	説明	必要なスキル
AWR レポートを有効にします。	レポートを有効にするには、「Oracle ドキュメント」の手順に従ってください。	DBA
保持期間を確認します。	AWR レポートの保持期間を確認するには、次のクエリを使用します。 SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;	DBA
スナップショットを生成します。	AWR スナップショットの間隔がピークワークロードの急増を捉えるほどきめ細かくない場合、AWR レポートを手動で生成できます。手動 AWR スナップショットを生成するには、次のクエリを使用します。 SQL> EXEC dbms_workload_repository.create_snapshot;	DBA
最近のスナップショットをチェックします。	最近の 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;	DBA

レポートを作成する

タスク	説明	必要なスキル
AWR レポートを有効にします。	レポートを有効にするには、「Oracle ドキュメント」の手順に従ってください。	DBA
保持期間を確認します。	AWR レポートの保持期間を確認するには、次のクエリを使用します。 SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;	DBA
スナップショットを生成します。	AWR スナップショットの間隔がピークワークロードの急増を捉えるほどきめ細かくない場合、AWR レポートを手動で生成できます。手動 AWR スナップショットを生成するには、次のクエリを使用します。 SQL> EXEC dbms_workload_repository.create_snapshot;	DBA
最近のスナップショットをチェックします。	最近の 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;	DBA

ディスク I/O 要件を推定します

タスク	説明	必要なスキル
メソッドを選択します。	IOPS は、ストレージデバイスの 1 秒あたりの入力操作と出力操作の標準的な尺度であり、読み取り操作と書き込み操作の両方が含まれます。  オンプレミスデータベースを AWS に移行する場合、データベースが使用するピークディスク I/O を決定する必要があります。 次の方法を使用して、ターゲットデータベースのディスク I/O を推定することができます: AWR レポートのロードプロファイルセクション AWR レポートのインスタンスアクティビティ統計セクション (Oracle データベース12c 以降の場合、このセクションを使用します) AWR レポートの I/O プロファイルセクション (12c 以前のバージョンの Oracle データベースの場合、このセクションを使用します) AWR ビュー 次のステップでこの 4 つのメソッドについて説明します。	DBA
オプション 1: 負荷プロファイルを使用します。	次のテーブルでは、AWR レポートのロードプロファイルセクションの例を示しています。 重要 より正確な情報を得るには、ロードプロファイルの代わりにオプション 2 (I/O プロファイル) またはオプション 3 (インスタンスアクティビティ統計) を使用することをお勧めします。   1 秒あたり トランザクションあたり 実行あたり 呼び出しあたり DB 時間: 26.6 0.2 0.00 0.02 DB CPU: 18.0 0.1 0.00 0.01 バックグラウンド CPU: 0.2 0.0 0.00 0.00 やり直しのサイズ (バイト): 2,458,539.9 17,097.5     ロジカルリード (ブロック): 3,371,931.5 23,449.6     ブロック変更: 21,643.5 150.5     物理的読み取り (ブロック): 13,575.1 94.4     物理的書き込み (ブロック): 3,467.3 24.1     読み取り IO リクエスト: 3,586.8 24.9     書き込み IO リクエスト: 574.7 4.0     読み取り IO (MB): 106.1 0.7     書き込み IO (MB): 27.1 0.2     IM スキャン行: 0.0 0.0     セッションのロジカル読み取り IM:         ユーザーの呼び出し: 1,245.7 8.7     解析 (SQL): 4,626.2 32.2     ハード解析 (SQL): 8.9 0.1     SQL ワークエリア (MB): 824.9 5.7     ログオン: 1.7 0.0     実行 (SQL): 136,656.5 950.4     ロールバック： 22.9 0.2     トランザクション： 143.8       この情報に基づいて、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 プロファイルほど正確ではありません。	DBA
オプション 2: インスタンスアクティビティ統計を使用します。	12c 以前のバージョンの Oracle Database を使用している場合、AWR レポートのインスタンスアクティビティ統計セクションを使用して IOPS とスループットを推定できます。次の表に、この構文の例を示します。 Statistic 合計 1 秒あたり トランザクションあたり 物理的読み取り、IO リクエストの合計 2,547,333,217 3,610.28 25.11 物理的読み取りの合計バイト数 80,776,296,124,928 114、482、426.26 796,149.98 物理的書き込みのI/O リクエストの合計数 534,198,208 757.11 5.27 物理的書き込みの合計バイト数 25,517,678,849,024 36,165,631.84 251,508.18 この情報に基づいて、合計 IOPS とスループットを次のように計算できます： 合計 IOPS = 3,610.28 + 757.11 = 4367 合計 Mbps = 114,482,426.26 + 36,165,631.84 = 150648058.1/ 1024 / 1024 = 143 Mbps	DBA
オプション 3: I/O プロファイルを使用します。	Oracle Database 12c では、AWR レポートに I/O Profiles セクションが含まれています。このセクションでは、すべての情報が 単一のテーブルに表示され、データベースのパフォーマンスに関するより正確なデータが得られます。次の表に、この構文の例を示します。   1 秒あたりの読み取り+書き込み 1 秒あたりの読み取り数 1 秒あたりの書き込み数 リクエスト合計： 4,367.4 3,610.3 757.1 データベースリクエスト: 4,161.5 3,586.8 574.7 最適化されたリクエスト: 0.0 0.0 0.0 やり直しリクエスト: 179.3 2.8 176.6 合計 (MB): 143.7 109.2 34.5 データベース (MB): 133.1 106.1 27.1 最適化された合計 (MB): 0.0 0.0 0.0 やり直し (MB): 7.6 2.7 4.9 データベース (ブロック): 17,042.4 13,575.1 3,467.3 バッファキャッシュ経由 (ブロック): 5,898.5 5,360.9 537.6 ダイレクト (ブロック): 11,143.9 8,214.2 2,929.7 このテーブルでは、スループットと合計 IOPS について次の値を示します： 　　　スループット = 143 MBPS (5 行目の 2 列目の合計とラベル付きから) IOPS = 4,367.4 (最初の行の リクエストの合計 とラベル付き、2　番目の列)	DBA
オプション 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;	DBA

ディスク I/O 要件を推定します

タスク	説明	必要なスキル
メソッドを選択します。	IOPS は、ストレージデバイスの 1 秒あたりの入力操作と出力操作の標準的な尺度であり、読み取り操作と書き込み操作の両方が含まれます。  オンプレミスデータベースを AWS に移行する場合、データベースが使用するピークディスク I/O を決定する必要があります。 次の方法を使用して、ターゲットデータベースのディスク I/O を推定することができます: AWR レポートのロードプロファイルセクション AWR レポートのインスタンスアクティビティ統計セクション (Oracle データベース12c 以降の場合、このセクションを使用します) AWR レポートの I/O プロファイルセクション (12c 以前のバージョンの Oracle データベースの場合、このセクションを使用します) AWR ビュー 次のステップでこの 4 つのメソッドについて説明します。	DBA
オプション 1: 負荷プロファイルを使用します。	次のテーブルでは、AWR レポートのロードプロファイルセクションの例を示しています。 重要 より正確な情報を得るには、ロードプロファイルの代わりにオプション 2 (I/O プロファイル) またはオプション 3 (インスタンスアクティビティ統計) を使用することをお勧めします。   1 秒あたり トランザクションあたり 実行あたり 呼び出しあたり DB 時間: 26.6 0.2 0.00 0.02 DB CPU: 18.0 0.1 0.00 0.01 バックグラウンド CPU: 0.2 0.0 0.00 0.00 やり直しのサイズ (バイト): 2,458,539.9 17,097.5     ロジカルリード (ブロック): 3,371,931.5 23,449.6     ブロック変更: 21,643.5 150.5     物理的読み取り (ブロック): 13,575.1 94.4     物理的書き込み (ブロック): 3,467.3 24.1     読み取り IO リクエスト: 3,586.8 24.9     書き込み IO リクエスト: 574.7 4.0     読み取り IO (MB): 106.1 0.7     書き込み IO (MB): 27.1 0.2     IM スキャン行: 0.0 0.0     セッションのロジカル読み取り IM:         ユーザーの呼び出し: 1,245.7 8.7     解析 (SQL): 4,626.2 32.2     ハード解析 (SQL): 8.9 0.1     SQL ワークエリア (MB): 824.9 5.7     ログオン: 1.7 0.0     実行 (SQL): 136,656.5 950.4     ロールバック： 22.9 0.2     トランザクション： 143.8       この情報に基づいて、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 プロファイルほど正確ではありません。	DBA
オプション 2: インスタンスアクティビティ統計を使用します。	12c 以前のバージョンの Oracle Database を使用している場合、AWR レポートのインスタンスアクティビティ統計セクションを使用して IOPS とスループットを推定できます。次の表に、この構文の例を示します。 Statistic 合計 1 秒あたり トランザクションあたり 物理的読み取り、IO リクエストの合計 2,547,333,217 3,610.28 25.11 物理的読み取りの合計バイト数 80,776,296,124,928 114、482、426.26 796,149.98 物理的書き込みのI/O リクエストの合計数 534,198,208 757.11 5.27 物理的書き込みの合計バイト数 25,517,678,849,024 36,165,631.84 251,508.18 この情報に基づいて、合計 IOPS とスループットを次のように計算できます： 合計 IOPS = 3,610.28 + 757.11 = 4367 合計 Mbps = 114,482,426.26 + 36,165,631.84 = 150648058.1/ 1024 / 1024 = 143 Mbps	DBA
オプション 3: I/O プロファイルを使用します。	Oracle Database 12c では、AWR レポートに I/O Profiles セクションが含まれています。このセクションでは、すべての情報が 単一のテーブルに表示され、データベースのパフォーマンスに関するより正確なデータが得られます。次の表に、この構文の例を示します。   1 秒あたりの読み取り+書き込み 1 秒あたりの読み取り数 1 秒あたりの書き込み数 リクエスト合計： 4,367.4 3,610.3 757.1 データベースリクエスト: 4,161.5 3,586.8 574.7 最適化されたリクエスト: 0.0 0.0 0.0 やり直しリクエスト: 179.3 2.8 176.6 合計 (MB): 143.7 109.2 34.5 データベース (MB): 133.1 106.1 27.1 最適化された合計 (MB): 0.0 0.0 0.0 やり直し (MB): 7.6 2.7 4.9 データベース (ブロック): 17,042.4 13,575.1 3,467.3 バッファキャッシュ経由 (ブロック): 5,898.5 5,360.9 537.6 ダイレクト (ブロック): 11,143.9 8,214.2 2,929.7 このテーブルでは、スループットと合計 IOPS について次の値を示します： 　　　スループット = 143 MBPS (5 行目の 2 列目の合計とラベル付きから) IOPS = 4,367.4 (最初の行の リクエストの合計 とラベル付き、2　番目の列)	DBA
オプション 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;	DBA

CPU 要件の推定

タスク	説明	必要なスキル
メソッドを選択します。	ターゲットデータベースに必要な CPU は、次の 3 つの方法で推定することができます: プロセッサの実際に使用可能なコアを使用して OS 統計に基づく活用コアを使用して データベース統計に基づく活用コアを使用して 使用されるコアを確認する場合、OS 統計の代わりに、データベースメトリクスメソッドを使用することを推奨します。理由は、移行を計画しているデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。 CPU 世代に基づいて、要件を推定することもできます。異なる世代の CPU を使用している場合、ホワイトペーパー「ワークロードパフォーマンスを最適化するための vCPUs 数の謎を解き明かす」の手順に従うことで、必要なターゲットデータベースを推定することができます。	DBA
オプション 1: 利用可能なコアに基づいて要件を推定します。	AWR レポートで: CPU は論理 CPU と仮想 CPU を指します。  コアは物理 CPU チップセットに搭載されているプロセッサの数です。  ソケットは、チップをボードに接続する物理デバイスです。マルチコアプロセッサには、複数の CPU コアを搭載したソケットがあります。 使用可能なコア数は次の 2 つの方法のいずれかで推定できます： OSコマンドを使用して AWR レポートを使用して 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 注記   CPU 使用率を抽出するために、 nmon や sar などの OS コマンドを使用することはお勧めしません。この理由は、これらの計算には他のプロセスの CPU 使用率が含まれて、データベースが使用する実際の CPU 使用率を反映していない可能性があるためです。 AWR レポートを使用して使用可能なコアを推定するには AWR レポートの最初のセクションから CPU 使用率を導き出すこともできます。以下はレポートからの抜粋です。 DB Name DB Id インスタンス Inst num 起動時間 [Release] (リリース) RAC XXXX <DB_ID> XXXX 1 2020年 9月5日 23:09 12.1.0.2.0 いいえ ホスト名 プラットフォーム Cpus コア ソケット メモリ (GB) ＜host_name＞ Linux x86 64 ビット 80 80 2 441.78 この例では、CPU 数は 80 で、これは論理 (仮想) CPU であることを示しています。また、この構成には 2 つのソケットがあり、各ソケットに 1 つの物理プロセッサ (合計で 2 つの物理プロセッサ) があり、物理プロセッサまたはソケットごとに 40 コアがあることも確認できます。	DBA
オプション 2: OS 統計を使用して CPU 使用率を推定します。	OS で(sarやその他のホスト OS ユーティリティを使用して)、またはAWR レポートのオペレーティングシステム統計セクションから IDLE/ (IDLE+BUSY) 値をレビューすることで、OS の CPU 使用率統計をチェックできます。v$osstat から直接消費された CPU の秒数を確認できます。AWR レポートと Statspack レポートでも、オペレーティングシステム統計セクションでこのデータが表示されます。 同じボックスに複数のデータベースがある場合、BUSY_TIME の v$osstat 値はすべて同じになります。 Statistic 値 最終値 FREE_MEMORY_BYTES 6,810,677,248 12,280,799,232 INACTIVE_MEMORY_BYTES 175、627、333、632 160、380、653、568 SWAP_FREE_BYTES 17,145,614,336 17,145,872,384 BUSY_TIME 1,305,569,937   IDLE_TIME 4,312,718,839   IOWAIT_TIME 53,417,174   NICE_TIME 29,815   SYS_TIME 148,567,570   USER_TIME 1,146,918,783   LOAD 25 29 VM_IN_BYTES 593,920   OUT_BYTES 327,680   PHYSICAL_MEMORY_BYTES 474、362、417、152   NUM_CUPS 80   NUM_CPU_CORES 80   NUM_CPU_SOCKETS 2   GLOBAL_RECEIVE_SIZE_MAX 4,194,304   GLOBAL_SEND_SIZE_MAX 2,097,152   TCP_RECEIVE_SIZE_DEFAULT 87,380   TCP_RECEIVE_SIZE_MAX 6,291,456   TCP_RECEIVE_SIZE_MIN 4,096   TCP_SEND_SIZE_DEFAULT 16,384   TCP_SEND_SIZE_MAX 4,194,304   TCP_SEND_SIZE_MIN 4,096   システムに他の 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% 利用	DBA
オプション 3: データベースメトリクスを使用して CPU 使用率を推定します。	システム内で複数のデータベースが実行されている場合、レポートの先頭に表示されるデータベースメトリックを使用できます。   スナップ ID スナップタイム セッション カーソル/セッション スナップを開始: 184662 2020年 9月28日 09:00:42 1226 35.8 エンドスナップ: 185446 2020年 10月6日 13:00:20 1876 41.1 経過時間:   11,759.64 (分)     DB 時間:   312,625.40 (分)     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 では、計算された使用率がオペレーティングシステムまたはデータベースの値と一致しません。これらの値は、他のオペレーティングシステムでは一致します。	DBA

CPU 要件の推定

タスク	説明	必要なスキル
メソッドを選択します。	ターゲットデータベースに必要な CPU は、次の 3 つの方法で推定することができます: プロセッサの実際に使用可能なコアを使用して OS 統計に基づく活用コアを使用して データベース統計に基づく活用コアを使用して 使用されるコアを確認する場合、OS 統計の代わりに、データベースメトリクスメソッドを使用することを推奨します。理由は、移行を計画しているデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。 CPU 世代に基づいて、要件を推定することもできます。異なる世代の CPU を使用している場合、ホワイトペーパー「ワークロードパフォーマンスを最適化するための vCPUs 数の謎を解き明かす」の手順に従うことで、必要なターゲットデータベースを推定することができます。	DBA
オプション 1: 利用可能なコアに基づいて要件を推定します。	AWR レポートで: CPU は論理 CPU と仮想 CPU を指します。  コアは物理 CPU チップセットに搭載されているプロセッサの数です。  ソケットは、チップをボードに接続する物理デバイスです。マルチコアプロセッサには、複数の CPU コアを搭載したソケットがあります。 使用可能なコア数は次の 2 つの方法のいずれかで推定できます： OSコマンドを使用して AWR レポートを使用して 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 注記   CPU 使用率を抽出するために、 nmon や sar などの OS コマンドを使用することはお勧めしません。この理由は、これらの計算には他のプロセスの CPU 使用率が含まれて、データベースが使用する実際の CPU 使用率を反映していない可能性があるためです。 AWR レポートを使用して使用可能なコアを推定するには AWR レポートの最初のセクションから CPU 使用率を導き出すこともできます。以下はレポートからの抜粋です。 DB Name DB Id インスタンス Inst num 起動時間 [Release] (リリース) RAC XXXX <DB_ID> XXXX 1 2020年 9月5日 23:09 12.1.0.2.0 いいえ ホスト名 プラットフォーム Cpus コア ソケット メモリ (GB) ＜host_name＞ Linux x86 64 ビット 80 80 2 441.78 この例では、CPU 数は 80 で、これは論理 (仮想) CPU であることを示しています。また、この構成には 2 つのソケットがあり、各ソケットに 1 つの物理プロセッサ (合計で 2 つの物理プロセッサ) があり、物理プロセッサまたはソケットごとに 40 コアがあることも確認できます。	DBA
オプション 2: OS 統計を使用して CPU 使用率を推定します。	OS で(sarやその他のホスト OS ユーティリティを使用して)、またはAWR レポートのオペレーティングシステム統計セクションから IDLE/ (IDLE+BUSY) 値をレビューすることで、OS の CPU 使用率統計をチェックできます。v$osstat から直接消費された CPU の秒数を確認できます。AWR レポートと Statspack レポートでも、オペレーティングシステム統計セクションでこのデータが表示されます。 同じボックスに複数のデータベースがある場合、BUSY_TIME の v$osstat 値はすべて同じになります。 Statistic 値 最終値 FREE_MEMORY_BYTES 6,810,677,248 12,280,799,232 INACTIVE_MEMORY_BYTES 175、627、333、632 160、380、653、568 SWAP_FREE_BYTES 17,145,614,336 17,145,872,384 BUSY_TIME 1,305,569,937   IDLE_TIME 4,312,718,839   IOWAIT_TIME 53,417,174   NICE_TIME 29,815   SYS_TIME 148,567,570   USER_TIME 1,146,918,783   LOAD 25 29 VM_IN_BYTES 593,920   OUT_BYTES 327,680   PHYSICAL_MEMORY_BYTES 474、362、417、152   NUM_CUPS 80   NUM_CPU_CORES 80   NUM_CPU_SOCKETS 2   GLOBAL_RECEIVE_SIZE_MAX 4,194,304   GLOBAL_SEND_SIZE_MAX 2,097,152   TCP_RECEIVE_SIZE_DEFAULT 87,380   TCP_RECEIVE_SIZE_MAX 6,291,456   TCP_RECEIVE_SIZE_MIN 4,096   TCP_SEND_SIZE_DEFAULT 16,384   TCP_SEND_SIZE_MAX 4,194,304   TCP_SEND_SIZE_MIN 4,096   システムに他の 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% 利用	DBA
オプション 3: データベースメトリクスを使用して CPU 使用率を推定します。	システム内で複数のデータベースが実行されている場合、レポートの先頭に表示されるデータベースメトリックを使用できます。   スナップ ID スナップタイム セッション カーソル/セッション スナップを開始: 184662 2020年 9月28日 09:00:42 1226 35.8 エンドスナップ: 185446 2020年 10月6日 13:00:20 1876 41.1 経過時間:   11,759.64 (分)     DB 時間:   312,625.40 (分)     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 では、計算された使用率がオペレーティングシステムまたはデータベースの値と一致しません。これらの値は、他のオペレーティングシステムでは一致します。	DBA

メモリ要件の推定

タスク	説明	必要なスキル
メモリ統計情報を使用してメモリ要件を推定します。	ソースデータベースのメモリを計算し、それをターゲットデータベースでマッチさせるのに、AWR レポートを使用できます。また、コストを節約するのに、既存のデータベースのパフォーマンスを確認してメモリ要件を減らすか、パフォーマンスを向上させるために要件を増やす必要もあります。それには、AWR の応答時間とアプリケーションのサービスレベルアグリーメント (SLA) を詳細に分析する必要があります。Oracle のシステムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) の使用量の合計を、Oracle の推定メモリ使用率として使用します。OS に さらに20% を追加して目標メモリサイズ要件を決定します。Oracle RAC では、すべての RAC ノードの推定メモリ使用率の合計を使用して、合計メモリを減らします。理由は、メモリが共通ブロックに格納されるためです。 インスタンス効率パーセンテージのメトリックを確認します。この表では、次の用語を使用します： Buffer Nowait % は、物理的な I/O を実行せずにバッファキャッシュで特定のブロックが見つかった回数の割合で、パフォーマンス向上には 100% を目標とします。  Buffer Nowait % は 100% 近くになるはずです。 Latch Hit % は 100% に近いはずです。  Non-Parse CPU の %は、非解析アクティビティに費やされた CPU 時間の割合です。この値は 100% に近いはずです。 インスタンス効率の割合 (目標 100%) Buffer Nowait %: 99.99 Redo NoWait %: 100.00 Buffer Hit %: 99.84 インメモリソート %: 100.00 ライブラリー %: 748.77 ソフト解析 %: 99.81 Execute to Parse %: 96.61 ラッチヒット %: 100.00 Parse CPU to Parse Elapsd %: 72.73 Non-Parse CPUの率 %: 99.21 フラッシュキャッシュのヒット率 %: 0.00     この例では、すべてのメトリクスに問題がないように見えるため、既存のデータベースの SGA と PGA をキャパシティプランニングの要件として使用できます。 メモリ統計セクションを確認し、SGA/PGA を計算します。   開始 修了 ホストメモリ (MB): 452,387.3 452,387.3 SGAの使用 (MB): 220,544.0 220,544.0 PGA 使用量 (MB): 36,874.9 45,270.0 使用中のインスタンスメモリの合計 = 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 が事前に計算されます。事前に計算された値が、推定値に近いことを確保します。	DBA

メモリ要件の推定

タスク	説明	必要なスキル
メモリ統計情報を使用してメモリ要件を推定します。	ソースデータベースのメモリを計算し、それをターゲットデータベースでマッチさせるのに、AWR レポートを使用できます。また、コストを節約するのに、既存のデータベースのパフォーマンスを確認してメモリ要件を減らすか、パフォーマンスを向上させるために要件を増やす必要もあります。それには、AWR の応答時間とアプリケーションのサービスレベルアグリーメント (SLA) を詳細に分析する必要があります。Oracle のシステムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) の使用量の合計を、Oracle の推定メモリ使用率として使用します。OS に さらに20% を追加して目標メモリサイズ要件を決定します。Oracle RAC では、すべての RAC ノードの推定メモリ使用率の合計を使用して、合計メモリを減らします。理由は、メモリが共通ブロックに格納されるためです。 インスタンス効率パーセンテージのメトリックを確認します。この表では、次の用語を使用します： Buffer Nowait % は、物理的な I/O を実行せずにバッファキャッシュで特定のブロックが見つかった回数の割合で、パフォーマンス向上には 100% を目標とします。  Buffer Nowait % は 100% 近くになるはずです。 Latch Hit % は 100% に近いはずです。  Non-Parse CPU の %は、非解析アクティビティに費やされた CPU 時間の割合です。この値は 100% に近いはずです。 インスタンス効率の割合 (目標 100%) Buffer Nowait %: 99.99 Redo NoWait %: 100.00 Buffer Hit %: 99.84 インメモリソート %: 100.00 ライブラリー %: 748.77 ソフト解析 %: 99.81 Execute to Parse %: 96.61 ラッチヒット %: 100.00 Parse CPU to Parse Elapsd %: 72.73 Non-Parse CPUの率 %: 99.21 フラッシュキャッシュのヒット率 %: 0.00     この例では、すべてのメトリクスに問題がないように見えるため、既存のデータベースの SGA と PGA をキャパシティプランニングの要件として使用できます。 メモリ統計セクションを確認し、SGA/PGA を計算します。   開始 修了 ホストメモリ (MB): 452,387.3 452,387.3 SGAの使用 (MB): 220,544.0 220,544.0 PGA 使用量 (MB): 36,874.9 45,270.0 使用中のインスタンスメモリの合計 = 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 が事前に計算されます。事前に計算された値が、推定値に近いことを確保します。	DBA

ターゲットデータベースの DB インスタンスタイプを決定

タスク	説明	必要なスキル
ディスク I/O、CPU、メモリの見積もりに基づいて DB インスタンスタイプを決定します。	前のステップの見積もりに基づいて、ターゲットの Amazon RDS または Aurora データベースの容量は次のようになるはずです: CPU の 68 コア スループットの 143 MBPS   ディスク I/O の 4367 IOPS 464 GB のメモリ ターゲットの Amazon RDS または Aurora データベースでは、これらの値を db.r5.16xlarge インスタンスタイプにはマッピングできます。このインスタンスタイプは 32 コアのキャパシティ、512 GB の RAM、13,600 Mbps のスループットがあります。 詳細については、AWS ブログ記事「Oracle のパフォーマンスメトリクスに基づく Amazon RDS インスタンスを大規模に適切なサイズ」を参照してください。	DBA

ターゲットデータベースの DB インスタンスタイプを決定

タスク	説明	必要なスキル
ディスク I/O、CPU、メモリの見積もりに基づいて DB インスタンスタイプを決定します。	前のステップの見積もりに基づいて、ターゲットの Amazon RDS または Aurora データベースの容量は次のようになるはずです: CPU の 68 コア スループットの 143 MBPS   ディスク I/O の 4367 IOPS 464 GB のメモリ ターゲットの Amazon RDS または Aurora データベースでは、これらの値を db.r5.16xlarge インスタンスタイプにはマッピングできます。このインスタンスタイプは 32 コアのキャパシティ、512 GB の RAM、13,600 Mbps のスループットがあります。 詳細については、AWS ブログ記事「Oracle のパフォーマンスメトリクスに基づく Amazon RDS インスタンスを大規模に適切なサイズ」を参照してください。	DBA

関連リソース

• 「Aurora DB インスタンスクラス」 (Amazon Aurora ドキュメント)

• 「Amazon RDS DB インスタンスストレージ」 (Amazon RDS ドキュメント)

• 「AWS マイナーツール」 (GitHub リポジトリ)