AWR不直接评估加内存收益，需先确认内存瓶颈：若DB Time中buffer busy waits或read by other session占比超15%、PGA溢出严重、shared pool碎片化或sga_target/pga_aggregate_limit配比失衡，加内存才可能见效。
AWR本身不直接评估“加内存能改善多少”，它只反映当前内存配置下的实际表现。想预估加内存效果，得先确认瓶颈真在内存上，而不是误判。
查DB Time里有多少被buffer busy waits或read by other session吃掉
如果DB Time中超过15%被这两类等待占用，说明buffer cache可能太小，物理读频繁，加内存才可能见效。用以下SQL快速定位：
SELECT event, time_waited_micro/1000000 AS sec, ROUND(time_waited_micro*100/SUM(time_waited_micro) OVER(), 2) pct
FROM dba_hist_system_event e
JOIN dba_hist_snapshot s ON e.snap_id = s.snap_id AND e.dbid = s.dbid
WHERE s.begin_interval_time > SYSDATE - 1
AND e.event IN ('buffer busy waits', 'read by other session')
ORDER BY time_waited_micro DESC;
注意：单看db block gets或physical reads绝对值没意义——要结合buffer cache hit ratio和业务负载变化趋势看。比如某次AWR报告显示physical reads从每秒200涨到800，但cache hit ratio仍稳定在99.2%，那大概率不是内存不够，而是SQL扫了更多数据。
对比两个AWR周期的PGA Aggr Target使用率和workarea executions
如果PGA Aggr Target长期超限（PGA memory freed非零、workarea executions - optimal占比超5%），说明排序/哈希操作频繁溢出到磁盘，加内存对这类SQL才有明显收益。重点关注：
-
V$PGASTAT里的over allocation count是否持续增长 -
DBA_HIST_PGASTAT中bytes processed与extra bytes read/written的比值——比值越接近1，说明溢出越严重 -
DBA_HIST_SQLSTAT里io_cell_offload_eligible_bytes为0但disk_reads很高的SQL，可能是PGA不足导致无法启用存储层加速
别跳过Shared Pool碎片和library cache pin等待
很多DBA一看到慢就加SGA_TARGET，结果发现shared pool里大量free memory被切成小块，library cache pin等待飙升。这时候加内存反而加剧碎片。检查方法：
SELECT pool, name, bytes/1024/1024 mb FROM v$sgastat WHERE name LIKE '%free memory%' AND pool = 'shared pool';
如果单块free memory小于1MB且总和超过200MB，说明碎片严重。此时应优先调整shared_pool_reserved_size或用ALTER SYSTEM FLUSH SHARED_POOL（仅限维护窗口），而不是盲目扩容。
真正决定加内存效果的是sga_target和pga_aggregate_limit的配比
Oracle 12c+默认开启automatic memory management，但sga_target和pga_aggregate_limit的初始值常不合理。比如一台64GB内存的服务器，sga_target设成40GB，pga_aggregate_limit却只有2GB，结果并行查询全挤在SGA里争抢，pga_aggregate_target形同虚设。正确做法是：
- 先用
DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT导出两份高负载时段的AWR报告，对比Memory Statistics页里SGA size和PGA size的实际峰值 - 确保
pga_aggregate_limit≥ 1.5 × 实测PGA峰值，否则自动内存管理会强制收缩PGA，触发大量direct path read/write -
sga_target不要超过物理内存的60%，留足OS缓存和hugepages预留空间，否则vm.swappiness=1也救不了频繁swap
加内存后最易被忽略的点：没调memory_max_target。这个参数必须在重启前设好，否则实例启动时会把新加的内存当无效配置丢弃——AWR里SGA size还是老样子，但v$memory_dynamic_components里会显示current_size卡在旧值不动。
