Re: Split Blocks on Instance Crash

From: Charlotte Hammond <charlottejanehammond_at_yahoo.com>
Date: 2005-12-23 11:06:23
Message-id: 20051223100623.97745.qmail@web33114.mail.mud.yahoo.com

Thanks Jared - sorry, I was being lazy with my words - I should have said "avoid problems with split blocks" rather than "split blocks".

Tanel has provided an excellent description of the crash recovery mechanism but I'm still slightly puzzled:

During backup this BEGIN/END BACKUP mechanism is necessary as DBWR Oracle-block writes translate into multiple OS-blocks. A non-database aware backup mechanism (eg. unix "cp") may be operating concurrently on the same part of the disk and take some pre-write OS-blocks and some post-write OS-blocks resulting in a split Oracle block.

Now, I can't see how this really differs from a failed OS-write due to a crash again leaving some pre-change OS-blocks and some post-change OS-blocks on disk. But now without the blocks-in-the-redo-stream mechanism to allow for recovery.

For clarification, is this not a problem because:

I wasn't clear what I meant by "crash" - not just an instance crash where, yes, the operating system call should complete successfully even if the instance has died, completing all necessary OS-block writes necessary for a Oracle-block write. What I really meant was an O/S or a hardware crash where all OS-block writes do not complete due to a sudden lost of i/o service. In this case is it reasonable to expect that split blocks DO appear on disk, there is no block-in-the-redo-stream to cope with this, and that split blocks / media corruption may be possible on restart?
That, as I mentioned in a previous mail, such a "crash" happens so quickly compared to the long interaction with a backup, that an OS/hardware crash interrupting a DBWR call such that it only partially completes is far, far less likely than cp trying to read blocks at the same time as they are being written during a backup?

Apologies for dragging my confusion on to tortourous levels - if I don't get it this time I promise to go away and think about it some more and not bother you all until next year :-)

Thanks!

Charlotte

Jared Still wrote:

> BEGIN/END does not avoid split blocks.
> It merely caused the generation of more redo to
> recover from split blocks.
>
> From the Oracle Recovery Manager Users Guide, in the
> section on Fractured
> Blocks:
>
> When performing open backups *without* using RMAN,
> you must put tablespaces
> in *backup mode* in case the operating system reads
> a block for a backup
> that is currently being written by the database
> writer. When not in backup
> mode, Oracle records only changed bytes in the redo
> stream, not whole
> blocks. When a tablespace is in backup mode, Oracle
> writes the before-image
> of each changed block in the tablespace to the redo
> log before modifying it.
> Then, Oracle also records the changes to the block
> in the redo log. When you
> recover using SQL*Plus, Oracle applies the blocks
> and changes during
> recovery, so it does not matter that the block in
> the backup was fractured.
>
> HTH
>
> Jared
>
>
> On 12/22/05, Charlotte Hammond
> wrote:
> >
> >
> > Thanks David - but why is this different from the
> > backup situation? You would have the (archived)
> redo
> > available then too, but you must still use
> BEGIN/END
> > BACKUP to avoid split blocks.
> >
> > Charlotte
> >
> >
> >
> > --- David Sharples
> wrote:
> >
> > > because the information is available from redo /
> > > undo and can easily be
> > > replayed in case of a failure
> > >
> > > On 12/22/05, Charlotte Hammond
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Why does instance crash recovery not encounter
> the
> > > > split blocks that you might get doing a backup
> > > without
> > > > BEGIN/END BACKUP?
> > > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> > --
> > http://www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>

Jared Still wrote:

Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Dec 23 2005 - 11:06:23 CST