It seems, that Mark W. Farnham's reply didn't get into the list, so I'll
quote his valuable response.
Probably, things have changed in some way at least starting from 9i. Now
there is always an extra block at the beginning of each datafile (so called
"zero" block) with some info about platform, actual file size etc, so the
total file size is BLOCKS+1.
I've dumped the last block before and after "begin backup", with
checkpoint and log switch - nothing was changed there and the datafile size
was not changed either.
HTH
- Andrey
Mark W. Farnham wrote:
All versions I'm aware of, though I haven't dumped the end of a 10g, and
maybe not a 9i, either.
If you create a datafile, you'll probably notice that the size on disk is
at least 1 datablock size larger than you asked for. The very last OS set of
blocks adding up to the database block size is the same as the very first
one, except for a few key values that get resynchronized at checkpoints if I
remember correctly. If I recall correctly one of the values in these blocks
is also whether the tablespace was in backup. Prior to being able to lie to
the database with a command and "end backup" (intended really not for copies
of datafiles, but the current datafiles which cannot be block fractured in
the case that the database crashes while in backup mode), you had to
manually adjust that ending shadow end of the file block or Oracle would
still know something was "wrong" with the file.
This is also the reason why you have to make raw partitions a little
bigger than the datafile you want to create there. I always thought it was
funny (strange, odd sense of funny) that Oracle gave you one block less than
the create size and took up one block more than the create size.
If someone remembers the precise details of which programs update these
blocks and under what conditions, and is free to disclose it, I'd enjoy
reading that as well.
In the case below, if DB writer is suspended for the split and the plex
split operation generates a clean copy (note that that engineering detail is
not necessarily required if the volume manager is only promising that the
plexes remaining associated with the volume are identical, and there is
possibly extra work flushing things at split time), then you're not going to
have fracture blocks.
You get fractured blocks when an OS utility copying OS sectors (usually
512 bytes) ends a particular read in the middle of an Oracle block and then
the database writer writes the Oracle block before the next OS read starts.
Regards,
mwf
-----Original Message-----
*From:* oracle-l-bounce@xxxxxxxxxxxxx [
mailto:oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>]*On
Behalf Of *Andrey Kriushin
*Sent:* Thursday, May 25, 2006 10:05 AM
*To:* mwf@xxxxxxxx
*Cc:* Oracle-L Freelists
*Subject:* Re: Restore and Recover Fuzzy datafiles
Never heard of "ending block". What version it was then? Mark, could you,
please, clarify?
[skipped]
TIA
- Andrey
Mark W. Farnham wrote:
Before you could tell the database to "end" backup, you also had to patch
the beginning and ending blocks of the file (lie to Oracle) so that Oracle
did not consider the file to be "fuzzy," but I doubt you're working with a
vintage of the Oracle software that old. If you are, you'll need some kind
of binary block editor.
