Re: Controlled block corruption testing

Yes, "dd" is the perfect way to do this, but interestingly enough you might also find out about the "self-healing power" of Oracle database along the way.

For classes and just for testing, I've used "dd" to induce block corruption errors (i.e. ORA-01578, etc) by copying "/etc/oratab" into the Nth block of datafile XYZ, after determining that the block was (or blocks were) occupied by a particular table or index using the DBA_EXTENTS view.

What is interesting is that, on occasion, I'd run the "dd" command, then query the object in question, and because the blocks were cached, never encounter the block corruption.

Or, even better, in one class I was teaching on database recovery, during an exercise where I would randomly cause block corruption on each student's lab environment, the first thing the student did after I finished was run ALTER SYSTEM CHECKPOINT to force DBWR to write changed blocks to the datafiles, thereby erasing the corruption I had caused.  Lucky yes, but as the saying goes, better to be lucky than good.

Anyway, just be aware that corruption doesn't always persist.

On 6/18/18 08:38, Rich J wrote:
>
> Hey all,
>
> I'd like to do some block media recovery testing in RMAN.  It seems
> that the Linux/Unix "dd" command would be an obvious choice to corrupt
> an Oracle datafile block, but has anyone documented a controlled test
> like this?  Try to not reinvent the wheel, if possible.
>
> I'm thinking of targeting specific objects in the database to
> corrupt.  It doesn't seem difficult to get a relative block and "dd"
> an empty block in its place on a test instance, but if someone's
> already beaten this path...
>
> TIA!
> Rich
>

--
http://www.freelists.org/webpage/oracle-l