Re: split block (torn page) problem

  • From: Riyaj Shamsudeen <riyaj.shamsudeen@xxxxxxxxx>
  • To: Laimutis.Nedzinskas@xxxxxx
  • Date: Tue, 6 Dec 2011 18:22:43 +0530

There will be corruption in this case as the head and tail piece of the
block might not match etc. So, there would be a need for block media
recovery or restore snf recovery to repair that corrupt block. Simply, this
is a corruption induced by hardware problem.

Riyaj Shamsudeen
Principal DBA,
Ora!nternals - - Specialists in Performance,
OakTable member and Oracle ACE Director

Co-author of the books: Expert Oracle
Pro Oracle SQL,  Expert PL/SQL

On Tue, Dec 6, 2011 at 2:38 PM, <Laimutis.Nedzinskas@xxxxxx> wrote:

> Hi
> Recently people blogged about very basic, core oracle functionality and
> issues with durability and isolation here:
> Now I have a similar basic question about split block (torn page) problem.
> According to
>  EMC has a (separately licensed) feature Generic SafeWrite which "is used
> to help protect critical application from incurring an incomplete write,
> and subsequent torn page, due to a failure within a component"
> The question is what happens when:
> - Oracle dbwr(or foreground process for that matter) issues a single IO
> kernel call to write 8k block into a datafile
> - the first 4k are written successfully and the next 4k fails, i.e. torn
> page situation arises
> - Oracle is stopped, the problem is fixed, oracle is started and attempts
> crash recovery
> - My understanding is that Oracle crash recovery can not handle
> split-block. Unless the database was in backup mode meaning full block
> image is saved in the redo stream as a starting recovery point. I can only
> speculate the whole 8k image is so important because crash recovery needs
> datafile block sturctures like row directory (may be ITL's too ?) to be in
> a good shape.
> - Basically, is it so that Oracle relies on hardware atomicity with respect
> to 8k(or whatever block size) IO calls ? Is it so that the whole 8k block
> must be stored or nothing?
> Brgds, Laimis N
> --
> //


Other related posts: