客户的一套Oracle RAC双机的其中一个节点（节点1）从1月份开始，每隔一个星期就会挂死，挂死时系统运行非常缓慢，执行任何命令都要等待很长时间或者无法结束。
于是，在系统上部署nmon性能数据和lockstat锁数据收集脚本，抓取故障发生时的性能数据和内核锁数据。
1. 系统bug
故障再次发生后，查看nmon收集的性能数据，系统的sys cpu使用率在故障发生时出现异常，由平时的3%左右飙升至15%以上。
查看系统的锁数据，发现内核中有大量超时的spt_anon_getpages锁：
查询MOS，文档2024133.1有关于Oracle启用DISM后触发的系统bug 15858248，bug的解决方法：
Solaris 10: 升级内核补丁150400-29以上
Solaris 11: 升级到版本Solaris 11.2 SRU 13.6以上
替代方法：使用OSM或ISM（取消初始化参数中的SGA_MAX_SIZE设置）
遗留疑问：RAC的两个节点都启用了DISM，但是目前故障只发生在其中一个节点上，不明确是什么条件触发了bug一直在同一个节点发生。
2. 触发数据库启用DISM（Dynamic Intimate Shared Memory）的条件
默认情况下，数据库安装时不会设置SGA_MAX_SIZE值，因此它会取与SGA_TARGET相同的值。只是设置SGA_TARGET参数不会使用DISM。
设置SGA_MAX_SIZE值大于SGA_TARGET或SGA_MAX_SIZE大于SGA所有组件的总和时会启用DISM来替代ISM（在11g中，如果设置了MEMORY_TARGET或MEMORY_MAX_TARGET参数时也会启用DISM）。配置了AMM（Automatic Memory Management）会导致Solaris使用DISM。使用DISM可以动态调整SGA组件的大小。
另外，在Solaris中，启用DISM后数据库会锁定大量的SWAP空间，SWAP空间至少要如SGA_MAX_SIZE值设置一样的大小。
启用DISM后，在系统中可以看到dism的相关进程：
$ ps -aef |grep dism
root 1879 1 0 Feb 08 ? 0:00 ora_dism_@
root 2311 1 0 Feb 08 ? 0:00 ora_dism_+ASM1
root 2393 1 0 Feb 08 ? 0:00 ora_dism_+ASM1
root 2342 1 0 Feb 08 ? 0:06 ora_dism_+ASM1
root 10632 1 0 16:05:08 ? 0:00 ora_dism_orcl1
oradb 29350 27468 0 16:33:34 pts/1 0:00 grep dism
root 10152 1 0 16:04:32 ? 0:08 ora_dism_orcl1
查看某个Oracle进程的信息，也可以看到dism相关的内存段：
3. Solaris系统中数据库是否使用DISM的建议
4. 参考文档
Doc ID 2024133.1 System Unresponsive - High Load / RunQueue and Large Percent System and DISM
Doc ID 1472108.1 ISM or DISM Misconfiguration can Slow Down Oracle Database Performance
Doc ID 1010818.1 Solaris[TM] Operating System: DISM double allocation of memory