使用 AWR 報告估計 Oracle 資料庫的 Amazon RDS 引擎大小 - AWS 方案指引
Summary先決條件和限制架構工具最佳實務史詩相關資源

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 AWR 報告估計 Oracle 資料庫的 Amazon RDS 引擎大小

由 Abhishek Verma (AWS) 和 Eduardo Valentim (AWS) 建立

Summary

當您將 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 資料庫執行個體。目標資料庫可以是任何 Amazon RDS 或 Aurora 資料庫。

注意

如果您的目標資料庫引擎是 Oracle，容量估算會更精確。對於其他 Amazon RDS 資料庫，引擎大小可能會因資料庫架構的差異而有所不同。

我們建議您在遷移 Oracle 資料庫之前執行效能測試。

先決條件和限制

先決條件

  • 下載 AWR 報告的 Oracle Database Enterprise Edition 授權和 Oracle Diagnostics Pack 授權。

產品版本

  • 11g 版 (11.2.0.3.v1 版及更新版本） 和最多 12.2 版和 18c，19c 版的所有 Oracle 資料庫版本。

  • 此模式不包含 Oracle Engineered Systems 或 Oracle Cloud Infrastructure (OCI)。

架構

來源技術堆疊

下列其中一項：

  • 內部部署 Oracle 資料庫

  • EC2 執行個體上的 Oracle 資料庫

  • Amazon RDS for Oracle 資料庫執行個體

目標技術堆疊

  • 任何 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 報告載入設定檔區段中的資訊。如果可用，請改用輸入/輸出設定檔區段，或跳至執行個體活動統計資料區段，並查看實體讀取和寫入操作的總值。

  • 當您估計 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
任務描述所需的技能

選擇方法。

IOPS 是儲存裝置上每秒輸入和輸出操作的標準測量，並包含讀取和寫入操作。 

如果您要將現場部署資料庫遷移至 AWS，您需要判斷資料庫使用的尖峰磁碟 I/O。您可以使用下列方法來估算目標資料庫的磁碟 I/O：

  • AWR 報告的載入設定檔區段

  • AWR 報告的執行個體活動統計資料區段 （針對 Oracle Database 12c 或更新版本使用此區段）

  • AWR 報告的 I/O 設定檔區段 （針對 12c 之前的 Oracle 資料庫版本使用此區段）

  • AWR 檢視

下列步驟說明這四種方法。

DBA

選項 1：使用負載描述檔。

下表顯示 AWR 報告的 Load Profile 區段範例。

重要

如需更準確的資訊，建議您使用選項 2 (I/O 設定檔） 或選項 3 （執行個體活動統計資料），而非負載設定檔。

 

每秒

每筆交易

每個執行

每次呼叫

資料庫時間 (s)：

26.6

0.2

0.00

0.02

資料庫 CPU (s)：

18.0

0.1

0.00

0.01

背景 CPU (s)：

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

 

 

即時訊息掃描資料列：

0.0

0.0

 

 

工作階段邏輯讀取即時通訊：

 

 

 

 

使用者呼叫：

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，因此您可以計算總輸送量，如下所示：

MB 的總輸送量為 17042.4 * 8 * 1024 / 1024 / 1024 = 133.2 MB

警告

請勿使用負載描述檔來估計執行個體大小。它不如執行個體活動統計資料或 I/O 設定檔精確。

DBA

選項 2：使用執行個體活動統計資料。

如果您使用的是 12c 之前的 Oracle 資料庫版本，則可以使用 AWR 報告的執行個體活動統計資料區段來估計 IOPS 和輸送量。下表顯示本節的範例。

統計數字

總計

每秒

每個交易

實體讀取總 IO 請求

2，547，333，217

3，610.28

25.11

實體讀取總位元組數

80，776，296，124，928

114，482，426.26

796，149.98

實體寫入總 IO 請求

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 區段，可在單一資料表中呈現所有資訊，並提供更準確的資料庫效能資料。下表顯示本節的範例。

 

每秒讀寫數

每秒讀取數

每秒寫入數

請求總數：

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 （從第五列，標記為總計，第二欄）

IOPS = 4，367.4 （從第一列，標記為請求總數，第二欄）

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 為基礎。(OS 統計資料也包含其他程序的 CPU 用量。) 您也應該檢查 ADDM 報告中與 CPU 相關的建議，以提升遷移後的效能。

您也可以根據 CPU 產生來估計需求。如果您使用的是不同的 CPU 世代，您可以依照白皮書中的指示來預估目標資料庫所需的 CPU，說明 vCPUs 數量，以獲得最佳工作負載效能。

DBA

選項 1：根據可用核心估算需求。

在 AWR 報告中：

  • CPUs 是指邏輯和虛擬 CPUs。 

  • 核心是實體 CPU 晶片組的處理器數量。 

  • 插槽是將晶片連接到電路板的實體裝置。多核心處理器具有多個 CPU 核心的通訊端。

您可以透過兩種方式預估可用的核心：

  • 使用作業系統命令

  • 使用 AWR 報告

使用作業系統命令來估計可用的核心

使用以下命令計算處理器中的核心。

$ 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 等作業系統命令來擷取 CPU 使用率。這是因為這些計算包含其他程序的 CPU 使用率，而且可能不會反映資料庫使用的實際 CPU。

使用 AWR 報告預估可用的核心

您也可以從 AWR 報告的第一個區段衍生 CPU 使用率。以下是報告中的摘錄。

資料庫名稱

資料庫 ID

執行個體

整數

啟動時間

發行版本

RAC

XXXX

<DB_ID>

XXXX

1

205-Sep-20 日 23：09

12.1.0.2.0

NO

Host Name (主機名稱)

平台

CPUs

核心

通訊端

記憶體 (GB)

<host_name>

Linux x86 64 位元

80

80

2

441.78

在此範例中，CPUs計數為 80，這表示這些是邏輯 （虛擬） CPUs。您也可以看到此組態有兩個通訊端，每個通訊端有一個實體處理器 （總共兩個實體處理器），以及每個實體處理器或通訊端有 40 個核心。 

DBA

選項 2：使用作業系統統計資料估計 CPU 使用率。

您可以直接在作業系統 （使用 sar 或其他主機作業系統公用程式） 中檢查作業系統 CPU 用量統計資料，也可以從 AWR 報告的作業系統統計資料區段檢閱 IDLE/(IDLE+BUSY) 值。您可以看到直接從 v$osstat 消耗的 CPU 秒數。AWR 和 Statspack 報告也會在作業系統統計資料區段中顯示此資料。

如果同一個方塊中有多個資料庫，則它們都有相同的 BUSY_TIME v$osstat 值。

統計數字

Value

結束值

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

 

VM_OUT_BYTES

327，680

 

PHYSICAL_MEMORY_BYTES

474，362，417，152

 

NUM_CPUS

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

快照時間

工作階段

游標/工作階段

開始 Snap：

184662

28-Sep-20 日 09：00：42

1226

35.8

結束快照：

185446

206-Oct-20 日 13：00：20

1876

41.1

已過：

 

11，759.64 （分鐘）

 

 

資料庫時間：

 

312，625.40 （分鐘）

 

 

若要取得 CPU 使用率指標，請使用此公式：

資料庫 CPU 用量 （可用 CPU 功率的百分比） = CPU 時間 / NUM_CPUS / 經過時間

其中 CPU 用量是以 CPU 時間描述，並代表在 CPU 上花費的時間，而不是等待 CPU 的時間。此計算會導致：

= 312，625.40 / 11，759.64/80 = 正在使用 33% 的 CPU

核心數量 (33%) * 80 = 26.4 個核心

總核心 = 26.4 * (120%) = 31.68 個核心

您可以使用這兩個值中的較大值來計算 Amazon RDS 或 Aurora 資料庫執行個體的 CPU 使用率。

注意

在 IBM AIX 上，計算的使用率與作業系統或資料庫的值不相符。這些值確實符合其他作業系統。

DBA
任務描述所需的技能

使用記憶體統計資料估計記憶體需求。

您可以使用 AWR 報告來計算來源資料庫的記憶體，並在目標資料庫中比對。您也應該檢查現有資料庫的效能，並減少記憶體需求以節省成本，或提高需求以改善效能。這需要詳細分析應用程式的 AWR 回應時間和服務層級協議 (SLA)。使用 Oracle 系統全域區域 (SGA) 和程式全域區域 (PGA) 用量的總和作為 Oracle 的估計記憶體使用率。為作業系統新增額外的 20%，以判斷目標記憶體大小需求。對於 Oracle RAC，請使用所有 RAC 節點的估計記憶體使用率總和，並降低總記憶體，因為它存放在一般區塊中。

  1. 檢查執行個體效率百分比表中的指標。資料表使用下列詞彙：

    • Buffer Hit % 是在緩衝快取中發現特定區塊而非執行實體 I/O 的次數百分比。為了獲得更好的效能，請將目標設為 100%。 

    • Buffer Nowait % 應接近 100%。

    • Latch Hit % 應接近 100%。 

    • 非稀疏 CPU % 是用於非剖析活動的 CPU 時間百分比。此值應接近 100%。

    執行個體效率百分比 （目標 100%)

    緩衝區 Nowait %：

    99.99

    Redo NoWait %：

    100.00

    緩衝區命中 %：

    99.84

    記憶體內排序 %：

    100.00

    Library Hit %：

    748.77

    Soft Parse %：

    99.81

    執行 以剖析 %：

    96.61

    Latch Hit %：

    100.00

    剖析 CPU 到剖析已重疊 %：

    72.73

    非稀疏 CPU %：

    99.21

    Flash Cache Hit %：

    0.00

     

     

    在此範例中，所有指標看起來都不錯，因此您可以將現有資料庫的 SGA 和 PGA 用作容量規劃需求。

  2. 檢查記憶體統計資料區段並計算 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
任務描述所需的技能

根據磁碟 I/O、CPU 和記憶體預估值判斷資料庫執行個體類型。

根據先前步驟中的預估，目標 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 部落格 postRight-size Amazon RDS 執行個體，根據 Oracle 效能指標進行擴展。

DBA

相關資源