| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Red Hat 2.1, Oracle 9.2.0.5 and 25GB file block corruption on HP
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=3Ddctemporary 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_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of aj wells
Sent: Thursday, January 27, 2005 2:05 PM
To: oracle-l_at_freelists.org
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
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Fri Jan 28 2005 - 05:48:06 CST
 |
 |