使用 AWR 报告估计 Oracle 数据库的 Amazon RDS 引擎大小 - AWS Prescriptive Guidance
Summary先决条件和限制架构工具最佳实践操作说明相关的资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用 AWR 报告估计 Oracle 数据库的 Amazon RDS 引擎大小

由 Abhishek Verma (AWS) 和 Eduardo Valentim (AWS) 编写

环境：生产

源：Oracle 数据库

目标： Amazon RDS 或 Amazon Aurora

R 类型：重构

工作负载：Oracle

技术：数据库；迁移

Amazon Web Services：Amazon RDS；Amazon Aurora

Summary

当您将 Oracle 数据库迁移至 Amazon Relational Database Service (Amazon RDS) 或 Amazon Aurora 时，计算目标数据库的 CPU、内存和磁盘 I/O 是一项关键要求。您可以通过分析 Oracle Oracle Automatic Workload Repository (AWR) 报告来估计目标数据库所需的容量。此模式说明了如何使用 AWR 报告估计这些值。

源 Oracle 数据库可以位于本地或托管在 Amazon Elastic Compute Cloud （Amazon EC2） 实例上，也可以是 Amazon RDS for Oracle 数据库实例。目标数据库可是任何 Amazon RDS 或 Aurora 数据库。

注意： 如果您的目标数据库引擎是 Oracle，则容量估计会更加精确。对于其他 Amazon RDS 数据库，由于数据库架构差异，引擎大小可能会有所不同。

我们建议您在迁移 Oracle 数据库前进行性能测试。

先决条件和限制

先决条件

  • Oracle Database Enterprise Edition 许可证和 Oracle Diagnostics Pack 许可证，用于下载 AWR 报告。

产品版本

  • 版本 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 Automatic Workload Repository (AWR)是一个内置在 Oracle 数据库中的存储库。它定期收集和存储系统活动和工作负载数据，然后由 Automatic Database Diagnostic Monitor (ADDM) 对其进行分析。AWR 定期拍摄系统性能数据的快照 (默认情况下，每 60 分钟一次) 并存储信息 (默认情况下，最多 8 天)。 您可使用 AWR 视图和报告来分析这些数据。

最佳实践

  • 若要计算目标数据库的资源要求，您可以使用单个 AWR 报告、多个 AWR 报告或动态 AWR 视图。我们建议您在高峰负载期间使用多个 AWR 报告估算处理这些峰值负载所需的资源。此外，动态视图提供更多数据点，帮助您更准确地计算资源需求。 

  • 您应该仅估算计划迁移的数据库的 IOPS，而不是使用该磁盘的其他数据库和进程的 IOPS。

  • 要计算数据库使用了多少 I/O，请不要使用 AWR 报告的负载配置文件部分中的信息。请改用“I/O 配置文件”部分（如果可用），或者跳至“实例活动统计信息”部分并查看物理读写操作的总值。

  • 当您估计 CPU 利用率时，我们建议您使用数据库指标方法而不是操作系统 (OS) 统计信息，因为它仅基于数据库使用的 CPU。（操作系统统计信息还包含其他进程的 CPU 使用率。） 您还应查看 ADDM 报告中与 CPU 相关的建议，以提高迁移后的性能。

  • 在确定正确的实例类型时，请考虑特定实例大小的 I/O 吞吐量限制（Amazon Elastic Block Store (Amazon EBS) 吞吐量和网络吞吐量）。

  • 迁移前运行性能测试，以验证引擎大小。

操作说明

任务描述所需技能

启用 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 是存储设备上每秒输入和输出操作的标准衡量标准，包括读取和写入操作。 

如果您要将本地数据库迁移至 AWS，则需要确定数据库使用的磁盘 I/O 峰值。 您可以使用以下方法来估计目标数据库的磁盘 I/O：

  • AWR 报告的加载配置文件部分

  • AWR 报告的实例活动统计信息部分 (使用此部分获取 Oracle Database 12c 或更高版本)

  • AWR 报告的 I/O 配置文件部分 (使用此部分获得 12c 之前的 Oracle 数据库版本)

  • AWR 视图

以下步骤介绍了这四种方法。

数据库管理员

选项 1：使用负载配置文件。

下表显示了 AWR 报告的负载配置文件部分的示例。

重要提示：要获得更准确的信息，我们建议您使用选项 2 (I/O 配置文件) 或选项 3 (实例活动统计信息) 来代替负载配置文件。

 

(每秒)

每笔交易

每位高管

每次通话

数据库时间 (秒)：

26.6

0.2

0.00

0.02

数据库 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，因此您可按如下方式计算总吞吐量：

以 MB 为单位的总吞吐量是 17042.4 * 8 * 1024/1024/1024 = 133.2 MB

警告： 请勿使用负载配置文件来估算实例大小。它不如实例活动统计数据或 I/O 配置文件精确。

数据库管理员

选项 2：使用实例活动统计信息。

如果您使用的是 12c 之前的 Oracle 数据库，则可使用 AWR 报告的实例活动统计信息部分来估计 IOPS 和吞吐量。下表显示了本部分的示例。

Statistic

总计

(每秒)

每次传输

物理读取总数 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

数据库管理员

选项 3：使用 I/O 配置文件。

在 Oracle Database 12c，AWR 报告包括一个 I/O 配置文件部分，该部分在单个表中显示所有信息，并提供有关数据库性能的更准确的数据。下表显示了本部分的示例。

 

每秒读取+写入次数

每秒读取次数

每秒写入次数

请求总数：

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(从标有总计的第一行、第二列开始)

数据库管理员

选项 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：

  • 通过处理器的实际可用内核

  • 通过基于操作系统统计信息的已用内核

  • 通过基于数据库统计信息的已用内核

如果您要查看已使用的内核数，我们建议您使用数据库指标方法而不是操作系统统计信息，因为它仅基于您计划迁移的数据库使用的 CPU。（操作系统统计信息还包含其他进程的 CPU 使用率。） 您还应查看 ADDM 报告中与 CPU 相关的建议，以提高迁移后的性能。

您还可根据 CPU 生成估算需求。如果您使用不同的 CPU 代，则可以按照白皮书揭秘 vCPU 数量以实现最佳工作负载性能》中的说明来估计目标数据库所需的 CPU。

数据库管理员

选项 1：根据可用内核估算需求。

在 AWR 报告：

  • CPU 是指逻辑与虚拟 CPU。 

  • 内核是物理 CPU 芯片组的处理器数量。 

  • 插槽是一种将芯片连接至主板的物理设备。多核处理器的插槽带多个 CPU 内核。

您可通过两种方式估算可用内核：

  • 通过使用 OS 命令

  • 通过使用 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

05-Sep-20 23：09

12.1.0.2.0

否

主机名称

平台

CPU

内核

套接字

内存 (GB)

<host_name>

Linux x86 64 位

80

80

2

441.78

在此示例中，CPU 数量为 80，这表明它们是逻辑（虚拟）CPU。您还可以看到，此配置有两个插槽，每个插槽上有一个物理处理器（总共两个物理处理器），每个物理处理器或插槽有 40 个内核。 

数据库管理员

选项 2：使用操作系统统计信息估计 CPU 使用率。

您可以直接在操作系统中查看操作系统 CPU 使用率统计信息(使用 sar 或其他主机操作系统实用程序)，也可以通过查看 AWR 报告的操作系统统计信息部分中的 IDLE/(IDLE+BUSY)值来查看操作系统 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

 

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% 利用率

数据库管理员

选项 3：使用数据库指标估算 CPU 利用率。

如果系统中运行多个数据库，您可以使用报告开头显示的数据库指标。

 

快照 ID

快照时间

会话

光标/会话

开始快照：

184662

2020 年 9 月 28 日 09:00:42

1226

35.8

结束快照：

185446

2020 年 10 月 06 日 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，计算出的利用率与操作系统或数据库中的值不匹配。这些值在其他操作系统确实匹配。

数据库管理员
任务描述所需技能

通过内存统计数据估算内存需求。

您可以使用 AWR 报告计算源数据库的内存并在目标数据库中进行匹配。您还应该检查现有数据库的性能并减少内存需求以节省成本，或增加内存需求以提高性能。这需要对 AWR 响应时间和应用程序的服务水平协议（SLA）进行详细分析。使用 Oracle 系统全局区域 (SGA) 和程序全局区域 (PGA) 使用率之和作为 Oracle 的估计内存利用率。为操作系统额外添加 20%，以确定目标内存大小要求。对于 Oracle RAC，使用所有 RAC 节点上的估计内存利用率的总和并减少总内存，因为它存储在公共块上。

  1. 检查“实例效率百分比”表中的指标。表格使用以下术语：

    • 缓冲区命中百分比是在缓冲区高速缓存中发现特定块而不是执行物理 I/O 的次数百分比。为了提高性能，请以 100% 为目标。 

    • 缓冲区 Nowait%应接近 100%。

    • 锁定命中百分比 应接近 100%。 

    • % 非解析 CPU是在非解析活动中花费的 CPU 时间的百分比。此值应该接近 100%。

    实例效率百分比 (目标 100%)

    缓冲区 Nowait %：

    99.99

    重做 NoWait %：

    100.00

    缓冲区命中率 %：

    99.84

    内存中排序 %：

    100.00

    库命中 %：

    748.77

    软解析 %：

    99.81

    执行到解析 %：

    96.61

    锁定命中 %：

    100.00

    解析 CPU 到解析已用时间 %：

    72.73

    % 非解析 CPU：

    99.21

    闪存缓存命中 %：

    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 是根据预定义的公式进行预先计算的。确保预先计算的值接近您的估值。

数据库管理员
任务描述所需技能

根据磁盘 I/O、CPU 和内存估计确定数据库实例类型。

根据前面步骤中的估算，目标 Amazon RDS 或 Aurora 数据库的容量应为：

  • 68 个 CPU 内核

  • 143 MBPS 吞吐量  

  • 磁盘 I/O 的 4367 IOPS

  • 464 GB 的内存

在目标 Amazon RDS 或 Aurora 数据库中，您可将这些值映射到 db.r5.16xlarge 实例类型，该实例类型的容量为 32 个内核、512 GB 的 RAM 和 13,600 Mbps 的吞吐量。有关更多信息，请参阅 AWS Blog 文章基于 Oracle 性能指标大规模调整 Amazon RDS 实例大小。

数据库管理员

相关的资源