ASM实例必须设为instance_type=asm，否则sqlplus / as sysasm会报ORA-01031；需用spfile启动、独立Grid Infrastructure安装、合理配置asm_power_limit与failgroup物理隔离，并分离OCR与DATA磁盘组。
ASM实例必须设为 instance_type=asm
不是加了asm相关参数就能跑asm——oracle只认instance_type这个开关。如果误设为rdbms或留空，sqlplus / as sysasm会直接报错ora-01031: insufficient privileges，连登录都进不去。
检查方式很简单：show parameter instance_type。RAC每个节点上的ASM实例都必须单独确认，不能只在节点1配好就默认节点2也生效。
- 必须用
spfile启动，否则asm_diskgroups等动态参数修改后不持久 -
db_unique_name建议显式设为+ASM1、+ASM2，避免RAC中多个ASM实例名字冲突 - 不要复用数据库实例的
ORACLE_HOME——ASM实例需独立安装Grid Infrastructure，路径通常为/u01/app/19.0.0/grid
asm_power_limit调高≠更快，要看I/O队列深度
asm_power_limit默认是1，设成11确实能加速磁盘组再平衡（rebalance），但实际效果取决于底层存储的并发能力。在SAN环境里，值设太高反而引发I/O争用，v$asm_operation里能看到操作卡在ESTIMATED_FINISH_TIME迟迟不动。
更稳妥的做法是分场景调整：
- 日常维护（如加盘）：设为3～5，平衡速度与业务I/O影响
- 紧急故障恢复（如掉盘后重建）：临时提至7～9，完成后立刻降回
- OLTP核心库所在磁盘组：永远别碰11，哪怕再平衡慢点也比拖垮事务强
注意：alter diskgroup ... rebalance power N只能对正在运行的操作生效，对未开始的rebalance无效——得先alter diskgroup ... rebalance触发，再改power。
磁盘组冗余选normal还是high？看failgroup物理隔离度
normal redundancy要求至少两个failgroup，high要三个。但很多人忽略一点：failgroup不是靠名字区分的，而是靠磁盘物理归属。如果所有磁盘都挂在同一台SAN控制器下，即使写了FAILGROUP FG1 DISK 'LUN1'和FAILGROUP FG2 DISK 'LUN2'，故障时仍会集体失效。
真实部署中判断依据只有两个：
- 共享存储是否跨控制器（如双活SAN的两个SP）
- 本地多路径是否真正绑定到不同HBA卡和交换机路径
没做到物理隔离时，强行配normal反而制造虚假安全感；真有跨站点容灾需求，high也救不了网络分区——这时候该上Extended RAC+ASM Flex Disk Group，而不是硬调冗余级别。
OCR不能和DATA磁盘组混放，compatible.asm必须对齐
OCR文件写入磁盘组前，必须确保该磁盘组的compatible.asm属性 ≥ 集群软件版本。比如19c Grid Infrastructure要求至少'19.0'，若用create diskgroup ocr external redundancy disk '/dev/sdc' attribute 'compatible.asm'='12.1'，后续ocrconfig -replace会失败并报ORA-15032: not all alterations performed。
更隐蔽的坑是OCR和DATA共用磁盘组：OCR元数据更新频繁，和数据库大块顺序读写抢I/O，v$asm_disk_iostat里read_time和write_time会同时飙升。正确做法是单独划一个小型磁盘组（2～4块SSD），仅放OCR/Voting Disk，并设compatible.asm='19.0'、compatible.rdbms='19.0'严格对齐。
最后提醒一句：ASM不是黑盒，asmcmd lsct看连接状态、asmcmd lsdg查磁盘组容量、select * from v$asm_disk盯磁盘在线情况——这些命令得成为日常巡检动作，而不是等ORA-15040报出来才翻文档。
