Charles > Funny topic, eh? I am practicing backup and recovery procedures and > finding that recovery is quite easy since I never have corrupted > blocks to worry about. So, how do I practice for a "worse case" > scenarios? IMHO you already get excellent advices. I would just add that ideally you should not only check physical corruptions (RMAN reports such blocks as "FRACTURED" in v$database_block_corruption) but logical corruptions as well. About logical corruptions consider the following: - RMAN, during backups, doesn't check them per default... CHECK LOGICAL must be added. - The only way to produce them, if you are not lucky with random changes ;-), is to delve in the structure of the blocks, typically with BBED, and carefully change the blocks in a way that they are not recognized as physical corrupted. Another point is that RMAN doesn't detect inconsistencies (e.g. between DATA and INDEX segments). Only ANALYZE do it. HTH Chris > Are there white papers out there that go over this kind > of stuff? I found several "Best Practices" in metalink (look Mladen, > not plural), but that is not exactly what I am looking for as they > tell you how to fix the problem, not make the problem. I have tried > overwriting the binary files, but being simpled-minded I was using > vi. I thought about using the unix dd utility - unfortuantely I do > not have enough experience to be surgical (easy to mess up the first > few blocks, but what about the middle?). Can I use the same method > to isolate corruption to various parts of the database (ie, database > files, redo logs or rman backups)? > > I have a gut feeling that someone has already documented this, so if > this is the case, please point me there. > Thanks, > > PS - I have been practicing on 9iR2. Yet anything above 9iR1 would > be fine. > > -- > Charles Schultz -- http://www.freelists.org/webpage/oracle-l