Logical block corruption in an unused block which is a part of index

Question

Hi All,
During RMAN backup level 0 I am getting a corrupted block my DB:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t20 channel at 07/22/2009 21:30:49
ORA-19566: exceeded limit of 0 corrupt blocks for file /oracle/oradata/DB2/plind05_02.dbf
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
2950 1879477 1 1.0124E+13 LOGICAL
SQL> SELECT tablespace_name, partition_name,segment_type, owner, segment_name FROM dba_extents WHERE file_id = 2950 and 1879477 between block_id AND block_id + blocks - 1;
no rows selected
So this block does not belong to any object.
SQL > select * from dba_free_space where file_id= 2950 and 1879477 between block_id and block_id blocks -1;+
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
USAGIDX_200907 2950 1879433 1048576 128 909
But it exists in dba_free_space so it belongs to file space usage bitmap.
DB Verify shows:
myserver:/oracle/rman/DB2:DBINST1> dbv file=/oracle/oradata/DB2/plind05_02.dbf BLOCKSIZE=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Wed Jul 29 13:47:38 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle/oradata/DB2/plind05_02.dbf
Block Checking: DBA = -480465494, Block Type = KTB-managed data block
**** row 2: key out of order
---- end index block validation
Page 1879477 failed with check code 6401
DBVERIFY - Verification complete
Total Pages Examined : 4194176
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 3404935
Total Pages Failing (Index): 1
Total Pages Processed (Other): 569
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 788672
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 1795222745 (2360.1795222745)
Now, I have identified that this block belongs to an index subpartition so I have rebuild it with alter index ... rebuild subpartition... However, the RMAN backup still fails and DBV still reports an error.
I know that we could simply recreate the index but the problem is that its quite big (>6GB and table is >7TB).
My strong feeling is that the cause of this is that corrupted blocks will still be reported by RMAN and DBV until they are reused and reformatted.
My question is:
How can I reuse or reformat a block which does not belong to any object?

Answer 1

Hi,
Yes you're right, you need to reformat that block.
For that you need to allocate that block to a table, and fill that table with data until high water mark goes higher than block 1879477.
This isthe way I've done it once:
1) check the free space size below that block:
select sum(bytes)/1024/1024 before from dba_free_space where file_id=1879477 and block_id <= 1503738;
Let's say it is 6000 MB
2) create a dummy table, allocate enough extents to fill the size returned from the previous query
This does not format blocks, but the advantage of allocate extents is that you can specify size and datafile:
alter table allocate extents size 6000M datafile '/oracle/oradata/DB2/plind05_02.dbf';
you can check dba_extents to see if it covers block 1879477. If not, try to add a little more extents.
3) fill the table with data to fill those extents.
One idea is to insert one rows into the table, then use 'alter table test minimize records_per_block;' so that each block will have 2 rows maximum.
check the number of blocks (from dba_segments). Say you have 768000 blocks. Then you need to insert 768000/2 rows:
insert into ... select ... from dual connect by level < (768000/2)
4) check the high water mark has reach the end of all extents (compare dba_tables.blocks and dba_segemnts.blocks)
5) if not enough, try to add a little more rows.
Be careful that you don't go too far (especially if you have extensible datafile). Unfortunately, maxextents is ignored on LMT :(
6) now, your block should be reformatted. Just drop the dummy table.
Regards,
Franck.