Oracle报错|磁盘组修复 ORA-15237:attribute string cannot be set in CREATE DISKGROUP 故障远程处理

Oracle报错|磁盘组修复 ORA-15237: attribute string cannot be set in CREATE DISKGROUP 故障远程处理

深夜告警：突如其来的ORA-15237

老王揉了揉发酸的眼睛,凌晨2点的机房灯光格外刺眼，监控大屏上醒目的红色告警让他瞬间清醒："ORA-15237: attribute 'COMPATIBLE.ASM' cannot be set in CREATE DISKGROUP"，作为公司的Oracle DBA，他知道这个错误意味着新建ASM磁盘组的操作失败了，而明天上午新系统就要上线...

这种场景对DBA来说并不陌生,当我们需要在Oracle ASM（自动存储管理）中创建新的磁盘组时，有时会遇到ORA-15237这个看似简单却可能耽误大事的错误，今天我们就来彻底搞懂它，并分享远程处理这类问题的实战经验。

错误解析：ORA-15237到底在说什么

ORA-15237错误告诉我们：在CREATE DISKGROUP语句中尝试设置了不允许在此阶段指定的属性，错误消息中的"string"会被实际属性名替代，常见的有：

• COMPATIBLE.ASM
• COMPATIBLE.RDBMS
• CELL.SMART_SCAN_CAPABLE
• AU_SIZE
• SECTOR_SIZE

核心原因：这些属性本应在磁盘组创建后通过ALTER DISKGROUP命令设置，而不是在创建时直接指定。

实战复现：错误是如何产生的

让我们模拟一个典型场景（基于Oracle 19c环境）：

-- 错误的创建方式（会触发ORA-15237）
CREATE DISKGROUP DATA_NEW
  NORMAL REDUNDANCY
  DISK '/dev/oracleasm/disks/DISK1','/dev/oracleasm/disks/DISK2'
  ATTRIBUTE 'compatible.asm'='19.0';

执行后会立即报错：

ORA-15237: attribute 'compatible.asm' cannot be set in CREATE DISKGROUP

专业修复：分步解决方案

第一步：正确的磁盘组创建方式

正确的做法是先创建基本磁盘组,再设置高级属性：

-- 1. 先创建不含属性的磁盘组
CREATE DISKGROUP DATA_NEW
  NORMAL REDUNDANCY
  DISK '/dev/oracleasm/disks/DISK1','/dev/oracleasm/disks/DISK2';
-- 2. 创建成功后设置属性
ALTER DISKGROUP DATA_NEW SET ATTRIBUTE 'compatible.asm'='19.0';

第二步：特殊属性的处理技巧

某些属性如AU_SIZE确实需要在创建时指定,这时应该这样操作：

-- 正确的方式：AU_SIZE是允许在创建时指定的少数属性之一
CREATE DISKGROUP DATA_LARGE
  NORMAL REDUNDANCY
  DISK '/dev/oracleasm/disks/DISK3'
  ATTRIBUTE 'au_size'='16M';

第三步：远程诊断的关键检查点

当远程处理这类问题时,我通常会通过以下命令收集信息：

1. 检查现有磁盘组属性（作为参考）：

   

   SELECT name, compatibility, database_compatibility 
   FROM v$asm_diskgroup;

2. 确认磁盘可用性：

   SELECT path, header_status, state, total_mb, free_mb 
   FROM v$asm_disk;

3. 查看ASM参数设置（特别是隐含参数）：

   SELECT name, value, description 
   FROM v$asm_attribute;

深度分析：为什么Oracle要这样设计

理解这个错误背后的设计哲学很重要：

1. 事务完整性：磁盘组创建是原子操作，而属性设置可能涉及复杂校验
2. 依赖关系：某些属性依赖于磁盘组的基本结构先被建立
3. 安全考虑：防止在创建阶段误配置关键参数

预防措施：DBA的最佳实践

根据2025年最新的Oracle ASM管理指南，建议：

1. 标准化脚本：为团队准备标准的磁盘组创建脚本模板
2. 分阶段执行：将创建和配置分为两个明确的变更窗口
3. 预检查清单：
   • 确认磁盘已正确标记为ASM磁盘
   • 验证操作系统权限
   • 检查存储多路径配置
4. 兼容性规划：提前确定COMPATIBLE.ASM和COMPATIBLE.RDBMS的合适版本

紧急情况处理：当时间紧迫时

如果像老王那样面临上线压力,可以考虑：

1. 简化配置：先以最低兼容性创建磁盘组，事后再调整
2. 并行操作：一边创建基本磁盘组，一边准备后续属性设置脚本
3. 回退方案：准备好DROP DISKGROUP语句，以防需要快速重试

-- 紧急情况下的最小化创建语句
CREATE DISKGROUP DATA_EMERGENCY
  EXTERNAL REDUNDANCY
  DISK '/dev/oracleasm/disks/DISK4';

经验分享：那些年我们踩过的坑

1. 大小写敏感：'compatible.asm'和'COMPATIBLE.ASM'在某些版本中表现不同
2. 版本差异：Oracle 12c与19c对属性设置的严格程度不同
3. 云环境特例：在OCI上的ASM服务中，部分属性由平台自动管理

ORA-15237虽然是个直白的错误，但它提醒我们Oracle ASM管理的精细性，记住这个简单的原则：先搭建，后装修，先创建基本磁盘组结构，再通过ALTER语句精细调整属性配置。

凌晨3点,老王按照正确流程完成了磁盘组创建和属性配置，新系统的存储准备就绪，他保存好操作记录，为团队知识库又添加了一条实战经验，作为DBA，我们解决的每个错误不只是为了恢复系统，更是为了积累下一次更快解决问题的智慧。