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 DBAhttp://mgogala.freehostia.com
