Email: service@parnassusdata.com 7 x 24 online support!

    You are here

    • You are here:
    • Home > Blogs > PDSERVICE's blog > Oracle DBPITR使用当前控制文件导致 ORA-01248: 文件 在将来的不完整恢复中创建

Oracle DBPITR使用当前控制文件导致 ORA-01248: 文件 在将来的不完整恢复中创建

Oracle DBPITR使用当前控制文件导致 ORA-01248: 文件 在将来的不完整恢复中创建

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com

 

ORA-01248: 文件  在将来的不完整恢复中创建

ORA-01248  oerr ora 1248
01248, 00000, "file %s was created in the future of incomplete recovery"
// *Cause:  Attempting to do a RESETLOGS open with a file entry in the
//          control file that was originally created after the UNTIL time 
//          of the incomplete recovery.
//          Allowing such an entry may hide the version of the file that 
//          is needed at this time.  The file number may be in use for 
//          a different file which would be lost if the RESETLOGS was allowed.
// *Action: If more recovery is desired then apply redo until the creation
//          time of the file is reached. If the file is not wanted and the
//          same file number is not in use at the stop time of the recovery,
//          then the file can be taken offline with the FOR DROP option.
//          Otherwise a different control file is needed to allow the RESETLOGS.
//          Another backup can be restored and recovered, or a control file can
//          be created via CREATE CONTROLFILE.


ORA-01147 oerr ora 1147
01147, 00000, "SYSTEM tablespace file %s is offline"
// *Cause: A file belonging to the SYSTEM tablespace has been marked offline
//         by the DBA.  The database cannot be started until all SYSTEM
//         tablespace files are online and openable.
// *Action: Bring the file online.

 

适用于:

Oracle Database – Enterprise Edition – 版本10.2.0.4到11.2.0.4 [Release 10.2 到11.2]
本文信息适用于任何平台。

症状

RMAN 或手动时间点恢复(DBPITR / PITR)失败显示ORA-1248。

$ oerr ora 1248
01248, 00000, “file %s was created in the future of incomplete recovery”
*原因:尝试使用在不完整恢复的UNTIL time后创建的控制文件中的文件条目来进行 RESETLOGS open。允许这样的条目可能会隐藏此时所需的文件的版本。该文件号可能在用于 一个不同的文件,如果允许RESETLOGS将会丢失。
*操作:如果需要更多恢复,则应用重做直至文件的创建时间。如果不需要该文件且 相同的文件号不在恢复的停止时间使用,则可以使用FOR DROP选项使该文件脱机。否则,需要不同的控制文件来允许RESETLOGS。另一个备份可以被还原并恢复,或者可通过CREATE CONTROLFILE创建一个控制文件。
恢复会话的错误示例(RMAN 或手动恢复):

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01248: file 4 was created in the future of incomplete recovery
打开数据库失败显示:

ORA-01248: file <file#> was created in the future of incomplete recovery
作为示例,使用下一个PITR命令:

SQL> recover database using backup controlfile until time ‘2013-06-01:08:38:45’

恢复会话失败显示ORA-1547 和 ORA-1248:

ORA-00279: change 974433 generated at 06/01/2013 08:38:34 needed for thread 1
ORA-00289: suggestion : /oracle/dbs/arch1_22_816675639.dbf
ORA-00280: change 974433 for thread 1 is in sequence #22
ORA-00278: log file ‘/oracle/dbs/arch1_21_816675639.dbf’ no longer needed for this recovery

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01248: file 4 was created in the future of incomplete recovery
ORA-01110: data file 4: ‘/oracle/dbs/system2.dbf’

如果尝试了OPEN ,它失败显示:

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01248: file 4 was created in the future of incomplete recovery
ORA-01110: data file 4: ‘/oracle/dbs/system2.dbf’

 

原因

在恢复期间使用的控制文件包含在PITR后创建的文件的引用。

可以进行DBPITR ,使用控制文件的当前副本或包含DBPITR后创建的文件副本。但还需要一些步骤来避免ORA-1248。

解决方案

第1步. 使PITR后创建的数据文件OFFLINE DROP并尝试OPEN

识别在PITR后创建的所有数据文件并使它们offline drop:

在示例中,PITR是”2013-06-01:08:38:45″,则接下来运行查询来找出在PITR后创建的所有文件:
SQL> select file#, name, status
2  from   v$datafile
3  where  creation_time > to_date(‘2013-06-01:08:38:45′,’YYYY-MM-DD:HH24:MI:SS’);

FILE# NAME                      STATUS
———- ————————- ——-
4 /oracle/dbs/system2.dbf   SYSTEM
5 /oracle/dbs/afterpitr.dbf ONLINE
如果基于SCN (RECOVER UNTIL CHANGE) PITR 完成,运行基于PITR 的SCN的查询。

例如,如果执行了下一个恢复命令:

recover database using backup UNTIL CHANGE 1003626;

then identify all files created after scn 1003626:

select file#, name, status
from   v$datafile
where  creation_change# >= 1003626;

 

 

对每个被识别的文件执行OFFLINE DROP 并尝试OPEN:

alter database datafile <file# or file name> OFFLINE DROP;

 

第2步. 如果第1步不允许数据库打开,.重建控制文件并打开

如果在OFFLINE DROP 后,OPEN仍失败显示ORA-1147,则最后的解决方案是重建控制文件,除了在DBPITR和打开数据库后创建的文件。
例如:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01147: SYSTEM tablespace file 4 is offline
ORA-01110: data file 4: ‘/oracle/dbs/system2.dbf’

如果文件再次联机,则它失败显示ORA-1194:

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01190: control file or data file 4 is from before the last RESETLOGS
ORA-01110: data file 4: ‘/oracle/dbs/system2.dbf’

这些是预期的错误,因为在PITR后创建的文件不再需要。

重建控制文件应当解决问题:

CREATE CONTROLFILE REUSE ….. —>>> EXCLUDE the files created after DBPITR (after “2013-06-01:08:38:45” in our example)

RECOVER DATABASE USING BACKUP CONTROLFILE

–>>>> if it asks for archived logs, provide the current online redo logs present on disk (from v$log/v$logfile).

SQL> alter database open resetlogs;

Database altered.