Skip to Content

Recovery backup prior the last and all following log until last minute

Hi Guru,

The scenario is the following:

I must recover the db from a full backup prior the last full backup. The last backup was damaged. In order to recover until the last second I must restore the prior backup and the log between this backup and the last, and all log following the last bakup. The restore is without initialization, so the log area is also restored into the database. During the procedure I don't find this procedure. I'm able to recovert until last second only with initialization, or restore previous full backup and following log until the next full backup.


Backup full A Log1 Log2 Backup full B Log2 Log3

|__________|____|__________|__________|___| Log Area: 30% not saved

| |

Sucessfull Damaged

Restore chain:

Backup full A + Log1 + Log2 + Log3 + Log4 + Log Area 30% ---> System Consistent

How can I implement this scenario? I try but I have no success.

Please help me.

Thaks in advance.

Fabio Sambugaro

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    Nov 28, 2008 at 03:34 PM

    Hello Fabio,

    I think I know what is this about

    you were restoring database (without initialization) and your plan was to restore

    Backup full A + Log1 + Log2 + Log3 + Log4 + Log Area 30% ---> System Consistent

    assuming that last 30% of log entries are still in log area so you do not need to recover them from backup

    however what happed was:

    Backup full A + Log1 + Log2 + End of recovery

    and at this point recovery wizard did not ask for log3 and log4 , right ?

    the reason for this is that information from log3 and log 4 is still in log area , even thou the backup were created , this does not mean we have deleted the log area. the log area will be rewritten only once it is necessary. So if you are using autolog backup with staging area = 1/3 log area , it might be possible that you do not need last 2-3 log backup at all because the information is still in logs.



    Add comment
    10|10000 characters needed characters exceeded

    • Hi Antonio,

      > Finally I had good answers, thanks for your patience.

      You're welcome.

      > I had no clear the meaning of log area bar. Now it's all ok.

      I also find the "filling bar" counter intuitive - but I'm not the designer of this thing...

      > I test the recovery until latest state, and I think that in the log area I no longer have any information for recovery. But I don't see the log needed for restoration. I should clear the log area already saved and try the recovery in order to check if all logs shows.

      > How can I force a log area clean?

      To figure out, what information is available in the log area, use the "db_restartinfo" command.

      To clear the log area before performing a recovery, just use "recovery with initialization" - it just does this.

      best regards,


  • Nov 28, 2008 at 01:49 PM

    Hi Fabio,

    (have the user accounts become expensive or is Frighetto Antonio your alias ? 😉)

    Please use the "Restore backup from Backup-History" option in the recovery wizard to choose the second last backup.

    Be aware that there is no way to restore the log area at all!

    It doesn't matter what kind of restore you choose.

    When you use "recovery with initialization" the log area is simply cleared and its contents ignored.

    When you use just "recovery" the log area is used for the recovery - thus all necessary log entries that can be found in there are taken instead of reading them (slowly) from the log backups.

    So it might well be (depending on the amount of log generated and the size of the log area) that no log backup need to be used for a complete recovery if all log entries are still present in the log area.

    When you perfom the recovery of log backups the data is not written back to the log area, but directly read by the kernel to build up the internal redo-files that are used to 'replay' the uncommitted transactions.

    In any case: before you do anything further, perform an additional log backup right away to be sure that you don't loose unsaved log information from the log area due to some recovery 'accident' !



    Add comment
    10|10000 characters needed characters exceeded

    • Hi Lars,

      you're telling me that if I choose the backup to restore from the backup history, the log area isn't restored?

      Can I restore all the logs after this backup until the last minute? As previous example

      Backup history:

      backupA log1 log2 log3 backupB log4 log5 log6

      Restore chain:

      backupA log1 log2 log3 log4 log5 log6

      Is this scenario (Restore chain) possible? And how? Why the log area is lost?


      Fabio (no alias 😉 )