RE: Hot backup question
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <yong321@xxxxxxxxx>, <William.Blanchard@xxxxxxxxxxxxx>
- Date: Mon, 27 Sep 2010 16:47:59 -0400
In answer to your question, this would only be true if the os utility
program strictly obeyed the logical block at a time i/o. So, for example, if
you were able to guarantee that the 16 512 byte pieces that make up an
Oracle 8KB block were exactly aligned with the file system's view of the
same 8KB piece, even then nothing would prevent a utility like dd from being
used at a particular buffer size such that it read ending mid logical block
for one of its chunks, then an Oracle block write happened, and then dd
continued beginning with the rest of that logical block (but a later version
of the block), and just like that you get a "fractured" block on the backup
media.
Having one full copy of such a block in the required redo period of the
duration of the tablespace "hot" backup window plus any subsequent vector
changes means Oracle never has to rely on db blocks copied at the OS level
during hot backup for blocks that changed during the backup.
I think you are also correct that there is no general read lockout atomicity
between Oracle dbwr writes and OS level utility program reads. I guess the
point is that Oracle's "physical" backup protocol does not require this.
And of course any blocks that didn't change are just fine.
And thanks for replaying the "whole block once" detail. I tend to like my
backups to be like "belts and braces," meaning two completely different
types of force. The belt is basically a friction fitting that won't allow
your pants to fall. Braces are a positive hookup from the buttons on the
waistbands suspended over your shoulders (ergo the new world moniker
"suspenders").
So while RMAN is more efficient, reads Oracle blocks conclusively, and can
usually find the pieces you need for you, you are counting on Oracle's
having no fatal flaw in logic in performing the recovery. If you also have a
periodic hot backup and the intervening archived redo logs, you'd still be
able to get everything back.
Of course nothing is foolproof.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Yong Huang
Sent: Saturday, September 25, 2010 3:02 PM
To: William.Blanchard@xxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Hot backup question
<snip>
To borrow this thread, I have some unproved thought on this. Has anybody
considered the possibility of split blocks if the file system I/O chunk size
(commonly called file system block size) is the same as db_block_size?
Various sources always seem to use mismatch of the two sizes as an example
to explain split blocks. I think there's still a danger unless DBWn and OS
tool can write and read, respectively, to the same block at the same moment.
But it's possible when the two sizes match, the probability of split blocks
is reduced. This of course assumes the datafile is on a file system.
Yong Huang
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
