不能。SYSTEM表空间数据文件无法在线重命名或移动，必须停库后在MOUNT状态下用ALTER DATABASE RENAME FILE更新控制文件路径，且物理文件须已通过操作系统命令复制到位并校验一致；RMAN COPY+SWITCH对SYSTEM文件不适用，会报ORA-00230错误。
SYSTEM表空间数据文件不能在线重命名或移动
直接执行 ALTER DATABASE RENAME FILE 或 ALTER TABLESPACE ... RENAME DATAFILE 对 SYSTEM 表空间文件会报错，比如 ORA-01516（不存在的日志文件、数据文件或临时文件）或 ORA-01122（数据库文件验证失败）。这是因为 SYSTEM 表空间始终 ONLINE、无法 OFFLINE，且其文件被核心进程持续访问，任何联机操作都会破坏一致性。
必须停库后用 ALTER DATABASE RENAME FILE 操作
唯一安全路径是关闭数据库，在 MOUNT 状态下更新控制文件记录。但注意：这不等于“移动完成”，它只是逻辑层面的路径修正——物理文件必须已就位。
- 先
SHUTDOWN IMMEDIATE，确保实例完全停止 - 用操作系统命令（如
cp或rsync）把system01.dbf复制到目标路径，确认属主为oracle、权限为640、大小一致 -
STARTUP MOUNT，再执行ALTER DATABASE RENAME FILE '/old/system01.dbf' TO '/new/system01.dbf' -
ALTER DATABASE OPEN—— 如果此时报 ORA-01157，说明物理文件没到位或权限不对
为什么不能用 RMAN COPY + SWITCH？
RMAN 的 COPY DATAFILE 和 SWITCH DATAFILE TO COPY 在 SYSTEM 文件上会失败，报 ORA-00230（无法获取备份或复制操作的独占存档日志锁）。根本原因是 SYSTEM 数据文件的检查点和 SCN 依赖整个实例状态，RMAN 无法在 MOUNT 状态下安全接管其恢复链。
你可能会看到 RMAN 尝试执行但卡在 recover datafile 阶段，最终提示 “datafile is not recoverable” —— 这不是配置问题，而是设计限制。
Effector Ecosystem
下载
用于设计、审查、生成或重构使用Effector、effector-react、Farfetched、AtomicRouter、@effector/next等库的React应用。
容易被忽略的三个细节
很多人做完停库 rename 就以为结束了，结果一重启库就挂：
- 忘记检查
v$controlfile和v$datafile中路径是否完全一致（包括大小写、软链接、相对路径） - 目标路径所在文件系统未启用
noatime或挂载选项冲突，导致 Oracle 打开文件时返回 I/O 错误 - 如果用了 ASM，
RENAME FILE必须配合ASMCMD cp，不能用 OS 命令；而ALTER DATABASE MOVE DATAFILE（12c+）对 SYSTEM 仍不支持
最稳妥的做法：操作前用 strings 抽取新旧两个 system01.dbf 的文件头，比对 DBID 和 checkpoint SCN 是否一致。不一致=复制中断或文件损坏，不能继续。
