Re: Recovery possible!

Hi Thomas.

Thank you for perfect explanation. You give me really new knowledges about Oracle internals.

Sure. Backup is very serios thing.
I never use "dirty" backup myself. And I dont call people to do it. But I only interesting about why it is unpossible. Things you've told me are news for me.
I newer read about
> 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).

Where can I read more about the "log full block image at first time during hot backup"?
I always knowed only about a vector of changies in log file.

>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.

I think always Oracle doesn't write to the datafile when one in "BACKUP" state.
But you open the news to me. Where can I read about.

Or all above are "the hidden secret information" in Oracle?

Please, give me more information about above.

Thanks in advance,
Mark Malakanov

Thomas Kyte <tkyte_at_us.oracle.com> wrote in message news:378089a9.12737846_at_newshost.us.oracle.com...
> 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 - 12:09:03 CDT