Re: ORA-01578 data block corrupted with 10G

From: <Kurt-Erich.Finger_at_hte-company.de>
Date: 11 May 2005 08:16:22 -0700
Message-ID: <1115824582.723478.51550@z14g2000cwz.googlegroups.com>

hpuxrac schrieb:
> Kurt-Erich.Fin..._at_hte-company.de wrote:
> > RDBMS : 10.1.0.4
> > OS : Linux Debian Sarge 3.1
> > Kernel: 2.4.27-1-386
> > Box : standard office PC with 1G RAM
> >
> > We are testing an upgrade from 8.1.7 to 10.1.0.4 with some changes
in
> > the database design.
> > The schema was exported from the production machine (8.1.7)
imported
> > into the new box (10.1.0.4). The application could access the
tables
> > and seems to run correctly. We have to modify the design to remove
> some
> > faults in the old version. In one table we are replacing a column
> > containing strings with the corresponding ID's from a master table.
> > During this operation we get:
> >
> > ORA-01578 ORACLE data block currupted (file# 6, block 54871)
> > ORA-01110 : data file 6 '/data.dbf'
> >
> > I followed the Oracle instructions 28814.1 and found that the
segment
> > type where the corruption occured was a table (the table where I
want
> > to perform the update)
> > To exclude hardware error, I renamed the table and recreated it.
The
> > corrupted block error persists (with another record).
> > There is no ORA-600 error in the alert log file.
> >
> > The last lines in the alert log are:
> >
> > Thread 1 advanced to log sequence 6864
> > Current log# 1 seq# 6864 mem# 0: /data/redologs/redo1.log
> > Wed May 4 10:36:28 2005
> > Private_strands 18 at log switch
> > Thread 1 advanced to log sequence 6865
> > Current log# 2 seq# 6865 mem# 0: /data/redologs/redo2.log
> > Wed May 4 10:38:19 2005
> > Thread 1 cannot allocate new log, sequence 6866
> > Checkpoint not complete
> > Current log# 2 seq# 6865 mem# 0: /data/redologs/redo2.log
> > Private_strands 18 at log switch
> > Thread 1 advanced to log sequence 6866
> > Current log# 3 seq# 6866 mem# 0: /data/redologs/redo3.log
> > Wed May 4 10:39:45 2005
> > Hex dump of (file 6, block 54871) in trace file
> > /data/log/oradev10_ora_27480.trc
> > Corrupt block relative dba: 0x0180d657 (file 6, block 54871)
> > Bad check value found during buffer read
> > Data in bad block:
> > type: 6 format: 2 rdba: 0x0180d657
> > last change scn: 0x0000.01c64777 seq: 0x1 flg: 0x04
> > spare1: 0x0 spare2: 0x0 spare3: 0x0
> > consistency value in tail: 0x47770601
> > check value in block header: 0x3558
> > computed block checksum: 0xa400
> > Reread of rdba: 0x0180d657 (file 6, block 54871) found same
corrupted
> > data
> > Wed May 4 10:39:46 2005
> > Corrupt Block Found
> > TSN = 6, TSNAME = FAST_CORE_TS
> > RFN 6, BLK = 54871, rdba = 25220695
> > OBJN = 53256, OBJD = 53256, OBJECT= PARAM_VALUES,
SUBOBJECT
> =
> > Segment Owner= KEF, Segment Type = Table Segment
> >
> >
> > Thanks for any help
> >
> > Kurt-Erich
> >
> >
> > PS
> >
> > We know that Debian is not certified by Oracle, we had to use it
for
> > other
> > reasons. If this is a Debian problem we will of course install Red
> hat
> > or Suse
> >
> > PS2
> >
> > What does
> > Private_strands 18 at log switch
> > mean?

>
> One possible option ... get an rman backup before causing the
problem,
> keep db in archive log mode, use rman block recover to fix. That's a
> possible solution to allow you to continue testing.

>

> Isolating the source of this interesting failure as an os problem
> versus a hardware problem versus an oracle bug will be an interesting
> exercise. As you noted one of the first things to possbibly think
> about is re-testing on a different os ... without knowing any more
than
> you supplied can ugly throw in a free SWAG (Stupid Wild Ass Guess)
that
> your problem may be hardware based ... (controller or disk or ?).

Evetually we found the cause:

->>>faulty memory

all checks we ran on the filesystem (copying the file with dd to /dev/null
and Oracle#s dbverify) found no problem

Kurt-Erich Received on Wed May 11 2005 - 10:16:22 CDT