Blockrecover but full datafile restore + ORA-01193

Question

Hi,
We have a proplem, here is a short sescription:
We have corrupt blocks, how can we solve this problem? Blockrecover uses full datafile restore and finally fails with ORA-01193.
Here is a detailed description:
We have a 330GB datafile (bigfile tablespace) with 46 corrupt block.
DB version 10.2.0.4, Oracle linux, we use ASM.
We would repair these blocks.
V$DATABASE_BLOCK_CORRUPTION after "backup validate check logical datafile 7" :
FILE#     BLOCK#     BLOCKS     CORRUPTION_CHANGE#     CORRUPTION_TYPE
7     16872378     1     0     FRACTURED
7     16872408     40     0     CORRUPT
7     16872379     5     0     CORRUPT
The result is similar by dbv.
We have archivelog mode and backupset created by rman command:
backup as compressed backupset incremental level 0 database;
All of the corrupted blocks are in 1 LOB segment.
We copied the LOB segment, only 5 record cannot be read.
The corrupted LOB segment (and table) was exchanged by the copied (not corrupted) data, so users can work.
We remained the corrupted LOB segment in the database, but it is not in use.
I started blockrecovery by command:
BLOCKRECOVER DATAFILE 7 BLOCK 16872378,...,16872447;
The listed blocks are same as in the V$DATABASE_BLOCK_CORRUPTION, so the command could be:
BLOCKRECOVER CORRUPTION LIST;
The database was opened during blockrecocer and the datafile 7 was online.
A line appeared in the V$SESSION_LONGOPS with:
"RMAN: full datafile restore"
The restore was more than 4 hours, and finally it is failed with error:
Starting blockrecover at 29-AUG-12
starting media recovery
ORA-01193 file % is not the same file seen at start of recovery
Based on V$SESSTAT there were lot of physical read but only some physical write.
Maybe full datafile read, and only corrupted blocks was changed, but I didn't check it exactly.
We retried blockrecover with only one block, but the result was same: it failed after 4 hours with ORA-01193.
We retried the blockrecovery on a mounted but not opened database, and the datafile was offline:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE DATAFILE 7 offline
BLOCKRECOVER ...
The result was same: it failed after 4 hours with ORA-01193.
rman backup failed with error:
RMAN : ORA-19566: exceeded limit of 0 corrupt blocks for file %
After set maxcorrupt, rman backup ran successfuly
SET MAXCORRUPT FOR DATAFILE 7 TO 46;
Based on our current info, these workaround seems best for us:
- rman "set maxcorrupt"
- DB_BLOCK_CHECKING=FULL
- drop corrupted (but copied and not used segment)
- wait until corrupted blocks will be reallocated (checking it periodically by dbv)
- set maxcorrupt to 0
Our questions are:
*1. Why oracle uses "RMAN: full datafile restore" during blockrecover?*
Why needed to read the whole datafile?
One of the advantage of blockrecover should be the relative small IO, and fast restore.
I found only 2 results in google for "blockrecover" and "RMAN: full datafile restore".
(One of the findings was in this forum, but it was no answer for our problem)
*2. ORA-01193: file is not the same, but why?*
It is strange on opened database and online datafile, because other advantage of blockrecover should be the online recovery.
But it is more-more strange on closed(mounted) database and offline datafile. Only the rman blockrecover could change this file.
I found only 3 results in google for "blockrecover" "ORA-01193"
I found only the oerr output in google for "ORA-01193". But what does it mean? Only the rman blockrecover could change this file.
Cause: A different copy of the file was accessed the last time media recovery looked at the file header. A backup of the file was restored or the meaning of the file name changed during recovery.
Action: Ensure the correct file is available, then retry recovery.
*3. What else can be do to repair these corrupt blocks? What can we do for success blockrecover, or is there any other idea?*
Other infos:
- DB_BLOCK_CHECKING was false, but we changed it to FULL to avoid the subsequent corruptions
ALTER SYSTEM SET DB_BLOCK_CHECKING = FULL scope=both
- DBMS_REPAIR cannot detect the (out-of-line) LOB segment errors.
- rman SET MAXCORRUPT is not a "calming" solution
- When I read on internet, when we drop the corrupted LOB segments, the blocks will remains corrupt.
And the block will be repaired/formatted only when a new segment will allocate these blocks.
Based on metalink 336133.1, we can ensure the new allocation by fill the datafile with dummy data until the corrupted blocks will be allocated.
But this is a very IO intensive task.
- full recovery
very IO intensive, we try to avoid it.
Thx: lados.

Answer 1

Hi,
other infos:
We use ASM, and one of the disk is dropped and added after the last full (incremental level 0) backup. Can this premise causes the slow restore (something physical storage info is changed), or the ORA-01193 error (file % is not the same file seen at start of recovery) ? I don't think that a full db backup is needed after ASM disk drop/add/rebalance. But we tried a full backup (this was when the corrupt block first appeared with ORA-19566).
I found only one finding in the metalink for ORA-01193. The oerr reference (cause,action). It would be strange, if nobady else had problem with this error.
Thx: lados.