Oracle 自动存储管理（ASM）的重新平衡（Rebalancing）算法

原创于 2025-09-10 12:32:16 发布 · 946 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#oracle #数据库

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述
好的，我们将对 Oracle ASM（自动存储管理）的重新平衡（Rebalancing）机制进行一场深入的技术剖析。这是一个复杂但至关重要的主题，尤其在现代数据库存储管理中扮演着核心角色。

第一部分：官方技术详解

一、ASM 核心概念与内部结构回顾

1. ASM 是什么？
Oracle Automatic Storage Management (ASM) 是一个专为 Oracle 数据库文件提供的卷管理器和文件系统。它简化了数据库存储管理，通过条带化（Striping）和镜像（Mirroring）提供了高性能和高可用性。

2. 关键内部结构
理解 Rebalance 前，必须理解以下 ASM 核心结构：

磁盘组 (Disk Group)：ASM 管理的最高层逻辑单元，由一组物理磁盘（LUNs、PDBs、网络磁盘等）构成。数据库文件就创建在磁盘组中，而不是具体的物理磁盘上。
分配单元 (AU - Allocation Unit)：ASM 空间分配的基本单位。默认大小为 1MB，可在创建磁盘组时设置为 1, 2, 4, 8, 16, 32 或 64MB。AU 是条带化操作的基本块。
区 (Extent)：ASM 文件（如数据文件、日志文件）空间分配的单位。一个区由一个或多个 AU 组成。在 ASM 版本 11.1 之前，一个区等于一个 AU。之后，为了支持更大的文件，文件扩展（variable sized extents）被引入：文件前 20000 个区是 1 AU，接下来的 20000 个区是 4 AU，超过 40000 的区是 16 AU。
条带 (Stripe)：为了性能，ASM 可以将一个区（Extent）切分成更小的条带，并将它们分布到磁盘组的不同磁盘上。条带大小通常为 128KB。
ASM 实例：一个特殊的 Oracle 实例，用于管理磁盘组元数据并提供文件访问接口。数据库实例与 ASM 实例通信来访问数据。
RBAL：ASM 实例中的一个后台进程，负责协调磁盘组的重新平衡操作。
ARB0…ARB9 / ARBn：ASM 实例中的实际执行重新平衡操作的进程（Automatic Rebalance Master and Slave Processes）。其数量由 ASM_POWER_LIMIT 参数控制。

二、重新平衡 (Rebalancing) 的核心原理

1. 作用与触发条件
重新平衡的核心作用是在磁盘组内均匀分布文件数据，以维持 I/O 负载均衡。它在磁盘组的拓扑结构发生变化时自动触发：

添加磁盘 (ADD DISK)：最常见的原因。新磁盘加入，数据需要从现有磁盘迁移到新磁盘，以利用新增容量和 I/O 带宽。
删除/丢弃磁盘 (DROP/DISMOUNT DISK)：磁盘被移除，其上的数据需要被重新分布到磁盘组内剩余的所有磁盘上。
调整磁盘大小 (RESIZE DISK)：改变磁盘的容量。
磁盘故障 (FAILURE)：如果一个磁盘故障且其镜像副本不可用（例如在 NORMAL 冗余下），ASM 会重新平衡以恢复冗余。
手动强制 (REBALANCE POWER n)：即使没有结构变化，DBA 也可以手动发起重新平衡以强制优化数据分布。

2. 重新平衡算法与过程
重新平衡不是一个简单的“文件拷贝”过程，而是一个高度优化的、基于区（Extent）移动的算法。

阶段一：计划 (Planning)
1. 当触发事件发生时，RBAL 进程会评估当前的磁盘组布局。
2. 它计算出一个最优的数据分布目标状态，目标是使每个磁盘的已用空间百分比和未来的 I/O 负载尽可能均衡。
3. 基于此目标，RBAL 生成一个移动映射图 (Map of Moves)，详细列出需要将哪些区（Extent）从哪个磁盘移动到哪个磁盘。这个计划旨在最小化总的数据移动量。
阶段二：执行 (Execution)
1. RBAL 进程作为协调者（Master），将移动任务分配给多个 ARBn 工作进程。
2. 每个 ARBn 进程负责一部分区的移动。它会：
  - 从源磁盘读取一个或多个区的数据。
  - 将数据写入目标磁盘的适当位置。
  - 更新 ASM 的元数据（存储在磁盘组头中），以反映该区的新位置。这是关键：数据库实例通过查询 ASM 元数据来找到文件数据的位置。一旦元数据更新，所有后续的 I/O 请求将直接前往新位置。
3. 移动是以一种并行和异步的方式进行的。
关键特性：
- 幂等性 (Idempotent)：重新平衡操作可以从断点恢复。如果操作中断（如 ASM 实例重启），它会从上次完成的检查点（Checkpoint）继续，而不是从头开始。
- 在线操作：重新平衡期间，数据库可以保持打开并对数据进行完全访问。对于正在被移动的数据区，I/O 请求会被短暂暂停，直到该区的移动和元数据更新完成。这个暂停通常非常快，用户几乎无感知。
- 粒度：移动的单位是区（Extent），而不是整个文件。这允许细粒度的、交错进行的操作，最大限度地减少对单个文件的影响。

3. 管理机制：POWER 限制与速度控制
重新平衡的强度（即速度和对系统 I/O 的影响）由 POWER 参数控制。

含义：POWER 级别 (0-1024, 11gR2+; 0-11, 早期版本) 直接决定了参与重新平衡操作的 ARBn 进程的数量。更高的 POWER 意味着更多的并行进程，移动速度更快，但也会消耗更多的 CPU 和 I/O 资源。
设置：
- ALTER DISKGROUP data REBALANCE POWER 5; – 手动设置
- ASM_POWER_LIMIT 参数设置了自动重新平衡的默认上限。
POWER 0：一个特殊值。它不会取消正在进行的重新平衡，而是会暂停它。这对于在业务高峰时段减少系统负载非常有用。

三、常用查询与管理 SQL

监控重新平衡操作进度：

-- 在 ASM 实例中查询
SELECT * FROM V$ASM_OPERATION;
-- 或使用 GV$ASM_OPERATION (适用于 RAC)
SELECT GROUP_NUMBER, OPERATION, STATE, POWER, ACTUAL, SOFAR, EST_WORK, EST_RATE, EST_MINUTES FROM GV$ASM_OPERATION;

SOFAR：已完成的区移动数量。
EST_WORK：预计总移动量。
EST_MINUTES：预计剩余时间（分钟）。

查看磁盘组和磁盘状态：

SELECT GROUP_NUMBER, NAME, STATE, TOTAL_MB, FREE_MB, TYPE FROM V$ASM_DISKGROUP;
SELECT GROUP_NUMBER, DISK_NUMBER, NAME, PATH, STATE, TOTAL_MB, FREE_MB FROM V$ASM_DISK ORDER BY GROUP_NUMBER, DISK_NUMBER;

执行重新平衡操作：

ALTER DISKGROUP data ADD DISK '/dev/sdf1' REBALANCE POWER 8 WAIT; -- WAIT 选项使命令等待操作完成
ALTER DISKGROUP data DROP DISK DATA_0001 REBALANCE POWER 5 NOWAIT; -- NOWAIT 是默认选项，命令立即返回
ALTER DISKGROUP data REBALANCE POWER 3; -- 手动调整正在进行操作的 POWER

第二部分：场景、争用、排查与解决

四、性能争用与排查

重新平衡是一个资源密集型操作，主要消耗 I/O 和 CPU 资源。在高负载系统中，它可能引发争用。

1. 场景：I/O 瓶颈与 db file sequential read / db file scattered read 等待

原理：ARBn 进程需要从源磁盘读取区，并向目标磁盘写入区。这会与数据库实例的正常 I/O 请求（如全表扫描产生的 db file scattered read 或索引查找产生的 db file sequential read）竞争相同的物理 I/O 通道和磁盘带宽。
影响：数据库会话的 I/O 响应时间变长，查询性能下降，表现为上述等待事件的等待时间增加。
排查：
1. 使用 AWR/ASH 报告，比较重新平衡开始前后的性能数据。
2. 查看 Load Profile 部分的 Physical Read/Write IOPS/Throughput 是否有显著增长。
3. 在 Top 10 Foreground Events 中，观察 I/O 相关等待事件（db file sequential/scattered read, log file parallel write）的平均等待时间和总等待时间是否激增。
4. 在 ASM 实例中，监控 V$ASM_OPERATION 的进度，如果 EST_MINUTES 很高且 EST_RATE 很低，很可能遇到了 I/O 瓶颈。
解决：
- 降低 POWER：这是最直接有效的方法。ALTER DISKGROUP ... REBALANCE POWER 2; 立即减少并行度，减轻 I/O 压力。
- 在业务低峰期执行：将添加/删除磁盘的操作安排在夜间或周末进行。
- 分批次操作：如果需要添加很多磁盘，不要一次性加入，可以分多次，每次加少量磁盘，让系统有一个消化和适应的过程。
- 硬件层面：确保存储阵列的控制器缓存和后端磁盘带宽没有饱和。

2. 场景：ASM 元数据争用与 enq: KO - fast object checkpoint / ASM file metadata operation

原理：重新平衡过程中，ARBn 进程需要频繁更新 ASM 的元数据（如区的位置映射表）。这些更新需要加锁（Enqueue）以确保一致性。当 POWER 设置很高时，大量的 ARBn 进程会并发地请求更新元数据，导致对元数据资源的争用。
影响：ARBn 进程本身会变慢，因为它们在等待获取元数据锁。这表现为重新平衡速度并未随 POWER 增加而线性提升，甚至可能下降。数据库实例可能也会间接受到影响，因为它们也需要访问 ASM 元数据来定位文件。
排查：
1. 在 ASM 实例中查询等待事件：
```
SELECT INST_ID, EVENT, COUNT(*) FROM GV$SESSION WHERE WAIT_CLASS <> 'Idle' GROUP BY INST_ID, EVENT;
```
  查找 enq: KO - fast object checkpoint, ASM file metadata operation, disk group rebalance 等事件。
解决：
- 适当降低 POWER：找到一个平衡点，使得 I/O 和元数据争用都在可接受范围内。
- 监控 CPU：高并发的元数据操作也会消耗大量 CPU。确保 ASM 实例的 CPU 资源充足。

3. 场景：数据库实例出现 KSFV_MESSAGE: WAITING FOR LOCK FOR ASM ENQUEUE

原理：当数据库实例需要打开一个文件，而该文件恰好正在被重新平衡操作移动（其元数据正在被更新）时，数据库会话需要等待这个操作完成才能继续。这是一个正常的、短暂的等待。
影响：极个别会话可能会遇到短暂的暂停，通常用户无感知。但如果大规模发生，可能表明重新平衡过于激进。
解决：通常无需解决，这是设计使然。如果频繁出现，可考虑略微降低 POWER。

第三部分：通俗易懂的解释

想象一下 ASM 磁盘组是一个巨大的、由很多书柜（磁盘）组成的图书馆，书（数据）被拆成很多书页（区），并且为了安全，重要的书都有复本（镜像）放在不同的书柜里。

重新平衡是啥？：就是图书馆的自动化理员机器人（ARBn进程）。当你往图书馆里新增加了一个书柜（添加磁盘），原来的书柜都塞得比较满了，新书柜却是空的。这很不均衡，新书柜的容量和“接待能力”（I/O带宽）都浪费了。机器人就会自动开始工作，把原来书柜上的一些书搬到新书柜上，直到所有书柜的满溢程度都差不多为止。同样，如果你撤走一个书柜（删除磁盘），机器人就得把这个书柜上所有的书（和它的复本）都分散到其他书柜上去。
它是怎么工作的？：
1. 机器人首领（RBAL）先做一个计划：计算要移动哪些书页，移动到哪里，总工作量是多少。
2. 然后它派出一队小机器人（ARBn，数量由 POWER 决定）同时去搬书。它们不是按整本书来搬，而是一页一页地搬（移动区）。搬一页，就立刻更新一下图书馆的总索引卡（ASM元数据），告诉人们“《Oracle高级编程》第103页现在在3号书柜，不再是5号书柜了”。
3. 在线操作：在机器人搬某一页书的时候，它会在这页书旁边放个“正在整理，稍等片刻”的小牌子。这时如果有人（数据库会话）想读这一页，就需要等一下下（通常毫秒级），等机器人搬完并更新好索引，就可以读了。因为搬的粒度是一页，所以对整个阅读体验影响极小。
会出现什么问题？：
- 走廊堵了（I/O瓶颈）：如果派了太多小机器人（POWER 太高），它们推着小车在走廊里跑来跑去搬书，就会堵住正常来看书的人的路。导致大家（数据库会话）走路（I/O）都变慢了。
  - 解决办法：少派几个机器人（降低 POWER），或者等晚上人少的时候再搬。
- 索引台挤爆了（元数据争用）：所有小机器人每搬一页书都要去同一个索引台更新信息。机器人太多了就会在索引台前排长队，反而慢了。
  - 解决办法：同样，控制机器人数量（POWER），别让它们自己挤在一起内耗。

总结：
ASM 重新平衡是一个极其智能和高效的后台过程，是 ASM “自动”管理的核心体现。DBA 的关键职责不是 micromanage 这个过程，而是通过理解和调整 POWER 参数，像一个交响乐指挥一样，平衡好“数据迁移速度”和“系统运行性能”之间的关系，确保它在后台和谐地完成工作，而不至于冲到前台来“抢戏”。

欢迎关注我的公众号《IT小Chen》