April, After all, EXP will drop dead on only the first corrupt block within the high-water mark of tables; it won't check indexes. Some better alternatives: 1) If error messages (or the trace files accompanying the ORA-00600) displayed actual block addresses (either FILE#/BLOCK# or DBA), then you can use the DBMS_REPAIR.CHECK_OBJECT procedure to verify, after obtaining the name of the segment by querying DBA_EXTENTS... 2) ALTER SYSTEM DUMP DATAFILE [ file-id | 'file-name' ] [ BLOCK block-id | BLOCK MIN min-block-id BLOCK MAX max-block-id ] can help as well? It produces a trace file in the USER_DUMP_DEST, and usually if the block is corrupted, the dump will say exactly that... 3) RMAN "backup validate" command performs a "false backup" (i.e. just reads datafiles, doesn't write to backup media). This is the "EXP FULL=Y FILE=/dev/null" command done the right way... Hope this helps... -Tim on 1/27/05 3:04 PM, aj wells at awellsdba@xxxxxxxxx wrote: > Okay... not that that is out of the way... > > We have a multi TB databae (one of several) that has many 25GB files > (since it seems that is the biggest file we can make... ) and we have > several file systems. "we" just created two new file systems that are > 600+ GB each across several disks (0+1). > > When we allocated new files on the first of these file systems, we got > block corruption... (ORA-00600: INTERNAL ERROR CODE, ARGUMENTS: > [25012], [27]) on several of the files. > > HP says not hardware, RH says either Oracle or Hardware and Oracle > says it is OS or hardware. > > Anyone else seen anything vaguely resembling this... it is becoming a > big giant Charlie Foxtrot and no one is of much help (although Oracle > did have us start an export 13 hours ago on the tablespace and it is > now nearly half done... that will tell us if the two extents in the > only file left showing corruption is actually corrupt or only > pretending to be... ) > > thanks > aj > -- > //www.freelists.org/webpage/oracle-l > -- //www.freelists.org/webpage/oracle-l