SEO

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?

Kurt-Erich.Fin...@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 ?).

hpuxrac schrieb:
> Kurt-Erich.Fin...@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