Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Red Hat 2.1, Oracle and 25GB file block corruption on HP

RE: Red Hat 2.1, Oracle and 25GB file block corruption on HP

From: Parker, Matthew <>
Date: Fri, 28 Jan 2005 02:45:14 -0800
Message-ID: <>

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: =
[] On Behalf Of aj wells
Sent: Thursday, January 27, 2005 2:05 PM To:
Subject: Red Hat 2.1, Oracle 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... )


Received on Fri Jan 28 2005 - 05:48:06 CST

Original text of this message