OS指标比DB Time更关键，因Oracle 23c向量化执行、IMC增强和并行日志压缩对硬件响应更敏感；FREE_MEMORY_BYTES持续下降、IOWAIT_TIME占比超5%、LOAD持续高于1.2倍CPU核数等均预示硬件瓶颈提前暴露。
直接看 Operating System Statistics 里的 FREE_MEMORY_BYTES、IOWAIT_TIME 和 LOAD，别先翻 SQL 或等待事件——23c 对内存带宽、IO 吞吐和 NUMA 调度更敏感，硬件瓶颈在 AWR 里会提前“露底”。
为什么 OS 指标比 DB Time 更关键？
Oracle 23c 引入了更多向量化执行、内存中列式扫描（In-Memory Column Store 增强）和并行日志压缩，这些特性对底层硬件的响应曲线更陡峭。即使 DB Time 正常、AAS FREE_MEMORY_BYTES 在快照窗口内单向下跌 >5GB 且 INACTIVE_MEMORY_BYTES 未同步上升，就说明内存压力已在挤压大页分配，23c 的 IMC 加载或 PQ 分配可能失败。
-
IOWAIT_TIME占BUSY_TIME比例 >5% → 23c 的实时归档（Real-Time Apply）和在线重定义（Online Redefinition）会卡顿，不是磁盘慢，是 IO 调度器无法满足 23c 新增的预读/写合并策略 -
LOAD持续 >NUM_CPU_CORES× 1.2（比如 56 核系统 LOAD > 67），但USER_TIME占比反降 → 内核态锁争用加剧，23c 的新调度器（如_kcfis_scheduler）可能因 NUMA node 不均衡触发频繁跨节点迁移 -
TCP_RECEIVE_SIZE_MAX≠GLOBAL_RECEIVE_SIZE_MAX（尤其 RAC 环境）→ 23c 的 Fast Application Notification（FAN）心跳包会被截断，导致实例误判为故障并触发不必要的 rejoin
怎么交叉验证 CPU 是否真够用？
23c 默认启用 _px_use_large_pool 和更强的并行自适应算法，CPU 利用模式已变。不能只看 DB CPU 总值，必须拆到实例+时段粒度：
- 用
awrrpti.sql生成 per-instance 报告，对比各节点DB CPU/CPU_COUNT比率：23c 下若某节点该比率 > 0.85 且持续 5 分钟以上，大概率是enq: PS - contention（并行服务器池争用），而非物理 CPU 不足 - 查
V$OSSTAT中NUM_CPUS_ONLINE是否等于NUM_CPUS：23c 启动时若检测到超线程关闭（HT off），会主动禁用部分并行通道，但 AWR 不报错，只体现为Parallel Operations Downgraded次数突增 -
SQL ordered by CPU Time里前 3 名若含VECTOR或IMC关键字，且Elapsed Time per Exec>CPU Time per Exec× 2 → 说明向量化执行被降级为标量，根源常是 L3 cache miss 率高（需结合 OSperf stat验证，AWR 不提供）
哪些 AWR 指标在 23c 升级前必须 baseline？
不是所有指标都适合作为升级前后的比对基准。以下 4 项在 19c 运行稳定期采集后，23c 上线首周必须重测：
-
Physical Reads Direct Per Sec（Load Profile）：23c 默认启用_direct_read_decision_statistics_enabled=TRUE，若该值在 19c 是 1200，升级后掉到 300 且db file sequential read等待飙升，说明自动直读决策误判，需手动设ALTER SYSTEM SET "_direct_read_decision_statistics_enabled"=FALSE -
Redo Generated Per Sec：23c 的压缩日志写入（LOG_ARCHIVE_COMPRESSION）会降低该值，但若下降 >40% 且log file sync平均等待反而 +15%，说明 LGWR 线程被压缩任务阻塞，需调大_lgwr_async_io_max -
Global Cache Blocks Received Per Second（RAC）：23c 的 GC 优化依赖GLOBAL_RECEIVE_SIZE_MAX≥ 8MB，若该值在 19c 是 1800，23c 却跌到 900 且gc cr block busy上升，基本锁定网络缓冲区配置未更新 -
PGA Memory Allocated（Instance Efficiency）：23c 的自适应 PGA 管理更激进，若该值在 19c 是 12GB，升级后跳到 28GB 且PGA Cache Hit %_smm_advice_enabled 是否被意外关闭
真正难的是 FREE_MEMORY_BYTES 和 INACTIVE_MEMORY_BYTES 的趋势交叉——它们不报警，不报错，但 23c 启动后若这两项在 15 分钟快照内同步缓慢爬升（非业务驱动），八成是 MEMORY_TARGET 设置过高，触发了 23c 新增的 memory_guard 机制，在后台默默回收大页，表面平静，实则扼杀了向量化执行的内存亲和性。
