RE: corrupt blocks WHAT WOULD YOU DO?

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Fri, 9 Mar 2018 08:56:22 -0500
Message-ID: <001101d3b7ae$6ab0a3b0$4011eb10$_at_rsiz.com>



That’s okay. I also transposed SYSMAN to SYSAUX in my mind.    

On the drop re-install or OEM, I’d suggest recreating the SYSMAN tablespace if that is allowed. (I installed OEM maybe a decade ago a couple times and since then my clients all have that in place when I arrive or simply don’t use it, so I am beyond rust on that.) Who knows what other tools might be in SYSMAN. The rename suggestion still seems viable prior to the drop re-install unless that does a drop user. Then if you had partitioning you could use partition exchange to change the owner.  

Support might be able to tell from the bug number whether this is one of those “vampire” corrupt blocks that can suck your blood again if they come back from free extents.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Stefan Knecht Sent: Friday, March 09, 2018 8:37 AM
To: Mark W. Farnham
Cc: Howard Latham; ORACLE-L
Subject: Re: corrupt blocks WHAT WOULD YOU DO?  

Ahh thanks for pointing that out Mark. I hadn't noticed it was an IOT.  

However, I have now also seen that it's SYSMAN - SYSMAN is not part of the database at all. It's part of enterprise manager (or the agent thereof). Are we sure it's SYSMAN and not SYSAUX?  

If it's indeed SYSMAN and this is not an enterprise manager repository, then I would think it's the Database Console? Remove and reinstall it (if you're actually using it, otherwise just leave it out).      

On Fri, Mar 9, 2018 at 8:15 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

But this is a table, if I understood Howard correctly, an index organized table. An index organized table is distinct information and does not have an alternate source of data from which to be rebuilt.  

(It puzzles me that an IOT can be disabled, by the way. I wouldn’t have thought to attempt to make a table disabled.)  

I would not put the extent this corrupt block resides in the list of extents that can be allocated, so IF it is an empty table owned by an owner we can mess and it is currently named “A” I would rename it to “B” and create table “A” as select * from “B” where rownum < 1; Oh, instead of “B”, I would probably use the name “previously_A_corrupt_do_not_drop” or something else you would never drop.  

Did they give you a bug number? There are some bugs that you can prevent re-occurrence, which do not repair the “corruptness” of the existing block and such that the corrupt block being acquired for direct insert is not good.  

The original intent of the separate SYSMAN tablespace was to be stuff that *could* be re-organized (as opposed to the SYSTEM tablespace). I can’t certify that original intent was preserved.  

If this is part of one of the toolsets that can be uninstalled and re-installed, you still probably want to do the re-name before you drop that table. If this were a well understood user tablespace, I would copy everything in it to a new tablespace, drop the existing tablespace releasing the storage. Then if I needed the tablespace to be the original name, I would re-create it and copy the contents back and drop the temporary respository. (Tablespace create should not be able to replicate the “corruptness” of the block as a logical entity.)  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Stefan Knecht Sent: Thursday, March 08, 2018 7:26 AM
To: Howard Latham
Cc: ORACLE-L
Subject: Re: corrupt blocks WHAT WOULD YOU DO?  

What is the name of the object?  

I wouldn't accept Oracle's "fix" either way. If it's an index, regardless of what index it is, it can be dropped and re-created to rid of the corrupt blocks.  

Smells like they're looking for the "easy way out" here.  

Stefan      

On Thu, Mar 8, 2018 at 7:09 PM, Howard Latham <howard.latham_at_gmail.com> wrote:

RH EL 5

Oracle 11.2.0.4  

I have corrupt blocks in the sysman ts. Oracle tell me to rebuild my database. Its 1/2 TB and I don't really want the downtime.

Its in a MGMT Flow index which I don't think we use anyway and the index is disabled.

I don't have an RMAN backup old enough to repair.

What would you do?  

I do have two plans  

Turn on flashback and try dropping and recreating the objects.  

Its an IOT so cant be rebuilt online.  

Other plan - Ignore it. Does it matter?  

I seem to recall many years ago being told by Oracle to rebuild the AUD$ table index which had corrupted and caused logins to fail.  

Best Wishes  

Howard A. Latham  

-- 


//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework! Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat | _at_zztat_oracle --
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework! Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat | _at_zztat_oracle -- http://www.freelists.org/webpage/oracle-l
Received on Fri Mar 09 2018 - 14:56:22 CET

Original text of this message