So I assume that you didn't get corruption on the creation of the data = files but during the use of the data files since there are segments in = them you are trying to determine if they are corrupt.=20 The ORA-600 [25012] in most cases is index corruption, but sometimes it = affects a table object also. The problem relates to AS 2.1's pthread = library and Oracle. We had a few of these over many months requiring us = to repair blocks to get past it to ensure no data loss. The only = solution is to upgrade to AS 3.0 which has a different pthread library = and does not have the problem. As to your current corruption, as Tim stated there are some other = methods to determine if something is corrupt. The problem with these = 25012 corruptions is the arguments in the alert.log to the 25012 is the = table space number and the relative file number but not the block that = is corrupt. To find that you must go back to your alert.log and find all = the trace files associated with this corruption/crash. Tue Oct 5 18:42:44 2004 Errors in file /dumps-01/databases/xxx/udump/xxx-3_ora_15990.trc: ORA-00600: internal error code, arguments: [25012], [33], [277], [], [], = [], [], [] Sometimes you will also see associated ORA-600 with base arguments of = [4000], [17102], [15784], [kcbzpb_1], etc... Once you isolate the trace files then you can search in the trace file = for "last wait for" last wait for 'buffer busy waits' blocking sess=3D0x0 seq=3D1773 = wait_time=3D73 file#=3Db, block#=3D6599, id=3Ddc temporary object counter: 0 The file and block number are in hex so: file=3D11 block=3D26009. You = then can run dbv on this block: dbv file=3D<file_name blcoksize=3D<db block size> start=3D26009 = end=3D26009 You can also use these start and end arguments in dbv to examine a = complete extent in the database by simply determining the begin and end = block of an extent from dba_extents. Select extent_id, block_id begin_block, block_id+blocks-1 end_block from = db_extents where segment_name =3D <your segment name> and file_id =3D < = rfno from the 25012 arguments > Then pick the extent you wish to look at and: dbv file=3D<file_name blcoksize=3D<db block size> start=3D<begin block> = end=3D<end block> If corruption actually made it to disk and is in a table, then it is = repairable, but not usually by normal means. There is a 10% chance that = simply doing a single block recovery with RMAN can fix it, in the other = 90% of the case it requires a block edit to fix. If it is an index, then = simply drop and rebuild. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx = [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of aj wells Sent: Thursday, January 27, 2005 2:05 PM To: oracle-l@xxxxxxxxxxxxx Subject: Red Hat 2.1, Oracle 9.2.0.5 and 25GB file block corruption on = HP 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