FreeLists / oracle-l / RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM

[<Uldis.Pavuls@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx
http://www.tietoenator.com <http://www.tietoenator.com/>  

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Riyaj Shamsudeen
Sent: otrdiena, 2007. gada 2. janvārī 23:50
To: Pavuls Uldis
Cc: oracledba.williams@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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