ORA-04031报错中的sga heap(6,0)明确指向subpool 6和duration 0内存区，反映该子池内单次调用临时内存高频申请未释放；RAC中各节点独立管理，故问题具节点局部性；需结合alert日志、v$sga_dynamic_components及streams pool占用分析，优先调低_shared_pool_reserved_min_alloc并限制streams_pool_size，而非盲目增大shared_pool_size。
查清是哪个subpool和duration在告警
ORA-04031报错信息里带的sga heap(6,0)不是随便写的，它直接锁定问题子池和内存生命周期。其中括号内第一个数字（如6）是subpool编号，第二个（0）代表duration 0——即“单次调用期间临时分配”的内存，比如SQL硬解析、PL/SQL匿名块执行时申请的瞬时空间。RAC环境下各节点subpool独立管理，所以常见现象是节点1频繁报sga heap(6,0)，节点2完全正常。这说明问题不在全局配置，而在该节点上某个组件或会话持续向subpool 6的duration 0区域高频申请小块内存，又未及时释放。
验证方法：
- 直接从alert日志提取最近5条ORA-04031，确认sga heap(x,0)中的x是否固定（如全是6）；
- 查询v$sga_dynamic_components，确认shared pool当前实际大小是否被其他SGA组件挤压（如streams pool异常膨胀）；
- 若发现streams pool占用远超配置值（例如配置80GB却占到96GB），基本可判定是第三方同步工具导致Shared Pool内存被动态“猎夺”。
快速定位高硬解析源头
Library cache hit率低于85% + sga heap(x,0)反复报错，大概率是硬解析风暴。但不能只看AWR里的“硬解析次数”，要抓实时活跃源头：
- 运行
SELECT sql_id, parsing_schema_name, executions, loads, invalidations FROM v$sql WHERE loads > 50 AND invalidations > 10 ORDER BY loads DESC，重点看loads（加载次数）高的SQL——这些SQL每次执行都在重新进library cache，反复切分chunk； - 检查应用是否启用
cursor_sharing=force且未做充分测试，这种设置会让Oracle强行改写字面量SQL，生成大量child cursor，每个都占独立内存； - 排查ETL脚本或报表工具：是否用JDBC拼接含日期/ID的SQL（如
"SELECT * FROM t WHERE dt = '" + today + "'"），这类代码在RAC中会跨节点重复硬解析，迅速填满某一个subpool的duration 0区。
别急着调大shared_pool_size
盲目增大shared_pool_size可能让问题更隐蔽——内存变大后碎片更难被自动合并，duration 0区域反而更容易堆积无法回收的小块。真正该优先操作的是：
- 立即降低
_shared_pool_reserved_min_alloc隐含参数（如从默认4400降到4100），让原本被忽略的小于4400字节的分配请求也能走保留区，减少对主free list的冲击； - 给
shared_pool_reserved_size设硬下限，建议为shared_pool_size的10%，并确保它不被ASMM/AMM动态收回（在19c CDB中尤其要注意，streams pool可能抢占这部分预留空间）； - 若确认是
streams pool失控（如AWR显示其占用96GB），必须立刻执行ALTER SYSTEM SET streams_pool_size = 2G SCOPE=BOTH，否则Shared Pool永远在“抢地盘”中失血。
dump分析要避开高峰期
想看内存内部碎片分布，oradebug dump heapdump 536870914确实能输出LARGEST SUB HEAPS信息，但它会持有shared pool latch数秒甚至更久。在RAC中，这个操作如果发生在业务高峰，极易引发节点级hang——因为所有访问shared pool的进程都会排队等待latch，形成雪崩。
安全做法：
- 只在维护窗口执行，且提前在非问题节点验证命令响应时间；
- 用SELECT * FROM x$ksmsp WHERE ksmchcls = 'free'替代全量dump，查出free chunk的size分布（注意该视图查询本身也需shared pool latch，别在高峰期扫全表）；
- 更轻量的方式是查v$shared_pool_reserved：若REQUEST_FAILURES > 0且LAST_FAILURE_SIZE接近报错里的字节数（如4160），说明保留区门限已卡死，此时调低_shared_pool_reserved_min_alloc比dump更直接有效。
duration 0区域的问题从来不是“缺内存”，而是“内存不会呼吸”——它依赖调用结束自动释放，一旦有bug、泄漏或设计缺陷卡住释放路径，整个subpool就成了一潭死水。排查时盯着sga heap(x,0)和streams pool占用，比翻参数列表快得多。
