Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Split Blocks on Instance Crash, different issue for OS HW/SW failure in crash

RE: Split Blocks on Instance Crash, different issue for OS HW/SW failure in crash

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: 2005-12-23 11:51:04
Message-id: KNEIIDHFLNJDHOOCFCDKAEMBHGAA.mwf@rsiz.com


I'll take a pass at summarizing:

  1. As Tanel mentioned, if there is no OS HW/SW fault, and the quite unlikely event that DBWR dying itself in the middle of a write request is not what kills the instance, you're just not going to have fractured blocks on the live (ie. non-backup) images of Oracle blocks on disk.
  2. If the OS crashes, you can indeed get a broken file due to an incompletely written block. Then Oracle tells you that one or more files need media recovery. This is indeed lots less frequent, even in an OS crash, because the Oracle i/o requests are based on (dirty) integral Oracle blocks, whatever the component OS blocks may be. The details of your write intensity and the elevator algorithms of our particular disk farm probably affect whether you ever see something like this, as well as the details of your RAID processing. The key point is that Oracle will notice and tell you if it has a problem from the OS crash when you are restarting the instance. As instance recovery proceeds and you get a piece of redo to apply, it checks whether the vintage of the first and last OS level pieces of the block match. If they don't, and the file is not currently in backup, it will complain.
  3. Old style physical backups routinely have fractured blocks on the backup copy because the OS level copy usually has no clue at all that certain OS level 512 byte (or whatever size) sectors together make up an Oracle block. Putting a tablespace in "backup" causes the next block change for a given block of a file that is a component of a tablespace in backup to be written in its entirety to redo. (And don't be confused by the sentence in some versions of the manuals that make it sound like every block of the file gets written to redo, it is just the blocks that change during the backup and just the first time a given block changes during the backup.) So the fractured blocks are replaced by the redo if you recover from a backup. Since the blocks are not fractured (except by OS based damage) on the non backup image, this is the reason that if you crash during backup you can end the backup and only instance recovery is required on the original image of the Oracle file.
  4. RMAN reads integral Oracle blocks, so there are no fractured blocks on an RMAN backup and no extra redo is required.

Any quibbles or even slight corrections welcome.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Charlotte Hammond Sent: Friday, December 23, 2005 5:06 AM
To: oracle-l_at_freelists.org
Subject: Re: Split Blocks on Instance Crash

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:

  1. 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?
  2. 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

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

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



Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
--
http://www.freelists.org/webpage/oracle-l



--
http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 23 2005 - 11:51:04 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US