RE: RMAN impact

Mark

> CHECK LOGICAL
> ==================
> Tests data and index blocks that pass physical corruption checks for
> logical corruption, for example, corruption of a row piece or index 
> entry.

This part is interesting. In fact it is explicitly written that RMAN
detects corruptions in a row piece OR index entry. IMHO this simply
means that they detect logical corruptions at block level, i.e. they
don't do crosschecks between blocks. Basically no more than what block
checking (DB_BLOCK_CHECKING=TRUE, not block checksum) do.

> If the initialization parameter DB_BLOCK_CHECKSUM=TRUE, and if
> MAXCORRUPT and NOCHECKSUM are not set, then specifying CHECK LOGICAL
> detects all types of corruption that are possible to detect.

I love the part "all types of corruption that are possible to detect".
This also means that some corruptions cannot be detected.

> It is my understanding that an RMAN "BACKUP VALIDATE" with "CHECK
> LOGICAL" can, indeed, detect the sorts of corruption you are 
> referring to.
> I've even used it for such purposes on a couple occasions -- but
> since the results were "negative" I can't say for certain that it
> really works...  ;-)

I tested it explicitly. To do the test it is sufficient to delete an
index entry from an index block or delete a row piece from a data block.
Of course it is also possible to fake the ROWID in the index entry...
Result is that only ANALYZE detects such situations.

That said, the last time I had to fight with logical corruptions was in,
IIRC, 7.0.15. Since then only physical corruptions...


Best regards,
Chris
--
http://www.freelists.org/webpage/oracle-l


Other related posts: