RE: Block media recovery with standard edition

  • From: "Diego Cutrone" <cutroned@xxxxxxxxx>
  • To: <knecht.stefan@xxxxxxxxx>, "'Jonathan Lewis'" <jonathan@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 9 Dec 2015 10:25:52 -0300

Hi Mladen, as this was just a free block that got corrupted, I wouldn’t bother
on recreating/moving anything. You would get the corruption fixed by getting g
the block reformatted. You can do that by creating a table that would use that
block (or set of corrupted blocks) and then just drop it. I’ve fixed that using
this technique. Take a look at MOS Doc ID 336133.1 for further detail.



Also resizing the df like Stefan has pointed out would take care of that too
(in case the corrupted blocks were at the very end of it)



HTH

Diego



From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Stefan Knecht
Sent: Wednesday, December 09, 2015 7:59 AM
To: Jonathan Lewis
Cc: oracle-l-freelists
Subject: Re: Block media recovery with standard edition



Good question. I hadn't looked into it further, but I guess that that's
possible. Begs the question, though, why it would be reported corrupt in that
case.



On Wed, Dec 9, 2015 at 3:58 PM, Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
wrote:



Interesting point. Was it so close to the end of the file that it was a block
that could never be included in a usable extent ?

Sent from my iPad


On 9 Dec 2015, at 08:32, Stefan Knecht <knecht.stefan@xxxxxxxxx> wrote:

This sounds like a very similar case I've had a few times recently. Corrupt
block in unallocated extent at the end of the file. We just resized the file to
just under that block_id, which cleared it too.



Stefan





On Wed, Dec 9, 2015 at 11:26 AM, Mladen Gogala <gogala.mladen@xxxxxxxxx> wrote:

On 12/08/2015 06:53 PM, Andrew Kerber wrote:

Do you have a time when you could safely move the indexes to a new table space?
Then drop the tablespace.


Thanks Andrew! That was a good idea. However, the time was of the essence, so I
had to be a bit more creative. I used "backup as copy datafile 36", then
switched to the copy and lo and behold, the corrupt blocks were absent from the
copy. The only thing left was to drop the original copy of datafile, copy the
correct one back from +FRA to +DATA and switch back to the +DATA diskgroup.
Essentially, "backup as copy" seems to eliminate the corrupt empty blocks. I
learned something tonight.
Regards





--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com





Other related posts: