在实际运维过程中，最怕遇到的就是“误操作”。
尤其是在 Oracle RAC 环境中，如果误将集群（Grid Infrastructure）和数据库软件目录执行了  chown -R，将导致整个集群和数据库权限被破坏，实例无法启动，监听异常，ASM 无法挂载磁盘组等严重问题。

本文记录一次典型的修复过程及思路，供各位 DBA 参考。

一、问题背景

某次维护中，运维人员误在节点上执行了：

chown -R oracle:oinstall /oracle

或者更严重的：

chown -R root:root /

导致集群与数据库软件目录（ $GRID_HOME、 $ORACLE_HOME）内的所有文件属主、属组被破坏。

二、问题现象

• 集群无法启动；
• 数据库实例启动报错；
• Alert 日志出现如下信息：

WARNING：failed to register ASMB0 with ASM instance
ORA-01034：ORACLE not available
ORA-27121：unable to determine size of shared memory segments
Linux-x86_64 Error：13：Permission denied

从错误信息看，典型的“权限丢失”问题。

三、修复总体思路

修复的核心目标是：

1. 恢复集群软件（Grid Infrastructure）各文件的属主属组；
2. 恢复数据库软件（Oracle RDBMS）关键文件权限；
3. 验证 ASM 与数据库实例能正常启动。

在数据库集群环境中，误执行  chown -R 是极为危险的操作之一，它会导致 Grid Infrastructure 与数据库软件目录（$GRID_HOME、$ORACLE_HOME）中文件的属主与权限被破坏，进而造成集群无法启动、ASM 无法挂载、数据库实例启动报错等严重后果。常见错误包括  ORA-01034: ORACLE not available、 ORA-27121: unable to determine size of shared memory segments、 Linux-x86_64 Error: 13: Permission denied 等。

修复的关键在于恢复正确的文件属主、属组及权限。首先应立即停止所有集群与数据库服务。若有同版本正常环境，可在该环境中进入  $GRID_HOME，通过  getfacl -pR ./ > backup.txt 备份 ACL 权限，再根据实际主机名、ASM 名调整内容，拷贝至出问题的环境执行  setfacl --restore=backup.txt 完成权限恢复。若无参考环境，可使用  find 命令按 UID 查找被破坏的文件并重新  chown。

数据库部分的关键文件是  $ORACLE_HOME/bin/oracle 和  $GRID_HOME/bin/oracle，必须保持  -rwsr-s--x 权限，即同时具有 setuid 与 setgid 位。若权限丢失，可使用 ASM 用户执行  $GRID_HOME/bin/setasmgidwrap o=$ORACLE_HOME/bin/oracle 重新生成，并通过  chmod u+s、 chmod g+s 确保权限正确。修复完成后重新启动集群与数据库实例，若 ASM 和数据库均能正常运行，则说明权限恢复成功。经验表明，安装完成后应立即备份权限信息，日常运维严格区分 grid 与 oracle 用户操作，避免误执行高风险命令。同时可在系统中设置命令别名或权限保护机制，防止类似事故再次发生。

一、修复集群软件权限

⚠️ 处理前务必关闭集群和数据库。

crsctl stop cluster -all

方法一：使用 ACL 权限备份与恢复

如果有一套相同版本的正常环境，可以通过  getfacl /  setfacl 复制权限。

在正常环境执行：

cd $GRID_HOMEgetfacl -pR ./ > backup.txt

若环境主机名、ASM 实例名不同，可通过  sed 或  vi 命令批量替换：

:1,$s/rac1/rac2/g

然后将修改后的  backup.txt 拷贝至当前损坏环境，执行恢复：

setfacl --restore=backup.txt

该方法可较完整地恢复文件 ACL 权限和属主信息。

方法二：通过 UID/GID 恢复

如果没有备份环境，也可以查找指定 UID 的文件，重新分配属主。

find $GRID_HOME -uid <错误的uid> -exec chown grid:oinstall {} \;
find $GRID_HOME -uid <root用户id> -exec chown root:root {} \;

执行完成后，确认关键二进制文件的权限是否正确。

启动集群

crsctl start cluster -all

如果 CRS 能正常启动，说明 Grid 基本修复成功。

二、修复数据库软件权限

数据库无法启动时， alert.log 通常会出现如下报错：

ORA-01034：ORACLE not available
ORA-27121：unable to determine size of shared memory segments
Linux-x86_64 Error：13：Permission denied

其中，最关键的文件权限是  $ORACLE_HOME/bin/oracle。

正确的权限示例

$ ls -tlr $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle dba 407944920 Mar  4 19:36 /oracle/app/product/12.2.0/db_1/bin/oracle
$ ls -tlr $GRID_HOME/bin/oracle
-rwsr-s--x 1 grid oinstall 372684232 Mar  4 17:00 /oracle/gi/bin/oracle

修复步骤

切换至 ASM 用户执行：

su - gridcd $GRID_HOME/bin
./setasmgidwrap o=/u01/app/oracle/product/12.2.0/db_1/bin/oracle

手动确保二进制文件具备  suid/sgid：

chmod u+s $GRID_HOME/bin/oracle
chmod g+s $GRID_HOME/bin/oracle

参考文档：
📄  Database Will Not Mount: ORA-15025, ORA-27041, ‘Permission denied’, ORA-15081 (Doc ID 1378747.1)

验证启动

srvctl start database -d <dbname>

若数据库和 ASM 实例均正常启动，则恢复成功。

三、总结与经验教训

结语

误执行  chown -R 是 DBA 生涯中是破坏性的错误之一。
但只要掌握修复方法、冷静处理，依然可以让系统“起死回生”。

作者：Digital Observer（施嘉伟）
Oracle ACE Pro
PostgreSQL ACE Partner
Oracle  OCM、KCM、PGCM、YCP、DB2 、MySQL OCP、PCTP、PCSD、OCI、PolarDB技术专家、达梦师资认证，从业11年+
ITPUB认证专家、崖山YVP、PolarDB开源社区技术顾问、HaloDB技术顾问、TiDB社区技术布道师、青学会MOP技术社区专家顾问、国内某高校企业实践指导教师
公众号/墨天轮/金仓社区/IF Club：Digital Observer；CSDN/PGfans：施嘉伟；ITPUB：sjw1933