Red Hat 2.1, Oracle 9.2.0.5 and 25GB file block corruption on HP 2005-01-28 - By Parker, Matthew
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 (See ORA-600.ora-code.com) [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 (See ORA-00600.ora-code.com): internal error code, arguments: [25012], [33], [277], [], [], =
[], [], []
Sometimes you will also see associated ORA-600 (See ORA-600.ora-code.com) 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@(protected) =
[mailto:oracle-l-bounce@(protected)] On Behalf Of aj wells
Sent: Thursday, January 27, 2005 2:05 PM
To: oracle-l@(protected)
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 (See ORA-00600.ora-code.com): 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-l
|
|
