Re: split block (torn page) problem
Date: Thu, 8 Dec 2011 13:51:42 +0200
Message-ID: <OFB50FD015.B2DF5467-ONC2257960.003FB438-C2257960.004128AE_at_seb.lt>
> With ASM, file system caching is not involved and write calls operate on
devices. So, probability is much less with ASM.
It can be asked the other way arround. It's more than common that personal computers are crashed once and again. However disk corruptions resulting from crashes either go undetected or ... they happen very rarely. How big is the probability of disk devices corrupting blocks on writes?
My understanding would be that:
if we take battery backed disk devices then disk can pretty much guarantee that block write is atomic (fails or succeeds.) Messaging from server to disk device is no problem provided some minimal care is taken to check (or even cheksum) that disk receives a whole block.
It's interesting how big is the probability of disk block corruption for non-battery backed disks?
All that does not prevent torn(fractured) database page consisting of many blocks of course. Unless the path from server process to disk device is protected to deliver the whole db page or nothing.
brgds, Laimis N
Please consider the environment before printing this e-mail
From: Riyaj Shamsudeen <riyaj.shamsudeen_at_gmail.com>
To: Laimutis.Nedzinskas_at_seb.lt
Cc: ORACLE-L <oracle-l_at_freelists.org>
Date: 2011.12.08 07:24
Subject: Re: split block (torn page) problem
Hi
crash recovery applies redo records to roll forward the changes. If a
modified block is not written yet to the disk, that is okay, as redo
records from the log files can be used to replay the changes.
But, if the block is not written properly or fractured, then the crash
recovery will raise corruption errors and can't correct the corruption.
In enterprise servers, server reboots does not cause any corruption
(usually). From oracle point of view, a buffer is filled with block image
and I/O submitted to the OS. If the OS splits the call in to smaller chunks
(say 4K) and writes with two atomic calls underneath the write system call
(and that first 4K chunk succeeded, second 4K chunk write did not succeed),
it is possible for the corruption to occur, but it is a corner case and you
must be very unfortunate :-)
With ASM, file system caching is not involved and write calls operate on
devices. So, probability is much less with ASM.
HTH
Cheers
Riyaj Shamsudeen
Principal DBA,
Ora!nternals - http://www.orainternals.com - Specialists in Performance,
RAC and EBS
Blog: http://orainternals.wordpress.com
OakTable member http://www.oaktable.com and Oracle ACE Director
Co-author of the books: Expert Oracle
Practices<http://tinyurl.com/book-expert-oracle-practices/:>,
Pro Oracle SQL, Expert PL/SQL
Practices<http://tinyurl.com/book-expert-plsql-practices>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Dec 08 2011 - 05:51:42 CST