Re: Question: ONE corrupted tablespace in standby db???

> Does that mean you haven't tried to bring it up in read-only mode? I
> think you must have since you say "is being used," but I have to ask.
> Have you read from the affected datafiles?

I can bring the db up in read-only mode.

The affected files only contain a few specific, large, indexes.

> When you created the standby, did you use RMAN or a manual procedure?
> Did you follow a particular cookbook?

Not RMAN. I used a manual process, after reviewing Oracle's documentation.

> "You can usually ignore "Block found already corrupt" messages,
> because these
> are reporting a soft corruption in unused blocks.
> There is NO corruption in CURRENTLY used blocks.

Interesting. I would think that I would get some evidence of this with a dbv against the master db's data files, but they all verify with no warnings...

> Blocks found already corrupt do NOT contribute to the dbv report statistics.

True enough, the summary at the end of the log indicates no errors found.

> See Note:283787.1 - you perhaps recovered a nologged table,

INTERESTING: I just ran a select with an index hint, and got this::

ORA-01578: ORACLE data block corrupted (file # 90, block # 2571)
ORA-01110: data file 90: '/disk1/oradata/db1/arch_idx_db1_03.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

I do recall now, that I had to relocate this index from one tablespace to another not long ago, and elected to use NOLOGGING because at this point I need to be VERY aware of how much redo I was spitting out (disk space issues). This would appear to be the culprit.

I'm still not entirely clear on the implications of the NOLOGGING, but I'll obviously be digging into it... regardless, I see an index rebuild in my future. Or perhaps a recreation of that whole tablespace.

Thanks!! Received on Fri Jun 16 2006 - 17:00:09 CDT