Re: Restore and Recover Fuzzy datafiles

Hi guys, thanks for the reply here are the result

I used _allow_resetlogs_corruption

recreate the controlfile

open resetlogs

now I have ORA-01092 (search metalink only hit 2 results)

is upgraded 9i from 8i on W2K

still searching for solution

On 5/26/06, Andrey Kriushin <Andrey.Kriushin_at_rdtex.ru> wrote:
>
> 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_at_freelists.org [
> mailto:oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>]*On
> Behalf Of *Andrey Kriushin
> *Sent:* Thursday, May 25, 2006 10:05 AM
> *To:* mwf_at_rsiz.com
> *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.
>
>

-- 
regards,

Sinardy

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