在Oracle RAC集群中，ASM磁盘的所有者属性直接决定Grid Infrastructure进程能否以正确的操作系统身份访问共享磁盘。日常运维里，磁盘所有者被意外修改或安装时配置错误，往往会引发ASM实例无法启动、OCR读取超时等故障。掌握规范的更改方法并理解其影响范围，对于保障集群高可用性非常关键。
一、ASM磁盘所有者在Windows RAC中的角色
在Windows Server环境下，Oracle RAC的ASM磁盘实际上是操作系统层面的物理磁盘设备对象，例如\\.\PhysicalDrive3。与Linux环境下的grid:oinstall归属不同，Windows平台的所有者信息保存在磁盘设备的安全描述符中，通过访问控制列表（ACL）来决定哪些账户可以读取或写入该磁盘。安装Grid Infrastructure时，安装程序通常会将Oracle Grid服务账户（可能是本地系统账户或专用域账户）设置为ASM磁盘的所有者，并授予完全控制权限。如果后续这个所有者被改成了其他账户，而Grid服务账户又不具备相应的ACL，那么ASM实例在尝试打开磁盘时就会收到“拒绝访问”错误。
这里需要特别强调RAC多节点的一致性。所有参与集群的节点必须对同一个共享ASM磁盘具有相同的所有者和权限设置。如果节点A的所有者正确，而节点B的所有者被意外改成了其他账户，当节点B上的ASM实例尝试挂载磁盘组时，它会因为权限不足而失败。更严重的是，CSS（Cluster Synchronization Services）会通过表决磁盘进行节点间心跳检测，一旦某个节点无法正常访问表决磁盘，就可能被判定为异常节点并触发节点驱逐，导致数据库服务在集群层面出现意外切换甚至中断。因此，更改ASM磁盘所有者绝不能只在单个节点上执行，必须在每个节点按相同步骤逐一处理，并且要安排在业务低谷窗口进行。
此外，ASM磁盘所有者与磁盘组的所有者概念容易混淆。磁盘组的所有者是数据库内部的逻辑概念，由ASM实例管理；而磁盘所有者是操作系统层面的物理权限标识。本文讨论的是后者，即操作系统对底层磁盘设备的归属关系。只有底层所有者正确，ASM实例才能顺利读取到磁盘组的元数据。
二、Windows平台更改ASM磁盘所有者的完整步骤
在开始操作之前，需要先确认当前节点上ASM磁盘对应的物理磁盘编号。可以先通过diskpart工具列出所有磁盘，再结合Oracle自带的asmtool或asmcmd查看ASM磁盘路径与物理磁盘的映射关系。下面这个示例展示了如何进入diskpart并查看磁盘3的详细信息：
diskpart list disk select disk 3 detail disk
执行以上命令后，控制台会输出磁盘3的型号、大小以及只读属性等信息。如果该磁盘正是ASM使用的共享磁盘，则应当继续查看当前所有者。Windows的磁盘设备路径格式为\\.\PhysicalDrive3，对应的卷路径可能形如\\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\。需要注意的是，在Windows命令行中这些反斜杠必须原样保留，不能省略或替换为正斜杠。
更改所有者的推荐方式是使用icacls命令直接修改磁盘设备对象的安全描述符。与文件系统目录不同，磁盘设备对象不能通过右键属性→安全选项卡直接看到完整的ACL，但icacls可以作用于设备路径。例如，假设Oracle Grid服务账户名为OraGrid，要将\\.\PhysicalDrive3的所有者改为该账户并授予完全控制权限，可以在管理员命令提示符下执行：
icacls \\.\PhysicalDrive3 /grant OraGrid:F /T
上述命令中的</grant>参数用于添加权限，F代表完全控制，/T表示递归应用到所有子对象。如果还需要同时更改所有者，可以结合takeown或使用PowerShell的Set-Acl脚本。以下是一个PowerShell片段，展示了如何为磁盘设备设置所有者和访问规则：
$devicePath = "\\.\PhysicalDrive3"
$acl = Get-Acl -Path $devicePath
$identity = New-Object System.Security.Principal.NTAccount("OraGrid")
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($identity, "FullControl", "Allow")
$acl.AddAccessRule($rule)
Set-Acl -Path $devicePath -AclObject $acl
执行完权限修改后，务必再次通过diskpart的detail disk或icacls查看权限，确认新所有者已生效。尤其要注意，如果集群中有多个节点，需要在每个节点上用相同的账户名称和权限级别执行相同的命令。如果域账户在不同节点上名称相同但SID不一致，还需要核实域环境的账户解析是否正常。
三、更改后的验证与集群资源恢复
ASM磁盘所有者更改完成后，即使权限设置正确，Oracle Clusterware的现有进程仍然可能持有旧的安全令牌，导致磁盘访问在短时间内仍然失败。因此，建议在一个节点上先重启Oracle Clusterware服务来刷新安全上下文。可以使用以下命令停止和启动集群栈：
crsctl stop crs -f crsctl start crs
需要注意的是，crsctl stop crs -f会强制停止当前节点的所有集群资源，包括CSS、ASM实例和数据库实例。如果集群是生产环境，务必先确认其他节点能够正常接管负载，或者提前将数据库服务切换到其他节点。在停止集群栈之前，最好备份OCR和表决磁盘的配置，例如使用ocrconfig -export命令导出OCR内容到安全目录，例如C:\app\grid\backup\ocr_export.dat。
集群栈重启成功后，需要验证ASM磁盘是否被正确识别和挂载。可以通过srvctl检查ASM实例状态：
srvctl status asm -detail
同时登录ASM实例，查询v$asm_disk视图，确认所有磁盘的mount_status和header_status均为正常值：
select path, name, mount_status, header_status from v$asm_disk;
如果查询结果中某个磁盘的mount_status为CLOSED或header_status为UNKNOWN，则说明权限仍然存在问题。此时应检查ASM实例的告警日志，日志文件通常位于C:\app\grid\diag\asm\+asm\ASM1\trace\alert_ASM1.log。在日志中搜索ORA-15081或OS error等关键字，可以快速定位到权限拒绝的具体磁盘路径。
另一个常见问题是磁盘所有者虽然在磁盘设备层面修改成功，但ASM实例使用的访问路径是符号链接或者是通过asmtool映射的别名。此时需要确认ASM_DISKSTRING参数是否仍然指向正确的路径。如果之前使用的是磁盘编号而不是完整的设备路径，修改所有者后最好将ASM_DISKSTRING统一设置为\\.\PhysicalDrive*的形式，减少因路径解析不一致带来的额外问题。最后，所有节点验证通过后，再观察一到两个业务周期，确保集群没有出现间歇性的磁盘访问失败告警。
Oracle RACASM磁盘磁盘所有者修改时间：2026-09-20 13:41:24