RE: Block media recovery with standard edition

From: Diego Cutrone <cutroned_at_gmail.com>
Date: Wed, 9 Dec 2015 10:25:52 -0300
Message-ID: <037701d13285$22ad7fd0$68087f70$_at_com>



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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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_at_jlcomp.demon.co.uk> 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_at_gmail.com> 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_at_gmail.com> 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    

--

http://www.freelists.org/webpage/oracle-l Received on Wed Dec 09 2015 - 14:25:52 CET

Original text of this message