DB_FILE_NAME_CONVERT必须配置成对路径前缀，因其按“主库路径前缀→备库路径前缀”精确匹配替换，不支持通配符或模糊匹配，且两端必须带结尾斜杠、大小写敏感；若主库路径不以指定前缀开头则完全失效，导致ORA-01119等错误。
DB_FILE_NAME_CONVERT 为什么必须配成成对路径前缀
这个参数不是做字符串替换，而是按「主库路径前缀 → 备库路径前缀」做精确匹配替换。一旦主库数据文件路径不以你写的前缀开头，db_file_name_convert 就完全不生效，备库会直接报 ora-01119 或 ora-19504 —— 文件创建失败。
常见错误是只写目录名（比如 '/u01/oradata/prod', '/u02/oradata/std'），但主库实际路径是 /u01/oradata/prod/users01.dbf，而备库想放到 /u02/oradata/std/prod/users01.dbf。这时必须把前缀写全：前者得是 '/u01/oradata/prod/', '/u02/oradata/std/prod/'，末尾斜杠不能少。
- 必须两端都带结尾斜杠，否则可能只匹配到部分路径（比如把
/u01/oradata错误匹配进/u01/oradata_bak） - 大小写敏感，Linux 下
PROD和prod视为不同前缀 - 不支持通配符、正则或模糊匹配，只认字面量前缀
- 多个映射对用逗号分隔，顺序无关，但建议按路径层级从长到短排列，避免短前缀提前截断
主备库目录结构差异大时，怎么避免 DB_FILE_NAME_CONVERT 写崩
如果主库用 /u01/oradata/dbname/，备库用 /oradata/standby/datafiles/，硬凑前缀映射容易漏文件或错映射。这时候更稳的方式是：先在备库用 ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL，再靠 CREATE TEMPFILE / ALTER DATABASE CREATE DATAFILE 手动建；等同步稳定后，再切回 AUTO 并补全 DB_FILE_NAME_CONVERT。
- 临时表空间文件不会被
DB_FILE_NAME_CONVERT自动处理，必须单独用ALTER DATABASE ADD TEMPFILE指定备库路径 - 在线日志路径由
LOG_FILE_NAME_CONVERT控制，和DB_FILE_NAME_CONVERT互不干扰，别混在一起配 - 如果主库用了 OMF（Oracle Managed Files），备库又没开
DB_CREATE_FILE_DEST，那DB_FILE_NAME_CONVERT无效，必须关 OMF 或统一配置DB_CREATE_FILE_DEST
ALTER SYSTEM SET 后不生效？检查这三处硬性条件
DB_FILE_NAME_CONVERT 是静态参数，但只在备库处于 MOUNT 状态且未启动 Redo Apply 时才被读取。一旦已启库或已在恢复中，改了也白改。
- 必须在备库
SHUTDOWN IMMEDIATE后，用STARTUP MOUNT加载，再ALTER SYSTEM SET ... SCOPE=SPFILE - 修改后要重启备库（不是只
ALTER SYSTEM），否则新值不进内存也不影响后续文件创建 - 确认
STANDBY_FILE_MANAGEMENT是AUTO，否则参数根本不会触发自动映射逻辑
验证转换是否真起作用的最快方式
别等主库加数据文件再看备库报错——直接在主库执行：ALTER DATABASE ADD DATAFILE SIZE 10M，然后立刻查备库：SELECT NAME FROM V$DATAFILE WHERE NAME LIKE '%/u02%'。如果返回空，说明映射失败；如果返回新文件且路径符合预期，说明生效。
更细一点，可以查 V$ARCHIVED_LOG 的 NAME 字段，看归档日志里记录的主库路径是否能被你配的前缀覆盖住；再对比 V$STANDBY_LOG 里的实际路径，两头对得上才算真正落地。
最常被忽略的是：备库 alert.log 里其实每创建一个文件都会打一行 Converting filename ... to ...，但很多人只盯着 ORA 错误，忘了翻这条日志。
