ASM磁盘组属性决定了兼容级别、分配单元大小、扇区大小等底层参数。在Oracle RAC集群中，这些属性保存在磁盘组元数据里，所有节点的ASM实例共享同一信息。修改属性通常使用ALTER DISKGROUP命令或ASMCMD工具完成，但不同属性在变更时机、约束条件和生效范围上存在明显差异。下面从属性存储机制入手，逐步说明在Windows Server环境下如何安全完成属性修改。
一、属性存储机制与查询方法
ASM磁盘组属性并不是存放在某个节点本地配置文件里，而是直接写入磁盘组的元数据区域。因为RAC集群中的所有ASM实例都共享同一套磁盘组存储，所以在一个节点上修改属性后，其他节点在读取磁盘头信息时通常能够获取到新的值。这种设计避免了参数文件在各个节点间不一致的问题，但也意味着属性修改的影响范围是集群全局的，一旦写入错误的值，所有节点都会受到影响。
日常管理中最常用的查询视图是V$ASM_ATTRIBUTE。在Windows节点的命令提示符中，可以先进入Grid Infrastructure的BIN目录启动SQL*Plus，路径为C:\app\oracle\product\19.0.0\grid\BIN\sqlplus.exe。连接时需要使用SYSASM权限，例如执行C:\app\oracle\product\19.0.0\grid\BIN\sqlplus.exe / as sysasm。连接成功后，可以通过下面的语句查看DATA磁盘组的当前属性值。
SELECT name, value, read_only FROM v$asm_attribute WHERE group_number = ( SELECT group_number FROM v$asm_diskgroup WHERE name = 'DATA' ) ORDER BY name;
查询结果中read_only列非常重要。如果该列显示为Y，说明这个属性在磁盘组创建后不允许修改。常见只读属性包括au_size和sector_size。例如分配单元大小在创建磁盘组时就已经固化到元数据中，后续不能通过ALTER DISKGROUP调整。可修改属性则包括compatible.rdbms、compatible.asm、disk_repair_time等，它们大多用于控制兼容级别和ASM的自动修复行为。
了解属性的存储机制和只读标记，是安全执行修改操作的前提。很多误操作都发生在没有预先查询属性约束的情况下，直接尝试修改只读属性，结果收到ORA-15179一类的错误。建议每次修改前都先执行上面的查询，确认目标属性当前值以及是否允许动态变更。
二、ALTER DISKGROUP命令修改属性
修改ASM磁盘组属性最直接的方法是使用ALTER DISKGROUP ... SET ATTRIBUTE。语法结构并不复杂，但执行权限和属性值的格式要求比较严格。用户必须以SYSASM身份连接到ASM实例，并且目标磁盘组需要处于挂载状态。在Windows环境下，仍然通过SQL*Plus建立会话，执行命令前请确认当前节点已经成功加入RAC集群，并且ASM实例正常运行。
下面是一个将DATA磁盘组的RDBMS兼容级别提升到19.0.0.0的示例。注意磁盘组名称不区分大小写，但属性名和属性值通常使用单引号包裹。
ALTER DISKGROUP data SET ATTRIBUTE 'compatible.rdbms' = '19.0.0.0'; ALTER DISKGROUP data SET ATTRIBUTE 'compatible.asm' = '19.0.0.0';
这两条命令虽然可以连续执行，但建议先修改compatible.asm，再修改compatible.rdbms，因为二者的关系需要满足compatible.rdbms <= compatible.asm。如果先提高RDBMS兼容级别，而ASM兼容级别仍然较低，修改命令会直接失败。此外，兼容级别只能向上升级，不能向下降级。一旦将属性值写入，就无法再把它调回更低的版本。因此执行前必须确认所有节点的Oracle Grid Infrastructure版本都已经达到目标版本。
除了兼容级别，disk_repair_time也是经常调整的属性。它用于控制ASM在磁盘离线后等待多长时间才执行强制卸载和重新同步。默认值通常是3.6小时，但部分生产环境为了留出更长的硬件维护窗口，会把这个值调大。修改语句如下。
ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '8.5h';
此处的时间格式支持小时和分钟，例如4.5h表示4小时30分钟，90m表示90分钟。需要注意的是，这个属性影响的是ASM的自动修复策略，如果设置得过长，磁盘故障后数据恢复的时间也会相应延后，可能增加数据暴露风险。建议根据实际硬件保修响应时间和备份策略合理设置。
三、ASMCMD工具与节点间验证
除了SQL*Plus之外，ASMCMD命令行工具也提供了属性管理功能。在Windows Server上，ASMCMD的可执行文件位于C:\app\oracle\product\19.0.0\grid\BIN\asmcmd.exe。使用它可以执行lsattr查看属性，使用setattr修改属性。ASMCMD的setattr语法与SQL有所不同，不需要使用单引号，属性名和属性值直接以空格分隔。
例如在命令提示符中执行下面的命令，可以查看DATA磁盘组的全部属性。
C:\app\oracle\product\19.0.0\grid\BIN\asmcmd.exe lsattr -G data -l
如果需要通过ASMCMD修改兼容级别，可以使用类似下面的命令。
C:\app\oracle\product\19.0.0\grid\BIN\asmcmd.exe setattr -G data compatible.rdbms 19.0.0.0
无论使用SQL*Plus还是ASMCMD完成修改，都不能只在一个节点上验证结果。RAC集群的每个节点都运行独立的ASM实例，虽然磁盘组元数据是共享的，但不同节点的缓存刷新可能存在短暂延迟。建议在修改完成后，逐个节点登录并执行查询，确认V$ASM_ATTRIBUTE视图中已经反映出新的属性值。如果某节点查询结果长期不同步，可以尝试重新挂载磁盘组或重启该节点的ASM实例。
对于compatible.rdbms这类兼容属性，修改后新的数据库实例才能以目标兼容级别访问磁盘组，已经打开的数据库实例不会因为属性变化而自动调整。因此需要提前规划好数据库和集群的升级顺序。通常在完成所有节点的Grid Infrastructure升级后，再逐步提升ASM兼容级别，最后升级数据库实例的兼容级别，这样可以避免出现数据库实例无法访问磁盘组的情况。
四、常见修改案例与风险规避
在实际RAC运维中，最常见的属性修改场景是升级前的兼容级别调整。假设当前所有节点均运行19c版本的Grid Infrastructure，而DATA磁盘组的compatible.asm仍然停留在12.2.0.0，那么可以执行以下命令完成升级。
ALTER DISKGROUP data SET ATTRIBUTE 'compatible.asm' = '19.0.0.0'; ALTER DISKGROUP data SET ATTRIBUTE 'compatible.rdbms' = '19.0.0.0';
执行后务必在两个或更多节点上运行查询语句，确认属性值已经一致。如果在某个节点上查询仍显示旧值，不要立即重复执行修改命令，而应先检查ASM实例的告警日志。C:\app\oracle\diag\asm\+asm\+ASM1\trace\alert_+ASM1.log路径下通常能查看到属性同步失败的具体原因。反斜杠路径在Windows环境中必须保持完整，目录层级的跳转不能写成斜杠形式。
另一个容易踩坑的场景是修改disk_repair_time而不考虑ASM的重新同步压力。例如把修复时间从3.6小时调到24小时后，如果确实发生了磁盘离线，ASM会尝试在24小时内保留数据副本并等待磁盘恢复。但若该磁盘长时间无法上线，会触发大量的镜像扩展和重新平衡操作，可能影响整体I/O性能。因此修改前应该评估磁盘组的冗余类型、剩余空间以及硬件替换周期，不要单纯为了延长修复窗口而盲目调大参数。
属性修改操作虽然命令简单，但影响范围覆盖整个RAC集群。建议DBA在维护窗口内执行，避免在业务高峰期直接操作。修改之前保存一份完整的属性快照，可以使用SPOOL命令输出V$ASM_ATTRIBUTE查询结果到本地文件。操作完成后，除了验证属性值之外，还要检查磁盘组状态是否正常，确认所有节点均能正常读写。只有形成规范的修改流程，才能把ASM磁盘组属性变更的风险降到最低。
