当前位置：首页 > 数据库 > Oracle教程 > oracle奇怪的WRONG FILE NUMBER > 正文

oracle奇怪的WRONG FILE NUMBER

来源：这里教程网 时间：2026-03-03 22:45:11 作者：

一、现象：

目标是想搭建dg库，但是该数据库数据量比较大，将近5T，故需要使用rman备份恢复的方式来搭建， 于是先在主库做了全备，然后在dg库做恢复，restore成功后，尝试recover报错，说某个文件需要restore, 然后查看该文件状态发现报错：WRONG FILE NUMBER

1、数据文件备份方式如下：

RUN {  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/oracle/rman_backup/20250926/full_%U.bak';  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT '/backup/oracle/rman_backup/20250926/full_%U.bak';  ALLOCATE CHANNEL ch3 DEVICE TYPE DISK FORMAT '/backup/oracle/rman_backup/20250926/full_%U.bak';  ALLOCATE CHANNEL ch4 DEVICE TYPE DISK FORMAT '/backup/oracle/rman_backup/20250926/full_%U.bak';  BACKUP AS COMPRESSED BACKUPSET    INCREMENTAL LEVEL 0    DATABASE    TAG 'FULL_BACKUP_20250926'    FILESPERSET 5;  SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';  BACKUP AS COMPRESSED BACKUPSET    ARCHIVELOG ALL    FORMAT '/backup/oracle/rman_backup/20250926/arch_%U.bak'    TAG 'ARCH_BACKUP_20250926'    DELETE ALL INPUT;  #BACKUP CURRENT CONTROLFILE  FORMAT '/backup/oracle/rman_backup/20250926/control_%U.ctl'  TAG 'CTL_BACKUP_20250926'; #oracle rac 11.2.0.3 控制文件备份（RMAN 或 SQL）都强制要求“快照控制文件”，所以单独备份通过sql备份控制文件。  RELEASE CHANNEL ch1;  RELEASE CHANNEL ch2;  RELEASE CHANNEL ch3;  RELEASE CHANNEL ch4; }

2、备份控制文件：

11.2.0.3 RAC 官方代码存在缺陷，任何控制文件备份（RMAN 或 SQL）都强制要求“快照控制文件”与“最终备份片”同时落在共享存储，否则报 ORA-00245；
11.2.0.4 以后才放宽为“只要快照控制文件在共享即可，备份片可写本地”；
oracle rac 11.2.0.3 无法直接备份控制文件到非共享磁盘上， 但是oracle 11.2.0.4 是可以的
1）rman备份控制文件报错：
rman>BACKUP CURRENT CONTROLFILE  FORMAT '/backup/oracle/rman_backup/20250926/control_%U.ctl'  TAG 'CTL_BACKUP_20250926';
报错：RMAN-03009: failure of backup command on ORA_DISK_1 channel at 09/28/2025 10:06:31ORA-00245: control file backup failed; target is likely on a local file system
2）sql备份控制文件也报错：
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS  '/backup/oracle/rman_backup/20250926/control.ctl';
ALTER DATABASE CREATE STANDBY CONTROLFILE AS  '/backup/oracle/rman_backup/20250926/control.ctl'*ERROR at line 1:ORA-00245: control file backup failed; target is likely on a local file system
于是通过sql的方式备份控制文件到asm盘上：
SQL>  ALTER DATABASE CREATE STANDBY CONTROLFILE AS  '+ARCHIVELOGDG/control.ctl'; Database altered. 然后通过asmcmd 把asm上的备份文件cp到本地文件上，最后把备份的控制文件scp到dg库的机器

3、用全备在dg库的机器上恢复，如下所示的恢复命令：

因为执行run块报错，报错如下所示：
RMAN> RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01009: syntax error: found "identifier": expecting one of: ";" RMAN-01008: the bad identifier was: c0 RMAN-01007: at line 1 column 21 file: standard input
于是采用了如下所示的的恢复命令
1)编写run块内容到文件中，开启多个channel，提高备份恢复性能 [@psdg01 ~]$ cat  restore_parallel.rman RUN { SET NEWNAME FOR DATABASE TO '/backup/oracle/datafile/%b'; ALLOCATE CHANNEL c0 TYPE DISK; ALLOCATE CHANNEL c1 TYPE DISK; ALLOCATE CHANNEL c2 TYPE DISK; ALLOCATE CHANNEL c3 TYPE DISK; ALLOCATE CHANNEL c4 TYPE DISK; ALLOCATE CHANNEL c5 TYPE DISK; ALLOCATE CHANNEL c6 TYPE DISK; ALLOCATE CHANNEL c7 TYPE DISK; ALLOCATE CHANNEL c8 TYPE DISK; ALLOCATE CHANNEL c9 TYPE DISK; RESTORE DATABASE ; SWITCH DATAFILE ALL; SWITCH TEMPFILE ALL; RELEASE CHANNEL c0; RELEASE CHANNEL c1; RELEASE CHANNEL c2; RELEASE CHANNEL c3; RELEASE CHANNEL c4; RELEASE CHANNEL c5; RELEASE CHANNEL c6; RELEASE CHANNEL c7; RELEASE CHANNEL c8; RELEASE CHANNEL c9; } 2）执行备份 rman target / @restore_parallel.rman

4、restore完毕后，尝试recover，报错提示文件286需要restore:

RMAN> recover database; Starting recover at 29-SEP-25 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=692 device type=DISK RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 09/29/2025 11:27:38 RMAN-06094: datafile 286 must be restored
非常诡异的事情，restore已经成功执行了，为啥还会报错呢？

二、问题排查

1、在dg库查看文件的状态：发现文件头的文件号是错误的。

#文件online状态正常 SQL> SELECT name, status FROM v$datafile WHERE file#=286;   NAME                                      STATUS ---------------------------------------------------------------------------------------------- /backup/oracle/datafile/psimage19.dbf     ONLINE #查看文件头状态，发现异常，错误的文件号 SQL> SELECT file#, status, error FROM v$datafile_header WHERE file#=286;     FILE#     STATUS     ERROR ---------- -------------------------------------------------------------------------------     286       ONLINE     WRONG FILE NUMBER

2、什么是 文件头的文件号？

在Oracle数据库中，“文件头”通常是指数据文件（Datafile）的头部信息。Oracle数据库每个数据文件都有一个文件头，其中包含了重要的元数据信息。
1. 文件头的作用
存储元数据：文件头存储了关于数据文件本身的元数据信息，这些信息对于数据库的正常运行和维护至关重要。
验证文件完整性：文件头中的信息可以用于验证数据文件的完整性和一致性。
支持数据库恢复：在数据库恢复过程中，文件头中的信息可以帮助数据库管理系统（DBMS）确定数据文件的状态和位置。
2. 文件头包含的内容
文件编号（File Number）：每个数据文件在数据库中都有一个唯一的编号，文件头中存储了这个编号。
表空间信息（Tablespace Information）：文件头中包含了该数据文件所属的表空间名称和表空间编号。
文件状态（File Status）：文件头中记录了数据文件的状态，例如是否在线、是否需要恢复等。
文件大小（File Size）：文件头中记录了数据文件的大小信息，包括当前大小和最大大小。
创建时间（Creation Time）：文件头中记录了数据文件的创建时间。
块大小（Block Size）：文件头中存储了数据文件的块大小信息，这是Oracle数据库中数据存储的基本单位。
检查点信息（Checkpoint Information）：文件头中包含了最近的检查点信息(包括scn号)，这对于数据库的恢复操作非常重要。

3、什么情况下会发生这样的错误呢？

原来是我主库的文件分布在好多个目录中，在不同的目录上有相同名字的数据文件，然而我dg库在restore的时候，全部rename到同一个目录了，这样在dg库就会有冲突，同名的文件覆盖了数据块，但是并没有把数据文件头信息更正，很惊悚的是 restore居然不报错！但是实际上数据文件已经被覆盖了。

三、问题解决

1、从新恢复下286号文件，并指定恢复到另一个目录，具体如下所示：

run {  set newname for datafile 286 to '/backup/oracle/oradata/datafile/hrapp03.dbf';  restore datafile 286;  switch datafile 286;         }

2、再次查看文件状态，发现已经没报错了。

SQL> SELECT file#, status, error FROM v$datafile_header WHERE file#=286;     FILE#     STATUS     ERROR ---------- -------------------------------------------------------------------------------     286       ONLINE

3、最后再执行recover，正常了。

总结：

1、严格遵守运维规范，oracle数据库添加数据文件时，不管是不是在相同的目录下，都需要保证文件名字唯一性；
2、restore成功没报错，不意味着数据库恢复成功，只意味着每个文件都restore成功，但是遇到重名的会覆盖，需要排查原因。

编辑推荐：

相关推荐

最新软件资讯

商汤科技押注“1+X”：是破局利刃，还是盲目挣扎？
商汤科技押注“1+X”：是破局利刃，还是盲目挣扎？

热文推荐

天极热推