June 12, 2012

Real meaning and Simulate "ORA-01152: file was not restored from a sufficiently old backup"

I saw many times people asked the meaning of "ORA-01152: file n was not restored from a sufficiently old backup" and the difference between "ORA-01152" and "ORA-01113: file needs media recovery".

First of all,  "ORA-01152" is not related to controlfile. I say so because someone said  "ORA-01152: file was not restored from a sufficiently old backup" is caused by old
controlile.
It is not true. A simple prove is: even you recreate controlfile with "create database", you can still get the error.

Then what is the real meaning for "ORA-01152: file was not restored from a sufficiently old backup"?

To figure it out, let's firstly learn below knowledge regarding how oracle know if a recovery is nessasary during startup.
Infact oracle make the judgement from below two flags in datafile header block:
1. OFFSET 0138-0139: DB_state.
00 means DB is down, 04 means DB is running.
When a DB is up and running, this flag is 04. During an normal shutdown, oracle will change this flag to 00.
So if oracle read 04 of the flag during startup, then oracle will be aware that latest shutdown was not commpleted succeesfully, so a recovery will be nessasary.

2. OFFSET 0484-0489: checkpoint_change#
During a DB clean shutdown, oracle will make a full checkpoint, so all datafiles' checkpoint_change# will be sync.
So if in a startup checking, oracle found checkpoint_change# are inconsistent among datafiles, then an recovery will be required.



OK. Now we know how oracle judge the recovery, from two flags DB_state and checkpoint_change#.
Then it is a simple math that there are four combinations:
Scenario 1.DB_state=00 and checkpoint_change# are consistent.
It means lastest shutdown is an succeed clean shutdown. Oracle won't try to perform any recovery.

Scenario 2.DB_state=04 and checkpoint_change# are inconsistent.
95% DB crashing is located in this senerio. When a DB crashed, oracle have no time to change DB_state to 00, and checkpoint_change# among datafiles are not consistent.
In this senerio, when DB startup, a recovery will be required to perform, if you try to open resetlogs without recover, you will get below error:
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/data/oracle/data/miao/miao/stream01.dbf'
This is an common error we often get. We know very well about it.

Scenario 3.DB_state=04 and checkpoint_change# are consistent.
How can this happen? For example, you execute command "alter system checkpoint;" after this command you immediately execute below command:
shutdown abort;
Then checkpoint_change# among datafiles are the same. But DB_state remians 04.

Next time when oracle startup, oracle will read DB_state=04, which means, as i already introduced, latest close for this datafile is not an normal close.
The error here you will get is the same in senerio 2:
ORA-01113: file 5 needs media recovery

Scenario 4.state_flag=00 and checkpoint_change# are inconsistent.
In this case, you will get error "ORA-01152: file n was not restored from a sufficiently old backup".

But how could this happen? How can it be possible when checkpoint_change# are inconsistent while state_flag=00 which means a clean shutdown?


For example:
At time point T1, you shutdown database and made a closed clean backup.
Then you startup DB and do some operations and swtich logfile for mutiple times. Then at time point T2, again you normally shutdown the DB.

Now you delete some T2 datafiles and replace it with datafiles that you backuped at timepoint T1.
So now all these datafiles state_flag=00 because all datafiles are from an clean closed shutdown, but checkpoint_change# among these datafiles are not consistent.

In this sernerio, when you try to open resetlogs DB without recovery, you will get below error:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/data/oracle/data/miao/miao/system01.dbf'

5 Comments:

JAMSHER KHAN said...

Kevin You are awesome....I have seen lot of article on this topic but yours is best.
Your are master.

Unknown said...

That was a very good explanation.
Can you help us with steps to recover from this?

Unknown said...

If you take a consistent backup after shutting down the DB and then try to restore to that and recover will that fail?

Franck Pachot said...

Hi,

you said: First of all, "ORA-01152" is not related to controlfile.

But here is a case where it is related to controlfile. Recreating controlfile or recover using backup controlfile allows to open resetlogs:


RMAN> recover database;

Starting recover at 08-OCT-13
using channel ORA_DISK_1

starting media recovery
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/ORA/DATA/DEMO/system01.dbf'


SQL> select CHECKPOINT_CHANGE# , cast(CHECKPOINT_TIME as timestamp),file# from v$datafile;

CHECKPOINT_CHANGE# CAST(CHECKPOINT_TIMEASTIMESTAMP FILE#
------------------ ------------------------------- ----------
1849233 08-OCT-13 08.18.26.000000 PM 1
1849233 08-OCT-13 08.18.26.000000 PM 3
1849233 08-OCT-13 08.18.26.000000 PM 4
1849233 08-OCT-13 08.18.26.000000 PM 6


SQL> recover database using backup controlfile;
ORA-00279: change 1849233 generated at 10/08/2013 20:18:26 needed for thread 1
ORA-00289: suggestion : /ORA/RECO/DEMO/archivelog/2013_10_08/o1_mf_1_9_%u_.arc
ORA-00280: change 1849233 for thread 1 is in sequence #9


Specify log: {=suggested | filename | AUTO | CANCEL}
/ORA/DATA/DEMO/redo03.log
Log applied.
Media recovery complete.



SQL> alter database open resetlogs;

Database altered.

lalit said...

Hi Kevin,
Your blogs are really good..thanks for knowledge sharing....I have one scenario which I faced as below...
in my case while cloning i restore old controlfile from old autobackup and then I restore database which was relatively from recent COLD backup than that controlfile autobackup..I received same error of "ORA-01152: file was not restored from a sufficiently old backup" while opening database with resetlogs options.......so I recreated new control file manually from backup control file taken from production and able to open the database with resetlogs without any error...also no datafiles were in recover status....Can you please suggest why opening database succeeded by recreating controlfile here as you stated this error is not related to controlfile....i think this error comes when datafile info recorded in controlfile restored does not match with datafile headers (which contains metadata about the data file such as its size and checkpoint SCN)....hence after creating manual controlfile it sync control file with restored datafiles and opens the database...please let me know if my assumption is correct...

Post a Comment