{"id":16290,"date":"2021-04-30T15:00:29","date_gmt":"2021-04-30T13:00:29","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/"},"modified":"2021-04-30T15:00:29","modified_gmt":"2021-04-30T13:00:29","slug":"an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/","title":{"rendered":"An example of ORA-01152: file &#8230; was not restored from a sufficiently old backup"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p><a href=\"https:\/\/dev.to\/franckpachot\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup-5oo\" target=\"_blank\" rel=\"noopener\">.<\/a><\/p>\n<pre><code>\nOracle Error: \nORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below \nORA-01152: file ... was not restored from a sufficiently old backup \nORA-01110: data file ...\n<\/code><\/pre>\n<p>This error is one of the most misunderstood recovery error. It can happen in different case but I have here a simple example to reproduce it, with some comments and queries to see the state. I run an example to avoid long theory but let&#8217;s put the main media recovery concepts in a few words. [Note that even if my idea was to put only a few words&#8230; it is longer than expected, so skip to the example if that&#8217;s what you were expecting]<\/p>\n<p>Except when you are doing direct-path insert, the database files (datafiles) are written from the buffer cache, by the database writer, asynchronously, without caring about transactions. At any point in time, in a database that is opened, you may have commited changes for which the changed block is not yet written to the datafiles. You may also have changes written to the datafiles which are not commited yet or will be rolled back later. You may also have some part only of an atomic changes. There are points (checkpoint) where the database ensures that what has been changed in memory is written back to the datafiles. Those points are important as they mark the start of the redo log stream that is required to ensure that the changes done in memory can be applied (recovered) to the datafiles in case of database crash. The controlfile keeps track of this but the checkpoint information (time, SCN, redo threads,&#8230;) is also written to the datafile headers so that recovery is possible even of the current controlfile is lost, or restored from a backup.<\/p>\n<p>This is for instance failure. But the stream of redo may be used also in case of media recovery where you had to restore a datafile from a previous backup, in order to bring the datafile to the current state. Then the datafile header shows a checkpoint from a previous point in time (before the last checkpoint of the current state) and recovery can be possible because the redo from before the last checkpoint has also been backed up as archived logs. And finally, there&#8217;s also the possibility that all datafiles are from past checkpoints, because you want to do Point-In-Time Recovery (PITR) either by restoring all datafiles from a previous backup, and recover up to this PIT only. Or you used flashback database to bring them back, which recovers to this PIT as well. In those cases, you will open to a new incarnation of the database, like a branch in the timeline, and OPEN RESETLOGS to explicitly tell Oracle that you know that your datafile state is different than the current state, as known in the controlfile and the online redo logs (which will then be discarded).<\/p>\n<p>However, even if you have this possibility, with a datafile PIT state that does not match the controlfile one, there are some conditions that must be met in order to open the database without inconsistencies. Basically, they must be consistent among themselves. Because table data are in some datafiles, indexes may be in others, metadata in another one, undo vertors elswhere, and the same for foreign key parent table&#8230; So even if all recovery is correct (no changes lost thanks to redo log recovery) the database may refuse an OPEN RESETLOGS. And that&#8217;s basically what ORA-01152 tells you: your recovery is ok for each file, but the point you recovered to is not globally the same consistent state.<\/p>\n<p>So, there are two major pieces of information that are checked by Oracle when opening the database. One is about the consistency of each datafiles and the other is about the consistency of the database. When the database is opened, there may be some changes that are from after the checkpoint recorded in the datafile header, because dbwriter continuously does its job. This is known as the datafile being &#8220;fuzzy&#8221;. Only when the database is closed, the fuzzy bit is cleared to say that all blocks of the datafiles are consistent with the checkpoint time. That&#8217;s for each datafile consistency. And in order to leave a clean state, closing the database also does a last checkpoint so that all datafiles are consistent. This can be opened without the need to apply some redo log, given that you want to get the database at the same point in time than it was closed. But once closed, you can do things that Oracle doesn&#8217;t know. Like restoring the files from a previous backup, even from a hot backup where the files were fuzzy. So, in any case, when Oracle opens the database it checks the datafile headers, as if it were not cleanly closed.<\/p>\n<pre><code>\nSQL&gt; host mkdir -p \/u90\/{close,open}\/{before,after}\n<\/code><\/pre>\n<p>I create directories to put a backup of a datafile. I&#8217;ll backup the datafile in the open or mount state (to have fuzzy and non fuzzy backups). And from two points in time (&#8216;before&#8217; and &#8216;after&#8217; the state I want to open resetlogs)<\/p>\n<pre><code>\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n    OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n_____________ ______________ _____________________ __________________ ______________________\nREAD WRITE           1692588               1692038            1691878                1692586\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n     natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ              CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ _______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL           NO     YES    30-apr-2021 10:38:02        8196 1692038             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     05-aug-2019 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     05-aug-2019 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     05-aug-2019 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL           NO     YES    30-apr-2021 10:38:02        8196 1692038             183 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL           NO     YES    30-apr-2021 10:38:02           4 1692038             183 0\n\n11 rows selected.\n<\/code><\/pre>\n<p>I&#8217;ll run those queries each time. They show the checkpoint SCN of my database, from the controlfile, and from my datafile headers. The FUZZY=YES column tells me that the database is opened, which means that there are changes in the datafiles that were written after the checkpoint. This is also visible by the flag 4 in FHSTA (or 8196 because 8192 is another flag for the SYSTEM datafiles). There are files that are not fuzzy even if the database is opened, because the tablespaces are in read-only, PDB$SEED in this example. You can see that their checkpoint time is from a long time ago because they havent been opened read-write since them. As they are not fuzzy, and checkpointed at the same SCN, they are consistent. And as they are read-only since then Oracle knows that they don&#8217;t need any recovery. I think we have a clue about this with the RECOVER column being null.<\/p>\n<pre><code>\nSQL&gt; alter database begin backup;\n\nDatabase altered.\n\nSQL&gt; host cp \/u02\/oradata\/CDB19\/users01CDB19.dbf \/u90\/open\/before\n\nSQL&gt; alter database end backup;\n\nDatabase altered.\n<\/code><\/pre>\n<p>I&#8217;ve taken a hot backup of this datafile. The backup mode ensures that recovery will be possible, but the file is still online, and fuzzy, with db writer writing to it. So the header stilll shows it fuzzy and with the last checkpoint SCN.<\/p>\n<pre><code>\nSQL&gt; shutdown immediate;\nDatabase closed.\nDatabase dismounted.\nORACLE instance shut down.\n\nSQL&gt; startup mount\nORACLE instance started.\n\nTotal System Global Area   2147482744 bytes\nFixed Size                    9137272 bytes\nVariable Size               520093696 bytes\nDatabase Buffers           1610612736 bytes\nRedo Buffers                  7639040 bytes\nDatabase mounted.\n<\/code><\/pre>\n<p>I&#8217;ve closed my database cleanly and started it in mount, which means not opened.<\/p>\n<pre><code>\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n   OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n____________ ______________ _____________________ __________________ ______________________\nMOUNTED                   0               1692886            1692000                1692860\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n          natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL           NO     NO     2021-04-30 10:56:41        8192 1692886             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL           NO     NO     2021-04-30 10:56:41           0 1692886             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL           NO     NO     2021-04-30 10:56:41           0 1692886             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL           NO     NO     2021-04-30 10:56:41           0 1692886             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39        8192 1692776             183 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n\n11 rows selected.\n<\/code><\/pre>\n<p>After a clean shutdown, no files are fuzzy and all files where checkpointed at the same time: SCN 1692886 that we see in v$datafile and v$datafile_header. All consistent. You can see that the PDB datafiles have a SCN a little bit earlier but this is because the PDB are closed before the database is. Exactly the same as the read-only PDB$SEED. Then checkpoint is consistent for the container but earlier than the database and the RECOVER column is null.<\/p>\n<pre><code>\nSQL&gt; host cp \/u02\/oradata\/CDB19\/users01CDB19.dbf \/u90\/close\/before\n<\/code><\/pre>\n<p>I&#8217;ve taken another backup of my datafile here, now in a non fuzzy state (like a cold backup)<\/p>\n<pre><code>\nSQL&gt; create restore point now guarantee flashback database;\nRestore point NOW created.\n<\/code><\/pre>\n<p>I&#8217;m taking a snapshot of my database here as I&#8217;ll come back to this point. This PIT that I call &#8216;now&#8217; is the where I&#8217;ll try to restore the datafile from backups from before (what i just did) or from after (what i&#8217;m going to do before reverting back to this snapshot)<\/p>\n<pre><code>\nSQL&gt; alter database open;\nDatabase altered.\n\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n    OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n_____________ ______________ _____________________ __________________ ______________________\nREAD WRITE           1693832               1692889            1692000                1692999\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n               natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL           NO     YES    2021-04-30 11:03:00        8196 1692889             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL           NO     YES    2021-04-30 11:03:00           4 1692889             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL           NO     YES    2021-04-30 11:03:00           4 1692889             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL           NO     YES    2021-04-30 11:03:00           4 1692889             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39        8192 1692776             183 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n\n11 rows selected.\n\nSQL&gt; alter system checkpoint;\n\nSystem CHECKPOINT altered.\n\nSQL&gt; alter database begin backup;\n\nDatabase altered.\n\nSQL&gt; host cp \/u02\/oradata\/CDB19\/users01CDB19.dbf \/u90\/open\/after\n\nSQL&gt; alter database end backup;\n<\/code><\/pre>\n<p>Same as I did before, a hot backup of my datafile, but from a later point in time.<\/p>\n<pre><code>\nDatabase altered.\n\nSQL&gt; shutdown immediate;\nDatabase closed.\nDatabase dismounted.\nORACLE instance shut down.\n\nSQL&gt; startup mount\nORACLE instance started.\n\nTotal System Global Area   2147482744 bytes\nFixed Size                    9137272 bytes\nVariable Size               520093696 bytes\nDatabase Buffers           1610612736 bytes\nRedo Buffers                  7639040 bytes\nDatabase mounted.\n\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n   OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n____________ ______________ _____________________ __________________ ______________________\nMOUNTED                   0               1694252            1692000                1693891\n\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n     natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL           NO     NO     2021-04-30 11:05:43        8192 1694252             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL           NO     NO     2021-04-30 11:05:43           0 1694252             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL           NO     NO     2021-04-30 11:05:43           0 1694252             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL           NO     NO     2021-04-30 11:05:43           0 1694252             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39        8192 1692776             183 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n\nSQL&gt; host cp \/u02\/oradata\/CDB19\/users01CDB19.dbf \/u90\/close\/after\n<\/code><\/pre>\n<p>And finally a cold backup from a later point in time.<\/p>\n<pre><code>\nSQL&gt; host ls -l \/u90\/{close,open}\/{before,after}\n\/u90\/close\/after:\ntotal 5140\n-rw-r-----. 1 oracle oinstall 5251072 Apr 30 11:07 users01CDB19.dbf\n\n\/u90\/close\/before:\ntotal 5140\n-rw-r-----. 1 oracle oinstall 5251072 Apr 30 11:00 users01CDB19.dbf\n\n\/u90\/open\/after:\ntotal 5140\n-rw-r-----. 1 oracle oinstall 5251072 Apr 30 11:05 users01CDB19.dbf\n\n\/u90\/open\/before:\ntotal 5140\n-rw-r-----. 1 oracle oinstall 5251072 Apr 30 10:55 users01CDB19.dbf\n<\/code><\/pre>\n<p>I have 4 backups, from before and after, and in a clean or fuzzy state.<\/p>\n<pre><code>\nSQL&gt; flashback database to restore point now;\n\nFlashback succeeded.\n<\/code><\/pre>\n<p>Now back to my snapshot so that my current state is after the &#8216;before&#8217; backup and before the &#8216;after&#8217; backup. Sorry for this bad description of it, time travel is never easy to explain.<\/p>\n<pre><code>\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n   OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n____________ ______________ _____________________ __________________ ______________________\nMOUNTED                   0               1694252            1692000                1692886\n\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n     natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41        8192 1692886             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39        8192 1692776             183 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 10:56:39           0 1692776             183 0\n11 rows selected.\n<\/code><\/pre>\n<p>So, here we are. In closed (mount) state. No files are opened, No files are fuzzy. The checkpoint time is consistent &#8211; we will check only the CDB$ROOT now as we know the other containers where checkpointed earlier when closed. So CDB$ROOT checkpoint is at 10:56:41, SCN 1692886, which matches the controlfile SCN. I can OPEN RESETLOGS this database without any recovery but that&#8217;s not what I want to show.<\/p>\n<pre><code>\nSQL&gt; host cp \/u90\/open\/before\/users01CDB19.dbf \/u02\/oradata\/CDB19\/users01CDB19.dbf\n<\/code><\/pre>\n<p>I restored the datafile from the previous hot backup (older than my current state, and fuzzy)<\/p>\n<pre><code>\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n  2* natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41        8192 1692886             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL                  YES    2021-04-30 10:53:23           1 1692602             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 11:11:00        8192 1692776               1 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 11:11:00           0 1692776               1 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 11:11:00           0 1692776               1 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 11:11:00           0 1692776               1 0\n\n11 rows selected.\n<\/code><\/pre>\n<p>The file header shows the fuzzy state (FUZZY=Y) and this means that Oracle needs to apply some redo log, starting from the checkpoint SCN 1692602 and until it brings it to a consistent state, at least after the END BACKUP, to the end of fuzziness.<\/p>\n<pre><code>\nSQL&gt; alter database open resetlogs;\n\nError starting at line : 1 in command -\nalter database open resetlogs\nError report -\nORA-01195: online backup of file 7 needs more recovery to be consistent\nORA-01110: data file 7: '\/u02\/oradata\/CDB19\/users01CDB19.dbf'\n01195. 00000 -  \"online backup of file %s needs more recovery to be consistent\"\n*Cause:    An incomplete recovery session was started, but an insufficient\n           number of logs were applied to make the file consistent. The\n           reported file is an online backup which must be recovered to the\n           time the backup ended.\n*Action:   Either apply more logs until the file is consistent or\n           restore the database files from an older backup and repeat recovery.\nSQL&gt;\n<\/code><\/pre>\n<p>I&#8217;ll not do this recovery. I&#8217;m just showing the error message. This is ORA-01195 that tells you you need more recovery to clear the fuzziness.<\/p>\n<pre><code>\nSQL&gt; host cp \/u90\/close\/before\/users01CDB19.dbf \/u02\/oradata\/CDB19\/users01CDB19.dbf\n<\/code><\/pre>\n<p>I&#8217;ve restored from the cold backup here. So no fuzzy flag in the header.<\/p>\n<pre><code>\nSQL&gt; alter database open resetlogs;\n\nDatabase altered.\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n  2* natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL           NO     YES    2021-04-30 11:48:42        8196 1692890               1 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL           NO     YES    2021-04-30 11:48:42           4 1692890               1 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL           NO     YES    2021-04-30 11:48:42           4 1692890               1 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL           NO     YES    2021-04-30 11:48:42           4 1692890               1 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 11:48:45        8192 1693089               1 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 11:48:45           0 1693089               1 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 11:48:45           0 1693089               1 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 11:48:45           0 1693089               1 0\n\n11 rows selected.\n\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n    OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n_____________ ______________ _____________________ __________________ ______________________\nREAD WRITE           1694039               1692890                  0                1693104\n<\/code><\/pre>\n<p>From this cold backup, I was able to OPEN RESETLOGS. Because this cold backup was taken when the database was closed, so all are consistent.<\/p>\n<p>This was to show the ORA-01195 meaning: a datafile needs to be recovered to be consistent by itself.<\/p>\n<p>Now we will see the consistency with the other datafiles by restoring a backup from the future.<\/p>\n<pre><code>\nSQL&gt; shutdown immediate;\nDatabase closed.\nDatabase dismounted.\nORACLE instance shut down.\nSQL&gt; startup mount\nORACLE instance started.\n\nTotal System Global Area   2147482744 bytes\nFixed Size                    9137272 bytes\nVariable Size               520093696 bytes\nDatabase Buffers           1610612736 bytes\nRedo Buffers                  7639040 bytes\nDatabase mounted.\nSQL&gt; flashback database to restore point now;\n\nFlashback succeeded.\n\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n   OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n____________ ______________ _____________________ __________________ ______________________\nMOUNTED                   0               1694381                  0                1692886\n\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n     natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41        8192 1692886             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 11:48:35        8192 1692776               1 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n\n11 rows selected.\n<\/code><\/pre>\n<p>as my OPEN RESETLOGS was sucessfull, I flashback database again to go to the same point in time for my experiment.<\/p>\n<pre><code>\nSQL&gt; host cp \/u90\/close\/after\/users01CDB19.dbf \/u02\/oradata\/CDB19\/users01CDB19.dbf\n<\/code><\/pre>\n<p>I&#8217;ve restored the cold backup (not fuzzy) but from a checkpoint that happened after my current state.<\/p>\n<pre><code>\nSQL&gt; select * from (select file#,name,substr(status,1,3) sta,error err,recover rec,fuzzy fuz,checkpoint_time checkpoint from v$datafile_header)\n     natural join (select hxfil file#, fhsta, fhscn, fhrba_seq, fhafs from x$kcvfhall);\n\n   FILE#                                             NAME    STA    ERR    REC    FUZ             CHECKPOINT    FHSTA      FHSCN    FHRBA_SEQ    FHAFS\n________ ________________________________________________ ______ ______ ______ ______ ______________________ ________ __________ ____________ ________\n       1 \/u02\/oradata\/CDB19\/system01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41        8192 1692886             183 0\n       2 \/u02\/oradata\/CDB19\/pdbseed\/system01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21        8192 1276435              17 0\n       3 \/u02\/oradata\/CDB19\/sysaux01CDB19.dbf             ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       4 \/u02\/oradata\/CDB19\/pdbseed\/sysaux01CDB19.dbf     ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       5 \/u02\/oradata\/CDB19\/undotbs01CDB19.dbf            ONL                  NO     2021-04-30 10:56:41           0 1692886             183 0\n       6 \/u02\/oradata\/CDB19\/pdbseed\/undotbs01CDB19.dbf    ONL                  NO     2019-08-05 17:03:21           0 1276435              17 0\n       7 \/u02\/oradata\/CDB19\/users01CDB19.dbf              ONL                  NO     2021-04-30 11:05:43           0 1694252             183 0\n       8 \/u02\/oradata\/CDB19\/PDB\/system01CDB19.dbf         ONL                  NO     2021-04-30 11:48:35        8192 1692776               1 0\n       9 \/u02\/oradata\/CDB19\/PDB\/sysaux01CDB19.dbf         ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n      10 \/u02\/oradata\/CDB19\/PDB\/undotbs01CDB19.dbf        ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n      11 \/u02\/oradata\/CDB19\/PDB\/users01.dbf               ONL                  NO     2021-04-30 11:48:35           0 1692776               1 0\n\n11 rows selected.\n\nSQL&gt; select open_mode,current_scn,checkpoint_change#,archive_change#,controlfile_change# from v$database;\n\n   OPEN_MODE    CURRENT_SCN    CHECKPOINT_CHANGE#    ARCHIVE_CHANGE#    CONTROLFILE_CHANGE#\n____________ ______________ _____________________ __________________ ______________________\nMOUNTED                   0               1694381                  0                1692886\n\n<\/code><\/pre>\n<p>You can see the datafile is not fuzzy but with a checkpoint at 11:05:43, SCN 1694252, where all other datafiles, for this container, and the controlfile, are at 10:56:41, SCN 1692886. My file is from a state in the future of the other ones.<\/p>\n<pre><code>\nSQL&gt; alter database open resetlogs;\n\nError starting at line : 1 in command -\nalter database open resetlogs\nError report -\nORA-01152: file 7 was not restored from a sufficiently old backup\nORA-01110: data file 7: '\/u02\/oradata\/CDB19\/users01CDB19.dbf'\n01152. 00000 -  \"file %s was not restored from a sufficiently old backup \"\n*Cause:    An incomplete recovery session was started, but an insufficient\n           number of logs were applied to make the database consistent. This\n           file is still in the future of the last log applied. The most\n           likely cause of this error is forgetting to restore the file\n           from a backup before doing incomplete recovery.\n*Action:   Either apply more logs until the database is consistent or\n           restore the database file from an older backup and repeat recovery.\n<\/code><\/pre>\n<p>Here is ORA-01152 and the message may be misleading because there can be several reasons. Maybe the problem is the file mentioned, because you restored it from a backup that is too recent when compared to the others and to the point in time you want to open resetlogs. Or maybe it was not restored at all and it is the current datafile that remains there because you forgot to restore one file. Or maybe you want to go to a further point in time by recovering the other datafile up to the same PIT as this one.<\/p>\n<p>I&#8217;ll not go further here, this blog post is already too long. Of course, I&#8217;ll get the same error if I restore the fuzzy backup from the future. When you encounter this error you may think about the Point In Time you want to recover to. Either you have the right PIT and then you need to restore a backup of this datafile from before this point in time. Or maybe you want to recover to a further point in time to reach the state of this datafile. The error message supposes you have recovered to the right point in time but didn&#8217;t restore the right file.<\/p>\n<p>I tried to summarize this situation in a tweet:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">ORA-01152 is misleading.<br \/>The problem may be with the other files.<br \/>When I see:<br \/> ORA-01152: file <a href=\"https:\/\/twitter.com\/hashtag\/n?src=hash&amp;ref_src=twsrc%5Etfw\">#n<\/a> was not restored from a sufficiently old backup<br \/>I think of <a href=\"https:\/\/twitter.com\/hashtag\/n?src=hash&amp;ref_src=twsrc%5Etfw\">#n<\/a> as Marty McFly telling the other datafiles:<br \/> Guess you guys aren&#39;t ready for that yet\u2026<\/p>\n<p>(is it clear or should I blog?)<\/p>\n<p>&mdash; Franck Pachot (@FranckPachot) <a href=\"https:\/\/twitter.com\/FranckPachot\/status\/1388130205479456781?ref_src=twsrc%5Etfw\">April 30, 2021<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><br \/>\n<a href=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-medium wp-image-49542\" src=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif\" alt=\"\" width=\"300\" height=\"162\" \/><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . Oracle Error: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file &#8230; was not restored from a sufficiently old backup ORA-01110: data file &#8230; This error is one of the most misunderstood recovery error. It can happen in different case but I have here a simple example [&hellip;]<\/p>\n","protected":false},"author":27,"featured_media":16291,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[2329,96,226],"type_dbi":[],"class_list":["post-16290","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oracle","tag-backup-resetlogs","tag-oracle","tag-recovery"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.5) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>An example of ORA-01152: file ... was not restored from a sufficiently old backup - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"An example of ORA-01152: file ... was not restored from a sufficiently old backup\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . Oracle Error: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file ... was not restored from a sufficiently old backup ORA-01110: data file ... This error is one of the most misunderstood recovery error. It can happen in different case but I have here a simple example [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2021-04-30T13:00:29+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif\" \/>\n\t<meta property=\"og:image:width\" content=\"500\" \/>\n\t<meta property=\"og:image:height\" content=\"270\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/gif\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"21 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"An example of ORA-01152: file &#8230; was not restored from a sufficiently old backup\",\"datePublished\":\"2021-04-30T13:00:29+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/\"},\"wordCount\":1826,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/upFpIkQ.gif\",\"keywords\":[\"backup resetlogs\",\"Oracle\",\"Recovery\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/\",\"name\":\"An example of ORA-01152: file ... was not restored from a sufficiently old backup - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/upFpIkQ.gif\",\"datePublished\":\"2021-04-30T13:00:29+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/upFpIkQ.gif\",\"contentUrl\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/wp-content\\\/uploads\\\/sites\\\/2\\\/2022\\\/04\\\/upFpIkQ.gif\",\"width\":500,\"height\":270},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"An example of ORA-01152: file &#8230; was not restored from a sufficiently old backup\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/oracle-team\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"An example of ORA-01152: file ... was not restored from a sufficiently old backup - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/","og_locale":"en_US","og_type":"article","og_title":"An example of ORA-01152: file ... was not restored from a sufficiently old backup","og_description":"By Franck Pachot . Oracle Error: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file ... was not restored from a sufficiently old backup ORA-01110: data file ... This error is one of the most misunderstood recovery error. It can happen in different case but I have here a simple example [&hellip;]","og_url":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/","og_site_name":"dbi Blog","article_published_time":"2021-04-30T13:00:29+00:00","og_image":[{"width":500,"height":270,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif","type":"image\/gif"}],"author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"21 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"An example of ORA-01152: file &#8230; was not restored from a sufficiently old backup","datePublished":"2021-04-30T13:00:29+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/"},"wordCount":1826,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif","keywords":["backup resetlogs","Oracle","Recovery"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/","url":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/","name":"An example of ORA-01152: file ... was not restored from a sufficiently old backup - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif","datePublished":"2021-04-30T13:00:29+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/upFpIkQ.gif","width":500,"height":270},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/an-example-of-ora-01152-file-was-not-restored-from-a-sufficiently-old-backup\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"An example of ORA-01152: file &#8230; was not restored from a sufficiently old backup"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/16290","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=16290"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/16290\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/16291"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=16290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=16290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=16290"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=16290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}