Oracle 12c RAC的GI进程内存超1GB主因是ASM实例默认硬编码memory_target=1G，且GIMR（MGMTDB）自身占用约800MB+；需通过隐藏参数\_asm\_allow\_small\_memory\_target解锁后方可安全下调ASM内存，并同步管控GIMR数据保留与健康监控。
为什么Oracle 12c RAC的GI进程总吃掉1GB以上内存
因为asm实例默认启用了memory_target=1g，且这个值在12c中是硬编码级的默认行为——哪怕你手动设成500m，重启后也会自动回滚到1gb。这不是配置遗漏，而是oracle在12.1.0.2之后对grid infrastructure的资源模型做了强制升级：asm不再只是磁盘管理器，它要承载gimr（mgmtdb）和cluster health monitor等后台服务，必须预留足够内存缓冲。
如何安全降低ASM instance的memory_target
直接改memory_target没用，必须配合隐藏参数解锁限制：
- 以
/ as sysasm身份连接ASM实例：sqlplus / as sysasm - 执行：
alter system set "_asm_allow_small_memory_target"=true scope=spfile; - 再设置目标值：
alter system set memory_target=512M scope=spfile; - 重启ASM实例（
crsctl stop asm -f && crsctl start asm）
注意：_asm_allow_small_memory_target只在12.1.0.2+生效，且仅影响ASM实例，不影响数据库实例的sga_target。
GIMR（MGMTDB）才是真正的内存大户
很多人以为调小ASM内存就完事了，但ps -ef | grep -i mgmtdb常显示一个独立的Oracle进程，RSS动辄800MB+。这是因为GIMR是完整CDB+PDB结构，自带SGA和PGA，且默认保留3天监控数据，每天增长约700MB。
可选动作：
- 停用Cluster Health Monitor（仅限测试环境）：
crsctl stop res ora.crf -init，能释放300–500MB - 缩短GIMR数据保留期：
$CRS_HOME/bin/oclumon manage -repos checkretentiontime 172800（设为2天） - 生产环境不建议删除MGMTDB，但可确认它是否真的被EM或诊断工具依赖
调整后必须验证的三个点
改完别急着庆祝，这几个地方一错全白干：
-
crsctl stat res -t里所有GI资源状态必须是ONLINE，特别是ora.asm和ora.mgmtdb - 检查
v$asm_client是否仍能正常列出数据库实例，否则数据库无法挂载磁盘组 - 运行
asmcmd lsdg确认磁盘组在线且USABLE_FILE_MB无异常突降——过小的memory_target会导致ASM元数据缓存不足，引发IO抖动
最易忽略的是：GI内存下调后，如果后续升级补丁或打PSU，某些版本会重置_asm_allow_small_memory_target为false，导致ASM启动失败。每次维护后务必复查该参数值。
