ash缓冲区大小由隐含参数\_ash\_size控制，实例启动时确定且不可动态修改；实际容量取决于sga大小、活动会话数及诊断特性启用情况，可通过v$ash_info和v$ash_buffer_info查看使用水位。
ASH缓冲区大小由隐含参数 _ash_size 控制，不能直接修改
Oracle没有提供公开的、可ALTER SYSTEM SET的参数来调整ASH环形缓冲区大小。它的内存分配完全由底层SGA管理机制自动决定，且受隐含参数 _ash_size 控制——该参数只在实例启动时读取，运行中不可动态修改。试图用 ALTER SYSTEM SET "_ash_size" = ... 会报错 ORA-02095（指定的初始化参数不可修改）。
实际生效的ASH缓冲区容量，取决于：
– 实例启动时SGA总大小与各组件竞争情况
– 当前数据库活动会话数和采样密度（每秒1次）
– 是否启用了额外诊断特性（如SQL Monitoring、Real-Time SQL Monitoring）
查看当前ASH缓冲区配置和使用水位
必须用DBA权限执行以下查询，确认真实占用和上限：
SELECT * FROM V$ASH_INFO;
重点关注三列：
– ASH_BUFFERS：当前分配的槽位总数（即最大可存多少条采样）
– ASH_BUFFER_SIZE：以字节为单位的实际内存占用
– ASH_MAX_BUFFER_SIZE：理论最大允许值（通常等于SGA中预留的上限）
再查实时使用压力：
SELECT * FROM V$ASH_BUFFER_INFO;
若 CURRENT_SIZE 接近 MAX_SIZE，说明缓冲区已高频循环覆盖，老数据保留时间变短——这不是配置问题，而是高并发或长等待链导致的自然现象。
间接影响ASH缓冲区可用空间的可行操作
虽然不能调 _ash_size，但可通过调整SGA相关显式参数，为ASH腾出更多内存空间：
- 增大
SGA_TARGET或MEMORY_TARGET（需重启），让Oracle有更大SGA池供内部调度 - 适当调小
SHARED_POOL_SIZE（尤其当共享池存在大量未老化SQL时），避免其过度抢占SGA - 检查是否有大量未绑定变量的硬解析，减少共享池碎片，间接释放SGA弹性空间
- 禁用非必要诊断特性：
ALTER SYSTEM SET "_sqlmon_max_plan" = 0;可降低实时监控对ASH相关结构的干扰
注意：_ash_size 的默认计算逻辑是 SGA_SIZE × 0.05 左右，但Oracle从不承诺固定比例，且19c+版本更倾向动态自适应分配。
为什么不要强行“扩大ASH”？
ASH设计本就是环形缓冲+高频覆盖，目标是“最近60分钟内尽可能细粒度”，不是“保留越久越好”。盲目增大它会带来真实代价：
- SGA中固定占用更多内存，挤压
DB_CACHE_SIZE或SHARED_POOL_SIZE，可能引发物理读上升或频繁硬解析 - 每秒1次采样已是轻量级，但缓冲区过大时，MMNL进程刷盘到
DBA_HIST_ACTIVE_SESS_HISTORY的开销会上升 - AWR快照本身只每小时聚合一次ASH数据，更细的原始采样对长期趋势分析意义有限
真正需要延长历史覆盖时间，应该靠增加AWR快照频率（DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS）或延长AWR保留期，而不是动ASH缓冲区。
