诗檀软件专业数据库修复团队
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.