Re: Split Blocks on Instance Crash

  • From: Tanel Põder <tanel.poder.003@xxxxxxx>
  • To: "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 22 Dec 2005 12:58:53 -0600

Hi,

So the risk goes way, way down. I'd quibble slightly with Tanel's "always"
remark. If you restart and it tells you media recovery is required, then a
file really did get crashed and one of the cases of

Yep, as Tom Kyte says "Never say never, never say always, I always say" :)

But my point here is that you don't get fractured blocks if instance crashes due "it's own reasons", like shutdown abort, kill or some ora-600. As long as the write request is safely sent to OS *and* OS and hardware themselves perform adequately, the whole blocks are sent to disk causing no fracturing issues here (because Oracle doesn't split datablock IO to match filesystem or rawdevice block sizes as you already mentioned).

What happens afterwards is matter of OS or hardware, if it functions ok, no problems, if it doesn't function OK *and* an instance crash happens the same time (could be caused by OS/HW dysfunction) then we are in trouble.

a file getting trashed is that it is not marked fuzzy and a block's header
and tail don't match. Then you would have to get a previous backup of the
file (or block) and roll it forward. So the recovery is just the same as if

A datafile in read-write tablespace should be marked fuzzy from the moment it's brought online.


In practice, I've seen such unexplained corruption issues few times too, which I've eventually had to explain as "probably a single occurrence an unknown hardware or software error".

Tanel.
P.S. RMAN pins the buffer for duration of copy, so fractured blocks are a non-issue here (thus RMAN doesn't require full blocks to be logged during backup)



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


Other related posts: