Oracle 19c ASM磁盘权限持久化配置：详解udev规则，彻底解决重启失效问题
在Oracle 19c RAC或单实例数据库的部署过程中，ASM磁盘组的配置是核心环节，但也常常成为技术难点。许多DBA会遇到这样的困扰：安装时使用asmcmd lsdg命令无法识别磁盘组，或者在执行create diskgroup建组操作时，反复出现ORA-15025、ORA-15031等权限错误。究其根本，绝大多数问题都源于磁盘设备的权限设置不当以及设备命名缺乏持久性。
核心症结在于，系统重启后/dev/sdX这类设备名会发生漂移，手动chown修改权限仅是临时生效。必须通过udev规则，基于scsi_id生成的全球唯一WWN号，将磁盘绑定到固定的别名（例如/dev/asmdiskc），并确保在RAC双节点上规则完全一致，权限属主正确设置为grid:asmadmin。
简而言之，如果/dev/sdx这类设备文件的属主和权限未能正确设置为grid:asmadmin，ASM实例将无法识别和访问这些磁盘。更复杂的是，即便手动执行chown命令成功，这也只是一个临时解决方案，系统重启后所有设置将恢复原状。因此，采用udev规则进行固化配置，是Oracle官方推荐且能实现一劳永逸的标准化解决方案。
为何直接执行chown grid:asmadmin /dev/sdX无法根治问题？
直接修改/dev/sdX的权限，方法看似简单，但为何无法作为持久化方案呢？关键在于，/dev/sdX这类基于内核探测顺序生成的设备名并非永久固定。当系统重启、多路径服务重新加载或内核模块刷新后，磁盘的设备编号（例如/dev/sdc, /dev/sdd）极有可能发生变动。你今天费力配置好的/dev/sdc权限，下次系统启动时，该磁盘可能被识别为/dev/sdd，导致权限错配。在Oracle RAC集群环境中，此问题会被进一步放大——若两个节点对同一物理磁盘识别出的设备名不一致，集群服务将无法正常启动。
- 真正稳定可靠的标识是
scsi_id命令生成的WWN（全球唯一名称），这是每块磁盘在全球范围内的唯一“身份证”，udev持久化规则正是基于此ID进行绑定。 - 同时需注意，Oracle ASM仅能识别和使用裸设备（即未分区的整块磁盘），对于
/dev/sdc1这类分区设备会直接拒绝访问。 - 此外，过去常用的ASMLib工具，在Oracle 19c时代已被官方明确弃用，当前推荐的标准化方案是使用udev规则，或结合多路径（multipath）软件进行配置。
编写udev规则前，务必准确获取磁盘唯一ID
在动手编写udev规则文件之前，首要且关键的一步是精确获取目标磁盘的唯一ID。切勿仅凭lsblk命令显示的设备名进行判断，必须使用scsi_id工具来获取SCSI设备的唯一序列号。操作时需关注以下细节：
- 命令路径与参数：在Oracle Linux 7/8或RHEL 7/8系统中，通常使用
/usr/lib/udev/scsi_id -g -u -d /dev/sdX。对于CentOS/RHEL 8.5及之后的版本，可能需要添加--whitelisted参数，否则命令可能返回空值。 - 确认目标为裸盘：执行
fdisk -l /dev/sdX，输出应显示“Disk /dev/sdX doesn‘t contain a valid partition table”，确认该磁盘为未分区的裸盘，方可用于ASM。 - 确保RAC环境一致性：对于RAC集群部署，同一块物理磁盘在两个节点上执行
scsi_id命令返回的字符串必须完全一致。若结果不同，通常意味着底层存储多路径配置存在问题，需优先解决。
例如，执行/usr/lib/udev/scsi_id -g -u -d /dev/sdf后，你将获得类似3604fe8d100d5d230b888210a00000038的长字符串，此ID即为后续编写udev规则的核心依据。
如何编写正确生效的99-oracle-asmdevices.rules规则文件
规则文件必须创建于/etc/udev/rules.d/99-oracle-asmdevices.rules路径下。其语法要求严格，顺序和细节均不容有误：
- 精确过滤设备类型：必须包含
ENV{DEVTYPE}=="disk"条件，确保规则仅作用于整块磁盘设备，避免误匹配到分区或LVM逻辑卷。 - 准确调用识别程序：
PROGRAM字段调用scsi_id时需指定完整路径，且RESULT的值必须与你先前获取的磁盘ID完全匹配，包括所有字符。 - 使用正确的设备创建命令：在
RUN+操作中，应使用mknod命令创建固定的别名设备文件（如/dev/asmdiskc），并对其设置权限，而非直接修改原始/dev/sdX设备的属主。 - 保持格式严谨：每行末尾避免多余空格，等号两侧不留空格，所有引号均使用英文双引号。
以下是一个标准的规则示例（请务必将示例中的ID替换为你实际磁盘的ID）：
KERNEL=="sd*", ENV{DEVTYPE}=="disk", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d %N", RESULT=="3604fe8d100d5d230b888210a00000038", RUN+="/bin/sh -c 'mknod /dev/asmdiskc %M %m; chown grid:asmadmin /dev/asmdiskc; chmod 0660 /dev/asmdiskc'"
规则编写完成后，执行udevadm control --reload-rules && udevadm trigger --subsystem-match=block命令以重新加载并立即触发规则。最后，使用ls -l /dev/asmdisk*命令检查，确认新创建的设备文件其属主和权限是否正确设置为grid:asmadmin和0660。
常见配置失败点排查：RAC节点间规则不一致
在Oracle RAC环境中，最常见的配置失败原因在于节点间的不一致。两个节点的/etc/udev/rules.d/99-oracle-asmdevices.rules文件内容必须保持绝对一致。实际操作中，容易因复制遗漏导致规则行缺失，或者更根本的问题是——两个节点对同一物理磁盘执行scsi_id命令得到了不同的结果（这通常指向底层存储多路径配置需要调整）。
可按以下步骤进行验证与排查：
- 在两个节点上分别执行
udevadm info --name=/dev/sdf | grep ID_SERIAL，对比输出信息是否完全一致。 - 在两个节点上运行
ls -l /dev/asmdisk*，确保所有asmdiskX设备文件均存在，且权限显示为brw-rw---- 1 grid asmadmin。 - 切换到grid用户，执行
asmcmd lsdsk -k命令，此时应能列出所有/dev/asmdiskX设备，其状态显示为candidate（候选）或provisioned（已配置）。
如果执行asmcmd lsdsk后列表仍为空，不必慌张。此时应重点检查udev规则是否被正确应用。可以运行udevadm test /sys/class/block/sdf命令，仔细分析输出日志中是否存在“failed to execute”（执行失败）或“no rule matches”（无规则匹配）等错误信息——这通常直接指明了规则语法错误或程序路径不正确等具体问题。
