👋 我是三笠，一名专注数据库运维与架构的 DBA，平时分享数据库实战经验与技术笔记，个人网站：ora100.com

前言

最近有一套 Oracle 19c RAC 数据库，DATA 磁盘组空间使用率已经接近 90%，需要扩容。

环境是两节点 RAC，底层使用 Dell EMC SAN 存储，通过 Multipath 管理共享磁盘，存储侧已经分配好一块 2TB 的新 LUN，只需要在操作系统上识别，然后加入 ASM 磁盘组。

整个过程不需要停库，本文记录一下实际操作步骤。

先看看当前 ASM 空间

首先使用 grid 用户连接 ASM：

sqlplus / as sysasm

查看磁盘组使用情况：

SET LINESIZE 200
SET PAGESIZE 100

SELECT
    NAME,
    TYPE,
    STATE,
    TOTAL_MB,
    FREE_MB,
    USABLE_FILE_MB,
    ROUND(FREE_MB/TOTAL_MB*100,2) FREE_PCT
FROM V$ASM_DISKGROUP
ORDER BY NAME;

查询结果：

NAME  TYPE   STATE    TOTAL_MB  FREE_MB  FREE_PCT
----- ------ -------- --------- -------- --------
ARCH  EXTERN MOUNTED    1048576   714856    68.17
CRS   EXTERN MOUNTED      61440    61044    99.36
DATA  EXTERN MOUNTED    6291456   651288    10.35

DATA 磁盘组总容量为 6TiB，剩余约 636GiB，使用率已经达到 89.65%。

再看看现有磁盘：

SET LINESIZE 220
COL NAME FORMAT A20
COL PATH FORMAT A40

SELECT
    NAME,
    PATH,
    TOTAL_MB,
    FREE_MB,
    HEADER_STATUS,
    STATE
FROM V$ASM_DISK
WHERE GROUP_NUMBER = (
    SELECT GROUP_NUMBER
    FROM V$ASM_DISKGROUP
    WHERE NAME = 'DATA'
)
ORDER BY DISK_NUMBER;

当前 DATA 由三块 2TiB 磁盘组成：

磁盘组采用 EXTERNAL 冗余，数据保护由底层 SAN 负责。

这次计划新增一块 2TiB LUN，扩容后 DATA 总容量达到 8TiB。

存储已经划好盘，主机怎么识别？

存储工程师已经将新 LUN 映射到两个 RAC 节点，但是操作系统还没有识别。

先在两个节点分别使用 root 扫描 SCSI 设备：

for host in /sys/class/scsi_host/host*; do
    echo "- - -" > "$host/scan"
done

sleep 5

udevadm settle

multipathd reconfigure

扫描完成后检查：

lsblk
multipath -ll

在两个节点上都发现了新增的 2TB 磁盘：

mpathh (3600c0ff000fd3e90xxxxxxxxxxxxxxxx) dm-9 DellEMC,ME5
size=2.0T features='0' hwhandler='0' wp=rw

|- 11:0:0:8 sdad active ready running
|- 11:0:1:8 sdae active ready running
|- 12:0:0:8 sdaf active ready running
`- 12:0:1:8 sdag active ready running

新 LUN 已经识别，四条路径全部正常。

⭐ 这里要特别注意：RAC 两个节点看到的必须是同一块共享 LUN，不能只看容量和设备名，还要核对 WWID。

本次两个节点识别到的 WWID 完全一致，说明共享存储映射正常。

另外，sdad、sdae 这些只是底层 SCSI 路径，不应该直接作为 ASM 磁盘使用。

我们使用 Multipath 聚合后的设备。

给新磁盘配置固定名称

现有 ASM 磁盘使用的名称分别是：

/dev/mapper/data1
/dev/mapper/data2
/dev/mapper/data3

因此，新磁盘继续采用相同的命名规则，配置为：

/dev/mapper/data4

两个节点分别备份配置文件：

cp -p /etc/multipath.conf \
/etc/multipath.conf.bak_$(date +%Y%m%d_%H%M%S)

编辑：

vi /etc/multipath.conf

在原有 multipaths 配置块中增加新 LUN 的 WWID 映射：

multipath {
    wwid  3600c0ff000fd3e90xxxxxxxxxxxxxxxx
    alias data4
}

注意，这里的 WWID 是脱敏示例，实际操作必须填写存储扫描得到的完整 WWID。

修改后先检查配置：

multipath -t >/tmp/multipath_test.log 2>&1
echo $?

返回 0，说明配置解析成功。

重新加载：

multipathd reconfigure

再次检查：

multipath -ll

新磁盘已经显示为：

data4 (3600c0ff000fd3e90xxxxxxxxxxxxxxxx) dm-9 DellEMC,ME5
size=2.0T

至此，两个节点的 Multipath 别名配置完成。

ASM 磁盘权限也要配置

当前环境通过 udev 管理 ASM 磁盘权限。

查看原有规则：

cat /etc/udev/rules.d/60-dm-permissions.rules

现有 DATA 磁盘的规则类似：

ENV{DM_NAME}=="data1", OWNER:="grid", GROUP:="asmadmin", MODE:="660", SYMLINK+="iscsi/oraasm-$env{DM_NAME}"
ENV{DM_NAME}=="data2", OWNER:="grid", GROUP:="asmadmin", MODE:="660", SYMLINK+="iscsi/oraasm-$env{DM_NAME}"
ENV{DM_NAME}=="data3", OWNER:="grid", GROUP:="asmadmin", MODE:="660", SYMLINK+="iscsi/oraasm-$env{DM_NAME}"

继续增加 data4：

ENV{DM_NAME}=="data4", OWNER:="grid", GROUP:="asmadmin", MODE:="660", SYMLINK+="iscsi/oraasm-$env{DM_NAME}"

两个节点都需要配置。

重新加载规则，并针对新增设备触发：

udevadm control --reload-rules

DM=$(basename "$(readlink -f /dev/mapper/data4)")

udevadm trigger --action=change --sysname-match="$DM"

udevadm settle

检查设备：

ls -l /dev/mapper/data4
ls -l /dev/iscsi/oraasm-data4

两个节点都成功生成了软链接：

/dev/mapper/data4 -> ../dm-9
/dev/iscsi/oraasm-data4 -> ../dm-9

再检查实际块设备权限：

ls -lL /dev/iscsi/oraasm-data4

stat -L -c '%U %G %a %n' \
/dev/iscsi/oraasm-data4

结果：

brw-rw---- 1 grid asmadmin 253, 9 ...

grid asmadmin 660 /dev/iscsi/oraasm-data4

权限没有问题。

这里有个容易忽略的地方：直接执行 ls -l 看到软链接是 root:root，不代表底层磁盘权限不正确。

要使用 ls -lL 或 stat -L 查看实际设备。

ASM 能不能识别这块新盘？

操作系统配置完成后，接下来检查 ASM。

su - grid
sqlplus / as sysasm

首先查看 ASM 磁盘发现路径：

SHOW PARAMETER asm_diskstring;

当前环境：

asm_diskstring = /dev/mapper/*

因此，后续加盘使用 /dev/mapper/data4，不需要修改 ASM_DISKSTRING。

检查新磁盘：

SET LINESIZE 220

SELECT
    INST_ID,
    PATH,
    OS_MB,
    TOTAL_MB,
    SECTOR_SIZE,
    LOGICAL_SECTOR_SIZE,
    HEADER_STATUS,
    MOUNT_STATUS
FROM GV$ASM_DISK
WHERE PATH = '/dev/mapper/data4';

查询结果：

INST_ID  OS_MB    TOTAL_MB  SECTOR_SIZE  LOGICAL_SECTOR_SIZE  HEADER_STATUS
-------  -------  --------  -----------  -------------------  -------------
1        2097152         0         4096                  512  CANDIDATE
2        2097152         0         4096                  512  CANDIDATE

这里 TOTAL_MB=0 并不是磁盘容量异常。

因为新磁盘还没有加入 ASM 磁盘组，ASM 已经通过 OS_MB 正确识别到 2TiB 容量。

HEADER_STATUS=CANDIDATE，说明它可以作为新磁盘加入 ASM。

不过，正式加盘之前，还需要检查扇区大小。

SELECT
    NAME,
    PATH,
    OS_MB,
    TOTAL_MB,
    SECTOR_SIZE,
    LOGICAL_SECTOR_SIZE,
    HEADER_STATUS
FROM V$ASM_DISK
WHERE GROUP_NUMBER = (
    SELECT GROUP_NUMBER
    FROM V$ASM_DISKGROUP
    WHERE NAME = 'DATA'
)
OR PATH = '/dev/mapper/data4';

结果：

四块磁盘的扇区参数一致。

操作系统再确认一下：

blockdev --getsize64 /dev/mapper/data4
blockdev --getss /dev/mapper/data4
blockdev --getpbsz /dev/mapper/data4

结果：

2199023255552
512
4096

容量和扇区参数均符合预期。

正式执行 ASM 在线扩容

前面的检查都通过后，就可以执行加盘。

本次 DATA 磁盘组为 EXTERNAL 冗余，新增磁盘与原有磁盘容量一致。

使用 grid 用户连接 ASM：

sqlplus / as sysasm

执行：

ALTER DISKGROUP DATA
ADD DISK '/dev/mapper/data4'
NAME DATA_0003
REBALANCE POWER 4;

返回：

Diskgroup altered.

说明新磁盘已经成功加入 DATA 磁盘组。

这里显式指定 NAME DATA_0003，是为了保持现有 ASM 磁盘的命名规则。

REBALANCE POWER 4 则用于控制重平衡的并行度。

对于生产环境，POWER 并不是越大越好。数值越高，通常意味着更高的重平衡资源消耗，具体还要结合存储 I/O 和业务负载决定。

加盘之后，Rebalance 怎么看？

ASM 新增磁盘后，会重新分布部分数据。

查询：

SET LINESIZE 220

SELECT
    INST_ID,
    GROUP_NUMBER,
    OPERATION,
    PASS,
    STATE,
    POWER,
    SOFAR,
    EST_WORK,
    EST_RATE,
    EST_MINUTES
FROM GV$ASM_OPERATION;

现场首次查询时，节点 2 上的 REBAL 处于 RUN 状态：

INST_ID  OPERA  STATE  POWER  SOFAR  EST_WORK  EST_MINUTES
-------  -----  -----  -----  -----  --------  -----------
2        REBAL  RUN        4     85    352556           31

说明 ASM 正在进行数据重平衡。

这里的 31 分钟是当时的估算剩余时间，并不代表实际耗时。

后续查询中，同时出现了 WAIT、RUN、DONE 状态。

⭐ 需要注意：看到 DONE 不代表所有 Rebalance 工作都已经完成。

应结合 PASS、STATE、SOFAR 和 EST_WORK 判断，直到没有正在执行的重平衡操作，再确认最终完成。

本次现场记录中，最后一次查询仍存在 RUN 状态，因此这里只确认扩容已成功、重平衡已经启动，不把最终完成时间写成已验证结果。

扩容后空间增加了多少？

执行加盘后，再次查询 DATA 磁盘组：

SELECT
    NAME,
    TYPE,
    STATE,
    TOTAL_MB,
    FREE_MB,
    USABLE_FILE_MB,
    ROUND(TOTAL_MB/1024,2) TOTAL_GB,
    ROUND(FREE_MB/1024,2) FREE_GB
FROM V$ASM_DISKGROUP
WHERE NAME = 'DATA';

结果：

NAME  TYPE   STATE    TOTAL_MB  FREE_MB   TOTAL_GB  FREE_GB
----- ------ -------- --------- --------- --------- --------
DATA  EXTERN MOUNTED    8388608   2748416      8192     2684

扩容前后对比：

DATA 磁盘组成功增加 2TiB，使用率从接近 90% 降到了约 67%。

再查看磁盘：

SELECT
    INST_ID,
    NAME,
    PATH,
    TOTAL_MB,
    HEADER_STATUS,
    MOUNT_STATUS,
    STATE
FROM GV$ASM_DISK
WHERE NAME = 'DATA_0003'
ORDER BY INST_ID;

两个 ASM 实例均返回：

INST_ID  NAME       PATH               TOTAL_MB  HEADER_STATUS  MOUNT_STATUS  STATE
-------  ---------  -----------------  --------  -------------  ------------  ------
1        DATA_0003  /dev/mapper/data4   2097152  MEMBER         CACHED        NORMAL
2        DATA_0003  /dev/mapper/data4   2097152  MEMBER         CACHED        NORMAL

说明新磁盘已经被两个 ASM 实例正常识别并使用。

最后检查集群：

crsctl stat res -t

两个节点的 ASM、DATA 磁盘组、数据库实例均为 ONLINE，数据库保持 OPEN 状态。

最后说几句

这次 Oracle 19c RAC ASM 扩容整体比较顺利。

从存储分配 LUN，到两个节点扫描磁盘、配置 Multipath 和 udev，再到 ASM 在线加盘，整个过程没有停止数据库。

实际上，ASM 扩容本身只需要一条 ALTER DISKGROUP 命令，真正需要仔细核对的是前面的共享存储配置。

尤其是 RAC 环境，两个节点的 WWID、Multipath、设备权限和 ASM 发现路径必须保持一致。

加盘命令不复杂，关键是确认加进去的确实是那块盘。

至于 Rebalance，也不要只看到 Diskgroup altered 就认为整个变更结束。空间扩容成功是一回事，数据重新分布是否完成，还需要单独检查。

写文章之外，我也在持续完善自己的数据库学习与运维平台 ORA100。

平时整理的数据库实战案例、常用 SQL、运维脚本和实用工具，都可以在这里找到。

网站地址：ora100.com

感兴趣的话，可以来看看。