AWR中计算CPU和IOPS历史峰值应查DBA_HIST_SYSMETRIC_HISTORY、DBA_HIST_SNAPSHOT、DBA_HIST_SYSSTAT三张表，重点关注'CPU Usage Per Sec'等瞬时速率指标，用MAX(value)聚合近90天有效快照，并结合OS层CPU及云平台Host CPU视图交叉验证。
AWR里哪几张表能直接算出CPU和IOPS历史峰值
关键不是看平均值，而是找过去30–90天里真实压到硬件极限的那几个小时。oracle awr 把负载拆得很细，但真正能反推硬件需求的只有三张表：dba_hist_sysmetric_history（每5分钟采样）、dba_hist_snapshot（快照时间锚点）、dba_hist_sysstat（累计计数器）。别去碰 dba_hist_system_event，它反映的是等待，不是消耗。
实操建议：
-
DBA_HIST_SYSMETRIC_HISTORY中重点关注metric_name IN ('CPU Usage Per Sec', 'Physical Reads Per Sec', 'Physical Writes Per Sec')，这些是带单位的瞬时速率，可直接对标新硬件标称值 - 用
MAX(value)聚合时，必须配合WHERE snap_id IN (SELECT snap_id FROM DBA_HIST_SNAPSHOT WHERE begin_interval_time > SYSDATE - 90)，否则默认只查最近7天 - 注意单位：CPU 是
centi-seconds/sec，即每秒消耗的 CPU 百分之一秒；IOPS 是reads/writes per second，但物理读写含 direct path 和 buffer cache miss，实际磁盘 IOPS 通常比这个低15–25%
怎么把AWR里的“每秒读”换算成SSD/HDD真实IOPS需求
AWR 给的 Physical Reads Per Sec 是数据库视角，不是存储层视角。一块 SATA SSD 标称 80K IOPS，不代表你能把 AWR 里看到的 60K 直接往上套——中间有重做、归档、备份、RAID条带、文件系统缓存等多层损耗。
实操建议：
- 先过滤掉夜间备份窗口：用
WHERE TO_CHAR(begin_interval_time, 'HH24') NOT BETWEEN '02' AND '05'排除归档/备份干扰 - 对 OLTP 类型，按
Physical Reads Per Sec × 1.3估算后端磁盘 IOPS（含 redo write + block cleanout）；对 DSS/报表类，乘 1.8 更稳妥 - 如果用了 ASM 或 Oracle ACFS，再额外加 8–12% 的元数据 IO 开销，这部分在 AWR 里不显式体现
- 别信“平均 IOPS × 2 = 峰值”，真实业务高峰常有 3–5 倍于日均的尖峰，必须取单个
snap_id下的原始value最大值，不是滚动平均
用awrddrpt.sql对比升级前后负载时，哪些指标不能直接比
awrddrpt.sql 生成的差分报告看着很全，但里面很多字段是“不可比”的——因为计算口径变了，或者根本没归一化。比如 DB Time 看似直观，但升级后如果用了 In-Memory 或结果集缓存，DB Time 会下降，不代表 CPU 真的省了，只是工作被挪到内存或客户端了。
实操建议：
- 只信任差分报告里的
CPU Usage Per Sec、Physical Reads/Writes Per Sec、Redo Generated Per Sec这三项，它们是底层硬件直连指标 - 避开
Logical Reads Per Sec：Buffer Cache 大小一变，这数字就失真；也别看Parse Count (hard)，硬解析下降可能只是用了 bind variable，和 CPU 升级无关 - 如果对比的是不同版本（比如 12c → 19c），记得加
SET LINESIZE 200再跑脚本，否则 19c 新增的IO Requests字段会被截断，导致你漏看关键 IOPS 拆分
为什么用AWR算出来的CPU需求，上云后还是经常超限
AWR 记录的是 Oracle 进程消耗的 CPU 时间，但云平台（如 AWS RDS、OCI DB System）的 vCPU 是调度单元，不是物理核。一个 DB CPU 高峰 85%，在本地可能是 16 核跑满，在云上可能对应 4 个 vCPU 被频繁抢占，尤其当实例共享物理资源时。
实操建议：
- 查 AWR 时同步抓
DBA_HIST_OSSTAT里的BUSY_TIME和IDLE_TIME，算出 OS 层 CPU 利用率，和 AWR 的CPU Usage Per Sec做交叉验证；两者偏差 >20%，说明有严重非 Oracle 进程干扰（比如监控 agent、logrotate） - 云环境必须补一手：用
SELECT value/100 FROM V$SYSMETRIC WHERE metric_name = 'Host CPU Utilization (%)'，这是 Oracle 主动采集的宿主机视图，比 AWR 更贴近云厂商的计量逻辑 - 别忽略 CPU steal time：在
DBA_HIST_OSSTAT里找VM_WAIT_TIME，大于 5% 就得跟云厂商确认是否底层过载，这时候加 vCPU 只会让争抢更严重
AWR 是好工具，但它只告诉你“过去发生了什么”，不承诺“未来一定这样”。最常被跳过的一步，是没把应用层连接池配置、批量作业调度窗口、以及归档日志传输延迟这些外部变量，映射回 AWR 的 snapshot_id 时间戳上——差15分钟，可能就把一次真实的 IOPS 尖峰归到了错误的业务模块下。
