ORA-16014根因是OS层文件系统只读，需用df -h和mount确认DB_RECOVERY_FILE_DEST路径是否ro，并检查磁盘空间与inode；ORA-1642禁止SYSTEM表空间设为只读属Oracle硬限制；ORA-01119创建数据文件失败还可能因SELinux、NFS配置或进程用户异常。
ORA-16014：日志无法归档，因为 DB_RECOVERY_FILE_DEST 所在文件系统只读
oracle 报这个错，不是数据库里某个表空间设了只读，而是底层 os 层面挂载点被 mount -o ro 或磁盘满后内核自动 remount 为只读。数据库进程（如 arcn）写归档时直接被系统拒绝，错误里常带 ora-19809: limit exceeded for recovery files 或 ora-00257: archiver error，但根因是 os 权限卡死。
实操建议：
- 先用
df -h和mount | grep $ORACLE_BASE确认DB_RECOVERY_FILE_DEST对应路径是否真的只读（看输出里有没有ro） - 别急着改 Oracle 参数——即使把
DB_RECOVERY_FILE_DEST指向另一个路径，如果新路径所在文件系统也是只读，照样报错 - 检查磁盘空间：
df -i（inode 耗尽也会触发只读 remount）、ls -lt /u01/fast_recovery_area/看最近归档是否堆积 - 临时恢复写入：若确定安全，用
mount -o remount,rw /u01（需 root），但必须同步清理归档，否则下次还会只读
ALTER TABLESPACE ... READ ONLY 后数据文件仍被修改？
表空间设为只读，只是禁止 DML 和 DDL，但 Oracle 仍可能往它的数据文件里写内容：比如 checkpoint 时更新文件头的 SCN、SMON 清理事务槽、甚至某些 bug 导致的隐式写。这时候如果该数据文件所在目录在 OS 层被设为只读（chmod -w 或父目录 chattr +a），就会在 alert.log 里看到类似 ORA-01114: IO error writing block to file ... (block # ...) 的报错。
实操建议：
- 确认只读意图：如果真要防止任何写入（比如做冷备份），OS 层限制比
ALTER TABLESPACE ... READ ONLY更彻底；但反过来，OS 只读会导致 Oracle 内部维护操作失败，不能替代数据库级只读 - 查文件权限：
ls -ld /u01/oradata/ORCL/users01.dbf，注意不仅是文件本身，整个路径（尤其是父目录）都得有写权限 - 常见坑：NFS 挂载时用了
noac或服务端导出选项限制了 write，此时touch测试会失败，但 Oracle 报错更隐蔽
ORA-1642：表空间 SYSTEM 不允许设为只读
这是硬性限制，不是权限问题。Oracle 要求 SYSTEM、SYSAUX、UNDO、TEMP 这几类表空间必须可写，否则实例无法启动或运行。如果你在脚本里写了 ALTER TABLESPACE SYSTEM READ ONLY，执行时直接报错，不会等到 OS 权限校验那步。
实操建议：
- 别试，没意义。想保护核心对象，用
READ ONLY用户角色、细粒度审计、或 RMAN 备份加加密更实际 - 误操作已执行？重启实例即可回退——只读状态不持久化到控制文件，但若伴随其他异常（比如同时改了 OS 权限），得先恢复 OS 写权限再启库
- 注意
DBA_TABLESPACES视图里的STATUS字段：显示READ ONLY仅对用户表空间有效，系统表空间永远是ONLINE
用 chown oracle:oinstall 修完权限，为什么还是 ORA-01119？
ORA-01119 是创建数据文件失败，常发生在 CREATE TABLESPACE 或添加数据文件时。即使 chown 和 chmod 都对了，也可能卡在三个地方：SELinux 上下文、NFS export 选项、或者 Oracle 进程实际运行用户不是 oracle（比如用 sudo -u oracle sqlplus / as sysdba 启动，但环境变量没继承）。
实操建议：
- 查 SELinux：
ls -Z /u01/oradata/，正常应是system_u:object_r:oracle_db_home_t:s0；不对就用restorecon -Rv /u01/oradata - NFS 场景必查服务端：
showmount -e localhost和/etc/exports里对应路径是否含no_root_squash（否则 root 创建的文件，oracle 用户看不到写权限） - 验证 Oracle 进程真实 UID：
ps -eo user,comm | grep pmon，确保是oracle用户，不是root或其他
Oracle 的权限协同不是“数据库设了只读，OS 就不用管”，而是两层校验叠在一起：OS 拒绝写，Oracle 就连内部维护都做不了；Oracle 不允许只读的表空间，OS 再放开也没用。最容易忽略的是 NFS 的 no_root_squash 和 SELinux 上下文，它们不出现在常规权限检查里，但一出手就是静默失败。
