翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWR レポートを使用して Oracle データベースの Amazon RDS エンジンサイズを推定 *Amazon Web Services、Abhishek Verma、Eduardo Valentim* ## 概要 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 に移行する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.html)」のパターンを参照してください。 **自動化とスケール** 移行する 複数の Oracle データベースがあり、追加のパフォーマンスメトリクスを使用したい場合、ブログ記事「[Oracle のパフォーマンスメトリックスに基づきAmazon RDS インスタンスを大規模に適切なサイズ](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/)」 で説明されている手順に従ってプロセスを自動化できます。 ## ツール + 「[Oracle 自動ワークロードリポジトリ (AWR)](https://docs.oracle.com/en-us/iaas/performance-hub/doc/awr-report-ui.html)」 は 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 ドキュメント](https://docs.oracle.com/en/database/oracle/oracle-database/18/tgdba/gathering-database-statistics.html#GUID-26D359FA-F809-4444-907C-B5AFECD9AE29)」の手順に従ってください。 | 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 を推定することができます:[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
次のステップでこの 4 つのメソッドについて説明します。 | DBA | | オプション 1: 負荷プロファイルを使用します。 | 次のテーブルでは、AWR レポートのロードプロファイルセクションの例を示しています。より正確な情報を取得するには、ロードプロファイルの代わりに、オプション 2 (I/O プロファイル) またはオプション 3 (インスタンスアクティビティ統計データ) を使用することをおすすめします。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
この情報に基づいて、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 とスループットを推定できます。次の表に、この構文の例を示します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
この情報に基づいて、合計 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 セクションが含まれています。このセクションでは、すべての情報が 単一のテーブルに表示され、データベースのパフォーマンスに関するより正確なデータが得られます。次の表に、この構文の例を示します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
このテーブルでは、スループットと合計 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 | |   | 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 |   |   |   | | 統計 | Total | 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 | |   | 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 | ### CPU 要件の推定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メソッドを選択します。 | ターゲットデータベースに必要な CPU は、次の 3 つの方法で推定することができます:[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
使用されるコアを確認する場合、OS 統計の代わりに、データベースメトリクスメソッドを使用することを推奨します。理由は、移行を計画しているデータベースのみが使用する CPU に基づいているためです。(OS 統計情報には他のプロセスによる CPU 使用量も含まれます。) 移行後のパフォーマンスを向上させるには、ADDM レポートの CPU 関連の推奨事項も確認する必要があります。
CPU 世代に基づいて、要件を推定することもできます。異なる世代の CPU を使用している場合、ホワイトペーパー「[ワークロードパフォーマンスを最適化するための vCPUs 数の謎を解き明かす](https://d1.awsstatic.com/whitepapers/Demystifying_vCPUs.df200b766578b75009ad8d15c72e493d6408c68a.pdf)」の手順に従うことで、必要なターゲットデータベースを推定することができます。 | DBA | | オプション 1: 利用可能なコアに基づいて要件を推定します。 | AWR レポートで:[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
使用可能なコア数は次の 2 つの方法のいずれかで推定できます：[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
**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 使用率を導き出すこともできます。以下はレポートからの抜粋です。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
この例では、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$ossta**t 値はすべて同じになります。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
システムに他の 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 使用率を推定します。 | システム内で複数のデータベースが実行されている場合、レポートの先頭に表示されるデータベースメトリックを使用できます。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
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 | | DB Name | DB Id | インスタンス | Inst num | 起動時間 | リリース | RAC | | --- |--- |--- |--- |--- |--- |--- | | XXXX | | XXXX | 1 | 2020年 9月5日 23:09 | 12.1.0.2.0 | いいえ | | **ホスト名** | **プラットフォーム** | **Cpus** | **コア** | **ソケット** | **メモリ (GB)** | | ＜host\_name＞ | Linux x86 64 ビット | 80 | 80 | 2 | 441.78 | | 統計 | 値 | 最終値 | | --- |--- |--- | | **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 |   | |   | スナップ 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 (分) |   |   | ### メモリ要件の推定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | メモリ統計情報を使用してメモリ要件を推定します。 | ソースデータベースのメモリを計算し、それをターゲットデータベースでマッチさせるのに、AWR レポートを使用できます。また、コストを節約するのに、既存のデータベースのパフォーマンスを確認してメモリ要件を減らすか、パフォーマンスを向上させるために要件を増やす必要もあります。それには、AWR の応答時間とアプリケーションのサービスレベルアグリーメント (SLA) を詳細に分析する必要があります。Oracle のシステムグローバルエリア (SGA) とプログラムグローバルエリア (PGA) の使用量の合計を、Oracle の推定メモリ使用率として使用します。OS に さらに20% を追加して目標メモリサイズ要件を決定します。Oracle RAC では、すべての RAC ノードの推定メモリ使用率の合計を使用して、合計メモリを減らします。理由は、メモリが共通ブロックに格納されるためです。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
* 使用中のインスタンスメモリの合計 = 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 | | 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 |   |   | |   | 開始 | 修了 | | --- |--- |--- | | **ホストメモリ (MB):** | 452,387.3 | 452,387.3 | | **SGAの使用 (MB):** | 220,544.0 | 220,544.0 | | **PGA 使用量 (MB):** | 36,874.9 | 45,270.0 | ### ターゲットデータベースの DB インスタンスタイプを決定 | タスク | 説明 | 必要なスキル | | --- | --- | --- | | ディスク I/O、CPU、メモリの見積もりに基づいて DB インスタンスタイプを決定します。 | 前のステップの見積もりに基づいて、ターゲットの Amazon RDS または Aurora データベースの容量は次のようになるはずです:[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
ターゲットの Amazon RDS または Aurora データベースでは、これらの値を db.r5.16xlarge インスタンスタイプにはマッピングできます。このインスタンスタイプは 32 コアのキャパシティ、512 GB の RAM、13,600 Mbps のスループットがあります。 詳細については、AWS ブログ記事「[Oracle のパフォーマンスメトリクスに基づく Amazon RDS インスタンスを大規模に適切なサイズ](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/)」を参照してください。 | DBA | ## 関連リソース + 「[Aurora DB インスタンスクラス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html)」 (Amazon Aurora ドキュメント) + 「[Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」 (Amazon RDS ドキュメント) + 「[AWS マイナーツール](https://github.com/tmuth/AWR-Miner/blob/master/release/5.0.8/AWR-Miner-capture-5.0.8/awr_miner.sql)」 (GitHub リポジトリ)