Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM

RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM

From: Bobak, Mark <Mark.Bobak_at_il.proquest.com>
Date: Wed, 3 Jan 2007 12:48:10 -0500
Message-ID: <AA29A27627F842409E1D18FB19CDCF270ACD4CD5@AABO-EXCHANGE02.bos.il.pqe>


I've seen similar looking corruptions on a few of my databases as well. I never did get to the bottom of the problem. However, in terms of solving the problem and moving on, you ought to be able to set MAXCORRUPT greater than then number of corrupt blocks you have, backup the datafile(s) affected, and then, restore datafile(s) from backup. Since they were corrupt on backup, Oracle will format the block at restore time. As long as the block is not part of any segment, that's ok. Note that if any corrupted block is part of any segment, the above is a bad idea.  

-Mark  

--

Mark J. Bobak

Senior Oracle Architect

ProQuest Information & Learning

There is nothing so useless as doing efficiently that which shouldn’t be done at all.  –Peter F. Drucker, 1909-2005

 


________________________________

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Uldis.Pavuls_at_tietoenator.com
Sent: Wednesday, January 03, 2007 12:35 PM
To: rshamsud_at_jcpenney.com
Cc: oracledba.williams_at_gmail.com; oracle-l_at_freelists.org
Subject: RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM


Riyai, 
it's quite possible the OS partition has been resized, i do not know, my role is rather consulting at need. I'm not on-site, it makes things a bit difficult. However, I did not find any tracs of resizing in the alert-log, at least not for the system tablespace (they certainly had had some difficulties with undo resizing, however). 
In fact there is account for 10 blocks in row corrupted in similar way, all fractured and with CORRUPTION_CHANGE#=0, rman just falls back on the first, although, it seems,  have recorded other piece of 9 blocks - next to the first one - in v_$database_block_corruption.Citation:
select T.NAME "T-space", D.NAME "Filename", C."FILE#" "FileId", C."BLOCK#" "BlockId", C.BLOCKS, 
C."CORRUPTION_CHANGE#" "Corr.SCN", C.CORRUPTION_TYPE 
from SYS."V_$DATABASE_BLOCK_CORRUPTION" C, SYS."V_$DATAFILE" D, SYS."V_$TABLESPACE" T 
where C."FILE#" = D."FILE#" and D."TS#" = T."TS#" order by 1, 2, 3, 4 ;

<Output as CSV>:
SYSTEM;/dev/rcmssystem;1;65535;1;0;FRACTURED SYSTEM;/dev/rcmssystem;1;65536;9;0;FRACTURED
<end of output>
All datafiles are locally managed and on raw devices (under VLM on AIX 5.3, so they are partitions in fact); there should be my first post (2 January, 2007) with a bit more info. Thanks for the idea of use of transportable tablespaces, it didn't occur to me. I'll certainly consider that. I was rather thinking about shrinking that file and then re-expanding it, that should clear the corruption on success - how do you think? It would be faster if succeeded. Altogether on the second thought CORRUPTION_CHANGE#=0 should mean media corruption, so your approach may be safer in long run. Best regards, Uldis Uldis Pavuls DBA, TietoEnator 41 Lacplesa Str., Riga, Latvia, LV 1011 phone +371 7 286 660, fax +371 7 771 313 mailto:Uldis.Pavuls_at_tietoenator.com http://www.tietoenator.com <http://www.tietoenator.com/> -----Original Message----- From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Riyaj Shamsudeen Sent: otrdiena, 2007. gada 2. janvârî 23:50 To: Pavuls Uldis Cc: oracledba.williams_at_gmail.com; oracle-l_at_freelists.org Subject: Re: RMAN fails because of corrupt block in seemingly free space in SYSTEM Uldis rman does not backup "never used" blocks, not "free" blocks. It is quite possible that this block was previously used and rman will back this block also. Looking at the following lines, clearly even rdba in the block is corrupted. Many other fields are corrupted too. Weird thing is that block is corrupted exactly at 65535 block, which happened to be a binary power of 16. Was this raw device extended using OS tools in the past ? If yes, from what size ? What is your db_block_size ? *** Corrupt block relative dba: 0x0040ffff (file 1, block 65535) Fractured block found during backing up datafile Data in bad block - type: 0 format: 2 rdba: 0x0000ffff last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05 consistency value in tail: 0x0074117a check value in block header: 0xfef9, computed block checksum: 0x9 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** Can you dump the block itself and print trace lines ? alter system dump datafile 1 block min 65535 block max 65535 Also, in your SQL, can you select block_id too ? select TABLESPACE_NAME,FILE_ID,BLOCKS, BLOCK_ID from SYS.DBA_FREE_SPACE where FILE_ID=1 and BLOCK_ID <=65535 and (BLOCK_ID+BLOCKS-1)>=65535; Is system locally managed or dictionary managed, in your database ? I am not sure why Oracle support would say that it is okay to have corrupt block, that too in a system tablespace. If I were you, I would be looking at creating a new database and transporting non-system tablespaces from current database to new database, urgently. Thanks Riyaj Shamsudeen -- http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 03 2007 - 11:48:10 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US