Reformatting empty but corruptly marked oracle blocks

Most of you may have already been tackling block corruption in oracle by simply employing the appropriate rman features. What actually appeared as the top most error on the monitoring log this morning was the following rman ERROR MESSAGE STACK, that looked as usual business at first:

channel ORA_DISK_2: backup set complete, elapsed time: 02:57:02
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup plus archivelog command at 01/01/2012 05:17:04

RMAN-03009: failure of backup command on ORA_DISK_2 channel at 01/01/2012 02:20:02
ORA-19566: exceeded limit of 0 corrupt blocks for file H:\ORACLE\SAN_3\ORADATA\WAZ\TEXT\TEXT_DATIDX_05.DBF


Redirecting dbv output to a file

this is a short note for everyone, who is still wondering why a simple shell construct like a redirect operator to a file won’t work for dbv (dbverify).

imagine a situation where you’re about to dbv-scan a good couple of datafiles and want to concatenate the output into a summary file. one approach is, probably, to just redirect/concatenate the output of dbv using >, create or cleanup the file, and >>, append the file, like so (please do not kick me for the weird “>” formatting below, the view plain link will show it correctly):

dbv file=c:\data01.dbf > dbv.log
dbv file=c:\data02.dbf >> dbv.log

however, the resulting file will be empty. the reason is, that for whatever sake, dbv does not write write to channel stdout, as one might expect, but to channel stderr (???). a simple trick to circumvent this issue is to overlay stdout and stderr by writing:

dbv file=c:\data01.dbf > dbv.log 2>&1
dbv file=c:\data02.dbf >> dbv.log 2>&1

here, the channel stdout is denoted by 1 and stderr by 2, respectively. to have it complete, channel stdin is usually identified by 0, if anyone may need to know it.

the same is, by the way, true for loadjava.