在Oracle RAC集群的日常运维中，ASM磁盘组里的disk repair timer是一个不起眼却牵一发而动全身的属性。它决定了一块掉线磁盘在被彻底剔除之前还能保留多长的抢救期，这个窗口期设置得是否合理，直接决定了磁盘短暂故障后集群是做一次轻量的增量同步，还是被迫承受一次代价高昂的全量rebalance。这篇文章把这个属性的机制、语法、监控手段和调优思路完整梳理一遍。
disk repair timer到底是什么
disk repair timer对应的是ASM磁盘组属性DISK_REPAIR_TIME，从Oracle 11g开始引入，默认值是3.6小时，也就是3小时36分钟。它的含义很直接：当磁盘组中的一块磁盘因为故障进入offline状态后，ASM不会立刻把它drop掉，而是启动一个倒计时，在倒计时归零之前，这块磁盘的元数据信息仍然保留在磁盘组里，一旦故障恢复，磁盘可以直接重新上线并只同步掉线期间发生变化的数据。
这个特性出现之前，ASM对磁盘故障的处理相当简单粗暴：磁盘一掉线就立刻从磁盘组中剔除，然后触发rebalance，把这块磁盘上的所有数据搬移到其他磁盘。对于容量以TB计的磁盘组来说，一次全量rebalance可能持续数小时甚至更久，期间大量IO被重建任务占用，业务SQL的响应时间会明显恶化。而现实中相当一部分磁盘故障是瞬时的，比如HBA卡复位、光纤链路抖动、存储控制器切换、机房供电波动，磁盘往往几分钟内就能恢复。为了几分钟的故障付出几个小时的rebalance代价，显然不划算，disk repair timer就是为解决这个问题而生的。
在RAC集群环境下，这个属性的意义被进一步放大。ASM磁盘的状态是集群范围内的全局信息，一个节点感知到磁盘故障，整个集群都会看到这块磁盘offline。如果磁盘被drop并触发rebalance，所有节点的ASM实例都会参与数据搬移，等于把IO压力扩散到了整个集群。因此对RAC来说，合理利用修复窗口，把瞬时的磁盘故障消解在resync阶段，是保护集群整体性能的重要手段。
计时器的工作机制：从offline到resync的完整流程
当一块磁盘被判定offline后，ASM会做三件事：第一，把磁盘标记为offline状态，此时磁盘组仍然保持挂载，数据库不受影响，前提是磁盘组冗余级别足够；第二，启动修复计时器，剩余时间可以从V$ASM_DISK视图的REPAIR_TIMER列查到，单位是秒；第三，开始记录掉线期间被写入的区段信息。这个记录动作非常关键，它决定了磁盘恢复后需要回补的数据范围。
如果在计时器归零之前磁盘故障排除，DBA执行ONLINE操作让磁盘重新上线，ASM会执行一次resync，只把掉线期间发生变化的数据块复制回这块磁盘。由于变化量通常只占总数据的很小比例，resync往往几分钟就能完成，对业务几乎无感。整个过程不会移动磁盘组里的其他数据，IO开销可控。
如果计时器归零时磁盘仍然没有恢复，ASM就会自动drop掉这块磁盘，同时启动rebalance，把这块磁盘上原本存放的所有数据重新分布到剩余磁盘上。这是一次全量的数据搬移，IO量与故障磁盘的容量成正比，大容量磁盘组上可能持续数小时。更麻烦的是，在rebalance完成之前，磁盘组的冗余度处于降级状态，如果此时再坏一块磁盘，normal冗余下数据就有丢失风险。
还有一点需要明确：disk repair timer只对normal或high冗余的磁盘组有实际意义。external冗余的磁盘组不做镜像，磁盘掉线意味着数据直接不可访问，谈不上修复窗口。所以如果数据盘组是external冗余，把修复时间设得再长也没有意义，真正该做的是确认存储侧的冗余策略是否可靠。
查看与修改DISK_REPAIR_TIME的实操方法
先看怎么查。磁盘组级别的属性可以通过V$ASM_ATTRIBUTE视图查询，也可以用asmcmd工具查看，两种方式在不同平台上的语法完全一致。下面的语句查的是所有磁盘组的disk_repair_time设置：
-- 查询磁盘组的disk_repair_time属性 SELECT GROUP_NUMBER, NAME, VALUE FROM V$ASM_ATTRIBUTE WHERE NAME = 'disk_repair_time'; -- 使用asmcmd查看，效果等同 -- asmcmd lsattr -G DATA -l disk_repair_time
修改属性用ALTER DISKGROUP语句，可以在线执行，不需要停数据库，也不影响磁盘组的正常读写。常见的做法是把默认的3.6小时调大，给硬件更换留出更充裕的时间：
-- 把DATA磁盘组的修复时间调整为8小时 ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time' = '8h'; -- 也可以写成更明确的小数格式 ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time' = '8.0h';
除了磁盘组级别的统一设置，还可以对单块磁盘单独指定修复时间。典型场景是某块磁盘已经确认硬件故障，备件需要较长时间才能到位，这时可以在offline操作里用DROP AFTER子句单独给它一个更长的窗口，其他磁盘仍然沿用磁盘组的默认值：
-- 手动让磁盘离线，并单独指定12小时的修复窗口 ALTER DISKGROUP DATA OFFLINE DISK DATA_0002 DROP AFTER 12h; -- 磁盘修复完成后重新上线，触发resync ALTER DISKGROUP DATA ONLINE DISK DATA_0002;
磁盘掉线后，监控剩余修复时间是运维的关键动作。REPAIR_TIMER列以秒为单位显示倒计时，配合磁盘的模式状态列，可以快速判断当前处于哪个阶段：
-- 查看磁盘状态与剩余修复时间
SELECT DG.NAME AS DISKGROUP,
D.NAME AS DISK,
D.MODE_STATUS,
D.STATE,
D.REPAIR_TIMER
FROM V$ASM_DISK D, V$ASM_DISKGROUP DG
WHERE D.GROUP_NUMBER = DG.GROUP_NUMBER
ORDER BY DG.NAME, D.NAME;
需要注意，执行这些操作时连接的是ASM实例而不是数据库实例。RAC环境下任意节点的ASM实例都可以执行，修改会同步到整个集群。如果集群搭建在Windows系统上，asmcmd同样可用，只是要通过C:\app\oracle\grid\bin目录下的工具执行，并确认环境变量ORACLE_SID指向的是+ASM1这类ASM实例而非数据库实例，否则会报权限或对象不存在的错误。
RAC环境下的设置建议与常见坑
修复时间设多长，没有放之四海而皆准的答案，核心依据是硬件故障的处置能力。如果存储厂商的备件到场加更换能在4小时内完成，8小时左右的设置就留足了缓冲；如果用的是异地维保，换盘可能要一两天，那就要权衡是否值得把窗口拉长到24小时。窗口设得过长的问题是：磁盘真正报废时，rebalance被推迟，磁盘组在降级冗余状态下运行的时间也相应拉长，这段时间里再出现一块磁盘故障，风险就会被放大。
另一个容易被忽略的场景是投票磁盘和OCR所在的磁盘组。RAC集群的投票盘放在ASM里时，磁盘组本身的可用性直接关系到集群的存续。虽然投票盘所在的磁盘组通常容量很小、rebalance很快，但修复时间的设置同样要谨慎评估，确保在窗口期内集群的仲裁机制不会受到威胁。必要时可以把OCR和投票盘单独放在一个小容量的高冗余磁盘组里，与业务数据盘组隔离管理，互不干扰。
监控层面建议做两件事：一是定期巡检V$ASM_DISK的STATE和REPAIR_TIMER列，任何出现异常状态的磁盘都要第一时间跟进，而不是等到计时器快归零才处理；二是盯住ASM实例的告警日志，Windows环境下日志位于类似C:\app\oracle\grid\diag\+asm\+ASM1\trace\的目录，文件名为alert_+ASM1.log，磁盘offline、计时器归零、resync开始和结束这些事件在日志里都有明确记录，排障时是第一手资料。
最后提醒一个细节：修复计时器是持久化在磁盘组元数据里的，不依赖某个ASM实例的内存状态。也就是说，即使计时期间某个节点重启，甚至整个集群重启，倒计时的进度依然会被保留，磁盘的offline状态也不会因为重启而丢失。这一点在规划维护窗口时要考虑进去，不要指望靠重启把一块掉线磁盘重置回在线状态，正确的操作永远是先修复底层硬件，再执行ONLINE触发resync，让ASM用最小的代价把数据补齐。
Oracle RACASM磁盘组disk repair time修改时间：2026-09-28 15:07:48