Re: Recovery possible!

A copy of this was sent to "Mark Malakanov" <markmal_at_sprint.ca> (if that email address didn't require changing) On Sat, 3 Jul 1999 19:38:42 -0300, you wrote:

>Hi Thomas.
>
>I made your sample. During 20 minutes, of cource. I dont wait for 3 days :^)
>
>1. Shutdown instance using SHUTDOWN ABORT.
>2. Copy datafiles (controlfiles and redo logs too, if you will right :^) to
>a backup folder.
> Pay attention! - "Dirty" backup!
>3. Startup Oracle. - everything well
>4. Work for a little as Scott. Create table and insert some data to one with
>commit.
> Inser second portion without commit.
>5. Kill Oracle80 task using Task Manager. (Failure model)
>6. Rename usr1orcl.ora file (User_data tablespace) to usr1orcl.or~
>7. Copy old "dirty" backuped usr1orcl.ora from backup folder to database.
>8. Try to start Oracle. Of cource one ask me to recover datafile.
>9. Svrmgr screenshot followed:
>...
>Database mounted.
>ORA-01113: file 2 needs media recovery
>ORA-01110: data file 2: 'C:\ORAWIN95\DATABASE\USR1ORCL.ORA'
>SVRMGR> recover datafile 2;
>ORA-00279: change 255084 generated at 07/03/99 18:33:47 needed for thread 1
>ORA-00289: suggestion :
>C:\ORAWIN95\DATABASE\ARCHIVE\ORCLT0001S0000000500.ARC
>ORA-00280: change 255084 for thread 1 is in sequence #500
> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
>Log applied.
>Media recovery complete.
>SVRMGR> alter database open;
>Statement processed.
>

You did it once (you can probably do it again and again), you feel confident it will work. (unfortunately, others reading this post might get the same idea). The problem is it will work in a lot of cases but not in ALL cases.

Backup and recovery is something you want to do correctly, you want to do right and you want it to work when you need it to. You do not want to backup shutdown aborted databases. There is no reason to and it is risky at best.

Here is the one counter case that demonstrates at least ONE reason why a backup of an aborted instance is not sufficient for recovery in some cases.

When you do a hot backup of an Oracle datafile, we generate more redo log information then usual. This extra information is a full block image of the affected block the first time a change is encountered on it (when in hot backup, instead of just logging vector changes, we log the block the first time). Why do we do this? We do this because while you are copying the file to a backup tape, we are still writing to the file. There is an opportunity then for the following to occurr:

o your backup program is reading block #1 from file #1 -- your blocksize is 8k, the OS reads 2k at a time.

o Your backup program read 4k of block #1 and gets interupted at the OS level.

o We are doing a checkpoint right now and flushing blocks to disk. We rewrite block #1 in file #1. We complete.

Your backup resumes and reads the last 4k of block #1. What is has is worse then a fuzzy block -- it has a block whos head does not match its tail. We make special consideration for that event and log a full block. We need this for media recovery if we encounter such a block. When we hit a fractured block in a backup set, we don't apply vector changes to the block from the redo until we find the 'full block' we logged -- then we apply the vector changes.

Instance recovery ( from a crash ) doesn't do this -- the log files have change vectors only, not the full blocks (instance recovery and media recovery are done very differently - very differently).

So, you backup an aborted instance. The blocks on the disk in the datafiles may very well suffer from the problem -- halfway through a write for example, the instance was terminated (killed by the abort). We can get blocks that are alot like a hot backup block *but we have not generated the extra redo information for this case* into our redo logs. Without this extra redo -- when using MEDIA recovery, we cannot recover. Data lost....

In an instance recovery (you are recovering the entire database -- not just a small portion) application of all of the redo, followed by processing of the undo we just rolled forward, fixes things. In media recovery, we don't do it that way -- we don't apply all of the redo to all of the files and rollback -- we selectively apply redo in a much different manner. Media recovery of individual file(s) cannot deal with this issue, hence the different logging mode.

It might work for you 99 times (backing up aborted instances) but it will be that 100'th time (when you really really need it to work) that this case pops up. Recovery of that file will just not be possible as it looks alot like a hot backup file (not quite but close enough) but the special procedures that are in place during a hot backup are not in place -- we will never find that full block image to recover with.

Here is the bottom line: don't do it. There is no reason to, its a bad idea, its not the way to do it.

>So, as you see everithig OK. You can use "dirty" backup - backup after
>abort.
>You can check it yourself.
>But I don't bring people use this way. "Shutdown Normal" is better of
>cource.
>I use hot backup on my production database.
>
>Note: If your database in NOARCHIVELOG you have to save (and recover) all
>set of Oracle files (datafiles, redo log files, controlfiles) any way, you
>use "clean" backup or "dirty".
>But In case of "dirty" backup you MUST recover redolog files because an
>information about data changies is inside this only. In case of "clean"
>backup information about data changies is already flushed into datafiles and
>you can recreate redo-logs anew, this useless now.
>
>Regards,
>Mark
>

--
See http://govt.us.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Sun Jul 04 1999 - 11:35:00 CDT