Mladen, could you check whether that was the very last block of the file or in
the last 1 M? My little finger tells me there might be some off by one or off
by one modolo some formatting factor size at the end of files, which would be
useful to identify to Oracle.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Stefan Knecht
Sent: Wednesday, December 09, 2015 5: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
