RMAN 不动文件权限，因其还原操作仅通过 Oracle 内部 I/O 接口写入数据块，不经过 shell 层，故不感知也不修改属主、组或权限位；还原后文件默认归当前 OS 用户所有且权限为 600，必须由 DBA 手动执行 chown/chmod 修复，范围包括数据文件、控制文件（600）、SPFILE（644）及归档目录（755），并确保 oracle 用户属于 oinstall 组。
rman 本身不处理文件权限恢复，它只还原文件内容和结构；权限属于操作系统层面控制，必须由 dba 在还原后手动设置 —— rman 不会、也不能改 chmod 或 chown。
为什么 RMAN 不动文件权限
RMAN 还原操作本质是把备份片中的数据块按物理结构写入目标路径，它调用的是 Oracle 内部 I/O 接口，不经过 shell 层，因此完全不感知、也不修改文件属主、组或权限位。即使源库文件属组是 oinstall、目标机当前用户属组是 dba，RMAN 还原出来的文件默认归当前 OS 用户所有，权限通常是 600（rw-------），不会继承源库设置。
还原后必须手动修复的三类权限
-
数据文件、控制文件、重做日志：必须属主为
oracle，属组为oinstall（或你实际使用的 DBA 组），权限严格为600；否则startup mount时会报ORA-01157/ORA-01152 -
SPFILE 和 PFILE：放在
$ORACLE_HOME/dbs/下，需644，属主oracle，属组oinstall；否则startup nomount失败，报LRM-00109 -
归档日志目录（
LOG_ARCHIVE_DEST_1等）：Oracle 进程需有写权限，建议设为755，属组包含oinstall并确保 oracle 用户在该组内
执行 chmod/chown 的关键时机和范围
别在还原前预设权限 —— RMAN 还原会覆盖属主和权限；必须等 RESTORE DATABASE 完成、SWITCH DATAFILE ALL 执行完、且所有文件已落盘后再统一修复：
例如目标数据文件路径为 /u01/app/oracle/oradata/ORCL/，执行：
chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL/
find /u01/app/oracle/oradata/ORCL/ -type f -name "*.dbf" -exec chmod 600 {} \;
find /u01/app/oracle/oradata/ORCL/ -type f -name "control*.ctl" -exec chmod 600 {} \;
chmod 644 $ORACLE_HOME/dbs/spfileORCL.ora
注意：chmod -R 600 会把目录也设成不可进入，所以必须分类型处理；临时文件（v$tempfile）路径同样要纳入 chown 范围，否则 open resetlogs 时可能卡在 temp 表空间初始化。
容易被忽略的跨用户组陷阱
如果目标主机上 oracle 用户不在 oinstall 组（比如只在 dba 组），即使 chown oracle:oinstall 成功，OS 层仍拒绝访问 —— 因为组权限不生效。务必确认：
id oracle 输出中必须含 oinstall；若无，运行 usermod -a -G oinstall oracle 并重新登录；否则后续所有 RMAN 操作（包括 CATALOG START WITH）都可能因无法读取备份片而失败。
