在实际运维过程中，最怕遇到的就是“误操作”。
尤其是在 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
从错误信息看，典型的“权限丢失”问题。
三、修复总体思路
修复的核心目标是：
- 恢复集群软件（Grid Infrastructure）各文件的属主属组；
- 恢复数据库软件（Oracle RDBMS）关键文件权限；
- 验证 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_HOME
getfacl -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 - grid
cd $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 实例均正常启动，则恢复成功。
三、总结与经验教训
| 项目 | 建议 |
|---|---|
| 权限备份 | 建议在安装完成后立即使用 getfacl 对 $GRID_HOME、$ORACLE_HOME 进行权限备份 |
| 分权操作 | 集群操作建议仅限 grid 用户，数据库操作仅限 oracle 用户 |
| 误操作防护 | 通过 alias 限制危险命令或配置操作日志审计，防止误执行 |
| 严重破坏时恢复 | 若权限破坏严重，可从相同版本环境复制软件目录并重新配置 ASM/OCR |
结语
误执行 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
